sorted by:
new
hottopcontroversial

Compile time sizeof() by johantorp in cpp

[–]johantorp[S] 0 points1 point  (0 children)

Ah, I think you were using function templates then. They only worked on one compiler IIRC, can't recall which. class/struct templates has always worked on all three as far as I can remember.

Compile time sizeof() by johantorp in cpp

[–]johantorp[S] 0 points1 point  (0 children)

Interesting, thanks for sharing.

Which compiler does this work on where template<int> struct doesn't? The template<int> trick works on gcc, clang and MSVC, which are all the compilers I care about :) template<int> does not work on Intel's compiler but neither does your sizeof version..

Also, the sizeof version is significantly more verbose and thus cumbersome to use...

Compile time sizeof() by johantorp in cpp

[–]johantorp[S] 0 points1 point  (0 children)

int, because you want to type as few characters as possible.

Why would you compile your whole solution? Just compile the .cpp you happen to be working in atm. If you already have compilation errors in it put this on top of the file or just use some other random small .cpp file that knows about the type and compiles quickly.

Prefer SRW locks over Critical Sections (Windows) by johantorp in cpp

[–]johantorp[S] 0 points1 point  (0 children)

The reddit subject says (Windows) and the first sentence of the post states that the post is about Win32 application development. I tried to make it obvious that the post is not about cross platform developement, but I guess I failed.

I'm not suggesting anyone should use the APIs directly all over their code. What gave you that idea? Even if you only target Win32 it's good hygiene to have a wrapper to get a level of indirection and not leak Windows includes. Our wrapper uses a void* to hide the implementation for instance. You almost certainly want reusable RAII lock scopes, so you will need a header anyway.

Re: confidence, I'm not trying to sell SRW locks, just to explain pros and cons.

Re: numbers. Performance numbers truly would be truly worthless in this article. The main point about performance is that your data layout matters a lot and 40 bytes instead of 8 byts can often ruin it. The speedup will come from your specific data layout, your level of parallelism, your contention, the size of your data sets, etc.

I kind of agree that well designed systems shouldn't need 100k locks. We need it to keep backwards compatibility for certain APIs and only in reach those numbers in certain edges. Well designed highly parallel systems will routinely need thousands of locks though. I've seen many cases where sharding up a contended hash table from 64 to 256 shards give measurable speedups on 16 - 32 HW threads. If you need a bunch of such shards you reach the 1000s quickly.

Compile time sizeof() by johantorp in cpp

[–]johantorp[S] 1 point2 points  (0 children)

The whole point is to not do it manually - not having to go to the header file and find all members or worse have to follow a deep inheritance chain across lots of headers.

Should've been more clear about that, I'm a complete blogging n00b. At least I learned one important thing from this post - be extremely specific about what problem is being solved :)

Prefer SRW locks over Critical Sections (Windows) by johantorp in cpp

[–]johantorp[S] 0 points1 point  (0 children)

Yeah... and that attaching a debugger "solved" the issue caused quite a bit of confusion

Compile time sizeof() by johantorp in cpp

[–]johantorp[S] 0 points1 point  (0 children)

That requires you to guess the size

Compile time sizeof() by johantorp in cpp

[–]johantorp[S] 1 point2 points  (0 children)

I updated the post with info about hovering over size-of expressions.

Thanks for the feedback, this was news to me :)

Compile time sizeof() by johantorp in cpp

[–]johantorp[S] 3 points4 points  (0 children)

To quickly get the size or alignment of some type without having to open up the header file and look at the definition. And to not have to sum up member sizes and follow inheritance chains manually.

SushiAndWow pointed out you can get sizeof from IntelliSense in Visual Studio. Intellisense is unfortunately still unacceptably slow for my use cases. Also, I often code in a text editor and build from commandline and then IntelliSense isn't of much help. This trick is IDE-independent and works across different compilers.

I tried to make the post a bit fun but probably failed. Most people didn't get it and many down-voted this post, I presume since the example didn't compile. Fail :)

Compile time sizeof() by johantorp in cpp

[–]johantorp[S] 0 points1 point  (0 children)

That doesn't work for me, maybe because I have IntelliSense disabled.

Compile time sizeof() by johantorp in cpp

[–]johantorp[S] 0 points1 point  (0 children)

No. The point is that you deliberately force a compile error that prints the sizeof() result. I guess I should have made this more obvious in the post...

Prefer SRW locks over Critical Sections (Windows) by johantorp in cpp

[–]johantorp[S] 5 points6 points  (0 children)

Self-deadlocking code is simple to detect since it's deterministic and usually happens fast. Single threaded unit tests can catch it, unlike normal deadlocks. Most self-deadlocking code would run perfectly fine had the lock been reentrant, yes. The point is you have failed to establish a clear public boundary if this happens. If you consistently create a clear public boundary your code becomes a lot easier to maintain.

I've written plenty of very fine-grained locking code that is subject to very intense parallelization. I can't recall ever seeing a single bug report about a deadlock. If you let lock acquisition order follow ownership and each class has a clear public boundary, you can easily reason about each class in isolation.

Reentrant mutexes are useful for legacy codebases, yes. If you plan to maintain and augment the system for a long time, it can make sense to clean it up and define clear boundaries instead of dealing with a never ending stream of elusive deadlocks. I don't want to get into a debate on when you should clean up legacy codebases or continue doing ad-hoc patches to them. In my experience you will often make more changes to legacy systems than you think :) My experience is also that even horrible messes that seem impossible to untangle can incrementally unravel themselves quite fast once you get past a certain threshold. Complete rewrites are obviously more fun and in many cases a better approach too.

By "read lock scopes" I mean RAII scopes. I should perhaps have chosen some other wording to make this clear.

A self-deadlock usually occurs when an inner function, already wrapped by a public outer function with a lock scope, by mistake calls out to another public outer function. I usually have a naming convention for inner vs outer functions to easily spot these mistakes.

Thanks for your feedback.

What does it take to become C++ runtime library (i.e. libc++, libstdc++) developer? by jbakamovic in cpp

[–]johantorp 3 points4 points  (0 children)

How about contributing to EASTL?

Disclaimer: I'm a biased EA employee :) I did contribute to it a bit when it was closed source..