C++ for C Programmers: part 1(ds9a.nl)
ds9a.nl
C++ for C Programmers: part 1
https://ds9a.nl/articles/posts/c++-1/
14 comments
I tried to rewrite my node backend in C++ but I got stuck at the package management part. When I learned Node I was able to install NPM and run “npm i -P uws” and was up and running quickly. Reading through about 5 WebSocket C++ lib installation instructions and still not making any progress was enough to make me wonder if my time would be better spent paying for a faster and/or bigger server cluster and just keeping node.
> I got stuck at the package management part
Bazel.io has been a revelation for me, and made C++ essentially practical to use on a day-to-day basis.
Bazel.io has been a revelation for me, and made C++ essentially practical to use on a day-to-day basis.
Packages are not really a thing in C++, partly because there are so many different environments and compilers anyway, and partly because C++ apps aren’t really made by stitching together hundreds or thousands of tiny packages like in Node.
On Windows you might use NuGet, on Linux you might use whatever the native package format is, but you would thinking fewer, bigger libraries rather than what you’re used to.
If you are looking for REST stuff try Casablanca, it’s on Github or in the repo for Ubuntu.
On Windows you might use NuGet, on Linux you might use whatever the native package format is, but you would thinking fewer, bigger libraries rather than what you’re used to.
If you are looking for REST stuff try Casablanca, it’s on Github or in the repo for Ubuntu.
Vcpkg is becoming the way to go for those that don't mind compiling everything, otherwise NuGet as usual.
Vcpkg has been really helpful for me, however I can't recommend its usage in day-to-day work considering it compiles things differently from vanilla releases.
It was a rather deceptive aspect of its usage that wasn't well advertised. Compilation units should be functionally equivalent to releases directly from vendors.
It was a rather deceptive aspect of its usage that wasn't well advertised. Compilation units should be functionally equivalent to releases directly from vendors.
author here, comments are welcome btw!
Perfect for where I am at the moment.
One question - Is there an RSS feed for your blog? I couldn't find one
One question - Is there an RSS feed for your blog? I couldn't find one
I don't know what you have planned for future installments, but I would make sure to emphasize that C++ more-or-less simply codifies common practice in C. E.g. how std::vector just codifies the practice of dynamically sized arrays using realloc, and iterators just codify and generalize the use of pointers as indices. I was not a C++ convert until I realized this.
> how std::vector just codifies the practice of dynamically sized arrays using realloc
I haven't ever seen std::vector using in-place realloc when resizing. The implementations I've seen simply always allocate a larger vector and copy the elements over.
Realloc tries to expand already allocated memory region if there's enough space immediately after current block. New allocation and copy is only done when this is not possible.
I haven't ever seen std::vector using in-place realloc when resizing. The implementations I've seen simply always allocate a larger vector and copy the elements over.
Realloc tries to expand already allocated memory region if there's enough space immediately after current block. New allocation and copy is only done when this is not possible.
hi colanderman, that is exactly the plan! I have a section on classes already done as something that most C projects eventually do by hand (ie, bunch of functions that accept a pointer to a struct as first parameter, which is actually "this"). You can even extend that into inheritance where you see most C based GUI toolkits emulating classes in all kinds of ways. Even the Linux kernel has tricks like this. Thanks for the tips!
Regarding the standard library you might also give a brief explanation about bounds checking in debug builds for example.
I find your comparing the running times of qsort and std::sort a bit dubious. How sure are you that the difference in running time has anything at all to do with inlining, and not differences in how those two methods are implemented? I get the point you're making, that using templates opens up all sorts of possible inlining optimization possibilities, but it still seems like an unfounded comparison to say that the run time difference between those two are solely due to inlining.
There's no reason libc couldn't define a static inline implementation of qsort in the header. The callbacks could be inlined just like in C++.
But putting tens of thousands of lines of basic library code into headers isn't commonly done in the C ecosystem for very good reasons--e.g. ability to fix a bug or improve performance[1] without having to recompile dependent binaries.
That said, in the BSD universe there are linked-list and tree implementations provided in <sys/queue.h> and <sys/tree.h> that are almost universally used, in both the kernel and userland. The macro definitions might be uglier than templates but no less typesafe and nobody forces you to look at the headers. Unlike sorting and hash algorithms 1) these never change and 2) they make it possible to create intrusive (space-efficient, zero-allocation) data structures, so it just makes sense to provide them in headers.
[1] qsort is not always implemented using quicksort. In fact, I think it's the exception rather than the norm.
But putting tens of thousands of lines of basic library code into headers isn't commonly done in the C ecosystem for very good reasons--e.g. ability to fix a bug or improve performance[1] without having to recompile dependent binaries.
That said, in the BSD universe there are linked-list and tree implementations provided in <sys/queue.h> and <sys/tree.h> that are almost universally used, in both the kernel and userland. The macro definitions might be uglier than templates but no less typesafe and nobody forces you to look at the headers. Unlike sorting and hash algorithms 1) these never change and 2) they make it possible to create intrusive (space-efficient, zero-allocation) data structures, so it just makes sense to provide them in headers.
[1] qsort is not always implemented using quicksort. In fact, I think it's the exception rather than the norm.
I have been very surprised how quickly I got up and running. Modern C++ had come a long way from what I remember a ways back.