auto ptr = mmap(NULL, sizeof(std::atomic), PROT_READ | PROT_WRITE,
MAP_SHARED | MAP_ANONYMOUS, -1, 0);
g_counter = new(ptr) std::atomic();
Modern C++ for C Programmers: part 5
61–70 of 82 posts
Re: Modern C++ for C Programmers: part 5
#62Earlier quoted context omitted.
It's possible that I'm missing something, but I believe that the result is necessarily identical in C, because there can be no observable side-effect of a struct copy in the C abstract machine.
No, it is not necessarily identical in C, because even though you don't have constructors or destructors, you can make an address comparison to check whether two objects are identical. For example the following code: https://godbolt.org/g/ikD6bi where the address of the caller's variable that will take the return value is passed along to the function returning it. Within the callee, f1 and f2 must be different object…
Ah, yes, that's a nice example.
Re: Modern C++ for C Programmers: part 5
#63Earlier quoted context omitted.
Certain IDE vendors could solve this if they really cared about UX. Not by implementing modules, but by efficiently scanning vast directories for versions of headers, and arranging them in a visually navigable manner (you know, actually being a useful IDE). The last time I used one, the OS was incapable of even searching folders. Partial string matching of filenames was apparently too complex for it to handle.
If you have your IDE properly configured with the include dirs needed to build, at least MSVC can autocomplete for you. Personally, I don't rely on this, as I do most of my C++ work from the command line using bash, vim & make. Can't explain why, but for C++ projects, I intuitively remember what paths I need for headers, but for a C# project, I rely upon autocomplete as a crutch. Maybe it's just how much more time I…
> If you have your IDE properly configured
You're misunderstanding me. I'm saying the IDE should discover headers for me. MSVC refers me to a Byzantine series of clicks, drop downs, text input, and OK buttons. That interface hasn't changed for 20 years
A proper modern UX would scan for valid headers in a dir, then allow me to choose which ones to "import" into the workspace. Not make me hunt for them through an antiquated and inefficient UI
Re: Modern C++ for C Programmers: part 5
#64Please please please can we get rid of headers and have modules? I find it super annoying having to specify things half in one place and half in another. Unfortunately, there still seems to be a bit of disagreement on the implementation among the standards committee.
You do not really to do that in C. If you are careful, the header only contains the visible interface, which is a list of functions that can be trivially deduced from the non-static functions of the source file. Moreover, the header file is optional, and is never included by the source file.
In C++, yeah, this language sucks.
Re: Modern C++ for C Programmers: part 5
#65Earlier quoted context omitted.
Single-file header libraries are actually all the rage in C++ these days. Here's[1] a list even! [1] https://github.com/nothings/single_file_libs
This is what you get if you're missing a proper package management that allows users to easily install their libraries. That single file is the substitute for a package that you can simply put somewhere, include it and it works.
> That single file is the substitute for a package that you can simply put somewhere, include it and it works.
So the substitute is much better than the package!
Re: Modern C++ for C Programmers: part 5
#66auto ptr = mmap(NULL, sizeof(std::atomic ), PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, -1, 0); g_counter = new(ptr) std::atomic (); waw, a 4k integer (or even more, depending on the platform).
I don't see the problem here. The code you quote is correct and guaranteed to allocate the minimum amount of memory for which the hardware can support the requested functionality.
It passed sizeof(std::atomic) as the length parameter and mmap() decided to give us a larger page (which may or may not be 4k) for its own very good reasons, namely that the overhead of keeping track of hyper-granular memory pages would cost more than it would save.
For a program that needs at least one shared counter, it's not possible to allocate less than one page of shared memory, regardless of if its implemented in C++, C, or whatever language -- it's a hardware level decision. If MMU designers could still provide 512 or smaller pages with the same performance as 4k pages they would certainly do so. Nor is it reasonable to keep track of memory flags like MAP_SHARED at a more granular level than a single page.
If the program did need more than one shared counter, it could instead use something like std::array, 512>. In other words, there's no reason why it would have to allocate 4k for every shared counter -- there's zero inherent overhead. It appears as if this particular program only needed 8 bytes, request 8 bytes, and had its request satisfied in the best way the hardware could allow.
Re: Modern C++ for C Programmers: part 5
#67Earlier quoted context omitted.
It takes all sorts, but I prefer the headers. Each project’s copy only gets upgraded explicitly, the debug info is always there, single stepping always works, there’s never a problem with ABI/compiler option mismatches (and you get the unoptimised version in your unoptimised build), anybody that gets the repo automatically gets all the dependencies too.
I.e. all the things you would get from a proper package manager if there was one for C++.
Sure... but it would have to be proper-as-in-proper. And what are the chances of that? Seems to be hard enough to even enforce the rule that ``-O3 -g'' is a thing, let alone all the rest :(
Re: Modern C++ for C Programmers: part 5
#68is there a modern C++ for python programmers? i have ~5 years programming in dynamic/interpreted (python/js) and compiled/gc'd(java/go) languages and i'd like to learn a systems language. i'm reading the rust programming book (and it's really good/easy to grok) but i'd also like to learn C++. the problem is that most books are either too easy (C++ as your first language) or too hard (straight into RAII and templates)…
I'm primarily a JavaScript developer nowadays. I used C back in the 80s and 90s but never really used C++. I decided to start teaching myself C++ a few weeks ago. I've been going through "The C++ Programming Language 4th Edition". It only covers up to C++11 but the first 100 pages or so goes through a quick whirlwind overview of the newer "modern" C++. The rest of the book goes more in depth and is a bit basic for most of the text for experienced programmers. So it has both the too easy and too hard parts but at least you can jump around to get somewhere in between. It's not great but it's the best resource I've found so far. I tried some Udemy courses but a lot of them move too slow and assume no programming experience.
Re: Modern C++ for C Programmers: part 5
#69is there a modern C++ for python programmers? i have ~5 years programming in dynamic/interpreted (python/js) and compiled/gc'd(java/go) languages and i'd like to learn a systems language. i'm reading the rust programming book (and it's really good/easy to grok) but i'd also like to learn C++. the problem is that most books are either too easy (C++ as your first language) or too hard (straight into RAII and templates)…
Worth noting that auto_ptr is decidedly not modern, it was deprecated in c++11 because it was error prone and replaced with C++11's unique_ptr (and shared_ptr/weak_ptr too sort of, although they have a different use case -- unique_ptr really is basically the same use case as auto_ptr). I figure you didn't mean to call it out specifically and more meant general smart pointers, but just felt I'd let you know that searc…
> deprecated in c++11
Not only that -- it was removed in C++17!
Re: Modern C++ for C Programmers: part 5
#70Earlier quoted context omitted.
I find D to be a good tradeoff between C++ and Rust. I can't stand not having compile-time evaluation, code generation and reflection in Rust and C++ is just too slow to iterate with.
Working with Python lately I very much got to like the interactive REPL and its immediate feedback. I actually think I forgot how to program in C. It lacks almost every data structure I'd deem useful to getting complex and mixed problems solved quickly. C++ provides many things and is useful if you are in a tight spot or you want/need the speed. If Rust keeps evolving at a quick pace I think I'll look into it a lot i…
Why wouldn't D work on microcontrollers? Runtime is too big? GC too difficult to avoid? Even in -betterC territory?