johnmurray / cpp-vs Goto Github PK

It's common to see code in Go code like the following

func doStuffWithResources() {
    handle = openSomeResourceHandle()
    defer handle.Close()

    // do stuff with handle
}

It would be fun to compare this to C++ code using RAII techniques.

Currently no title is set on versus pages (<title>). This needs to be set from a versus.yaml for ease of use and SEO stuff or whatever.

Open thinking about whether or not the C++ examples in the versus should be runnable via a Docker container and what that would look like from the site, to encourage further exploration.

Ruby has really found its place as a language of the web. With the popularity of Rails as well as the less-recognized Sinatra (upon which many other frameworks have inspiration, such as Flask for Python).

A good example for a simple web-server comparison would likely to be Sinatra. As it can easily fit on a few lines of code. Also since the C++ solution will be in Crow it makes a good comparison since Crow is inspired by Flask which was inspired by Sinatra.

The links for code-examples are not clean (contain .html extensions). The generated code should remove these from the URLs since they are not required with the Rack server anyways.

JS comes with very few data-structures although newer ones are landing in more modern JS. It'd be nice to do a purely standard-lib comparison of data-structures available. If one is not available, then it should be demonstrated the idiomatic work-around to implement it.

Off the top of my head, I'm thinking

• arrays
• maps
• queues
• sets
• trees

I'd also be open to highlighting a couple exotic structures that exist in the C++ std-lib, if there are any suggestions.

• basic string manipulation: trim, find, find-replace, capitalize, lower-case, etc.
• advanced string manipulation: sub-strings/view, buffers
• string formatting: gets into streams, so separate from advanced string manipulation

Overview

Shell work out to a bunch of worker threads/goroutines and then collect on the results.

Justification

Go has a principle of "Don't communicate by sharing memory, but share memory by communicating". That is to say, message passing and copying data across go-routines is preferable to sharing memory and using things like mutexes/locks to control access. This is really quite sound advice. However, since C++ lives in a world where performance is king, usually the case is the former in the original statement (communicate by sharing memory).

For those coming to C++ from Go, it is at least important for them to understand C++ code that they will likely encounter. Whether one style is preferable to the other depends on the situation, so I don't think it is right to sell either as good or bad, just typical Go vs typical C++.

I would contribute another piece comparing C++ Future Extensions as already available via the Boost Futures implementation vs. native JavaScript promises.

Should be fun discovering their similarities.
E.g. future<X>::then([](future<X>){...}) <=> promise.then(function(x){ ... }))

Good idea?

Edit (August, 1st):
Just to collect ideas here:

Edit (Aug. 21st):
Found a C++ library for the Promises A+ Spec: xhawk18/promise-cpp.

• However evolved wrapping of Boost.Asio needs to be done. Which may be a concern when updating Boost.Asio which natively at least supports std::future. 😞
• Couldn't yet find code to convert xhawk/promise to/from std::future/boost::future 😞

Now that we have development builds/environments on top of docker, the next logical step is to create a release job that can build the site in docker and persist the changes back. I think this is possible with local volumes. Essentially I want to completely eliminate the need for my release VM. 😛

self-explanatory. Offers good intro to syntax in C++. Copy/steal a lot from the JS lambdas one.

Go really only has one concurrency model by default, which is called a "Go Routine." It is essentially a lightweight (green) thread and the primary communication mechanism is through channels (comparable to synchronized queues). This type of concurrency is called CSP (Communicating Sequential Processes).

C++ on the other hand provides threads as the base-level of concurrency and doesn't restrict the types of concurrency we build on top of that, such as futures.

I think Go can be rather restrictive in terms of building higher-level abstractions, which can result in having to implement a lot of common patterns by hand, or with lots of code-generation. An example of futures by hand is here: http://www.golangpatterns.info/concurrency/futures. I think it would be a fun comparison to show off some of the flexibility of C++

A link should be added to the page to showcase the contributors to the site. I think a link to Contributors Graph page on GitHub should be sufficient.

Ruby lambdas and blocks are pervasive in stdlib and 3rd-party libraries. It should be fine to copy the format (and much of the content) from the JavaScript section on lambdas.

This is kind of getting into the realm of functional programming but is very common in idiomatic JS. The example should compare built-in as well as library based collection transformations. This includes functions such as map, flatMap, filter, each, etc. Ideally over multiple collection types. Since JS mainly has lists ([]) and maps ({}), we should focus on those types. I think we should stay away from the newer types in JS such as Map as they 1) aren't much used in typical JS code and 2) do not provide functional interfaces.

For the JS library section, Lodash should be used as it is 1) the gold standard and highly popular JS library and 2) provides a wide variety of collection-based methods.

For the C++ library section, I think Boost will likely be what is used, but am open to other suggestions as long as the library can be considered extremely mainstream and heavily used by the community at large.

Need to support styling for "notes". These are bits of HTML in the description files that are more of a "oh hey, and by the way ...". The visual delineation is useful to separate partially related concepts/topics/interjections from the main explanation.

<p class="note">
  <strong>Note</strong> These features are coming in a future version of
  C++, but are available in library form <a href="">here</a>.
</p>

I'm thinking something like

.note {
  border-left: 3px solid @lightGray;
  padding-left: 10px;
  font-style: italic;
  color: @lightGrayText;
}

Basically insert it, give it a left-border, make it ligher, and italic.

Opening an issue to track feedback.

• Lambda Captures - Explain more what the implications of a capture are (copies, memory-footprint of the lambda, etc) - resolved #36

A bit of feedback I got from Aaron Himelman (sorry, I don't know your GitHub handle).

Since C++ can differ greatly between official versions, it might be useful to point out somewhere on the site what version is being used. So far all of the examples have been tested with c++17, but whether it's worth noting the versions the examples work with or just stating somewhere that all examples use c++17... I'm not sure. Need to think on this more.

Many go apps will, even if not a web-service, expose a web-service as part of their running code. Part of why this is so common is how easy it is to spin up a web-server just using bits from the standard library.

Since we already have a C++ example in the C++ vs JS: Simple Web Server page, we can copy/paste from the C++ portion and just need to write up the Go bits.

One of the things that Ruby is really good at doing is sometimes called "string munging." Basically the ability to easily parse various kinds of input into a usable form, do something with it, and possibly output some info. It's a great scripting language.

This is very similar to some of the JS examples in the string processing versus, but with an emphasis on scripting (Ruby's domain). I think this will be particularly welcoming for system administrators who have a background in Ruby that need to learn C++ (or those who have operated in a similar role and maybe are transitioning).

I'm thinking of building a program and parsing the input from the ls command into some internal data-structures might be a good bit of code to showcase the dfiferences and provide lots of good teaching moments.

One thing I've been thinking about as I expand the examples beyond the initial JavaScript ones is that each language should be self-contained. Since the goal of the site is to be educational for members of other programming-language communities, it can't be assumed that anyone coming to the site is already polyglot.

However, there are some bits of information that are common to all examples across all versus' and are mostly just some preambles to understanding C++ code. I think this site is targetted toward more advanced (or adventurous) users, so a full explanation is not necessary, but it might be nice to offer some resources that fill in the gaps, such as:

• understanding #include statements and how they work
• understanding the various toolchains (clang, gcc, etc) and what defines c++ (the standard)
• understanding package management in c++ (or lack thereof)
• stack vs heap
• C++ versions (11, 14, 17), the standards process (at a high level) to understand how the language changes/evolves

Note: This is likely something that I'll revisit after the 1.0 milestone.

Given Go's sell that concurrency can be done very simply in Go, I think it'd be great to do a comparison of Go to C++ in the area of process coordination. That is, having multiple threads/go-routines coordinating together to solve a common task. So far I've written up the following, although I'm not particularly happy with it so it will likely change a bit:

Given the string Hello, World! each program must create as many concurrent
units (threads for C++, goroutines for Go) as there are characters. Then the threads
must coordinate (without the help of the main thread) to print out the characters in
order. The concurrent units may receive, at a minimum, the character they are responsible
for as well as the index of the character to print.

again Boost is required on the C++ side.

While the purpose of writing this site's generator in C++ is a attempt at demonstrating how easy C++ can be (because meta), it doesn't make contributing to this site from non-C++ programmers easy.

Rather than requiring non-C++ developers who wish to contribute to set up an environment with all the right dependencies and compiler versions, having the build be done in a simple docker container would be a much better workflow. The idea is that the user should be able to run make docker-dev and a docker instance should spawn which builds the site and then serves it on a host, and ideally dumps out the URL to the console for the user to see the site in their local browser.

This reduces the required dependencies for developing from C++ compilers and libraries to just docker (which is becoming pretty universal).

Bonus Work

It would be nice to move the production/release builds to this model as well. This should be possible as long as the build dockerfile mounts a local folder as a volume to produce the _site files into. This would free me up to do development on whatever machine I happen to be using on that day, and get rid of my linux VM I dedicate to this.