Hacker News Reader

Comment by flohofwoe | Hacker News Reader

`#pragma once` is not a panacea, it can still lead to double inclusion in scenarios where the same include file is accessible under different path names (granted, that's a very esoteric scenario). Besides, `#pragma once` is neither part of the C nor C++ standard. It's just a common convention between compiler vendors - so technically any code that uses pragme once as the only include guard is not standard C or standard C++ (but tbf, hardly any real-world code is fully standard compliant).

Typedef'ing common types to your own type names is absolutely fine as long as it is unlikely to collide with the typedefs of other libraries in the same project.

View on HN

> Typedef'ing common types to your own type names is absolutely fine as long as it is unlikely to collide with the typedefs of other libraries in the same project.

I read the parent post as indicating that "this is C++; we spell this as `using Foo = Bar;` now." Type aliases (or namespace aliases, or using-declarations) are not dead, but the typedef keyword in C++ is largely only retained for backwards compatibility.

The core issue here is that type aliases add a layer of indirection. That can be useful if the user shouldn't need to know the implementation details and can interact with said type purely through the API -- do I care if a returned Handle is a pointer, an int, or some weird custom class? Everyone is used to file descriptors being ints, but you aren't going to do math on them.

#pragma once is a de-facto standard now, and if it’s not in the actual standard then that says more about the failings of the standard writers than anything else.

And there’s absolutely no reason to typedef _standard_ int types anymore. Not in C, and definitely not in C++. That’s just crusty old practices. Maybe if you want to have nice short types like u8, i8, etc, I can understand that. But SlangUint32 is just ugly.

Pragma once isn't in the standard because there are cases where it doesn't work and to standardize it means making the standard significantly longer to catorgize when the compiler is allowed to not work. I've been in discussions and they all conclude it is not worth the effort

Pragma once is widely enough accepted that anyone who argues against its use for that purpose better either be able to tell me the compilers it doesn’t work on, or I’m going to assume they’re being pedantic for the hell of it.

And honestly, anyone who relies on the scenarios Pragma once fails in (Compiling off network shared and symlinks) should really fix those monstrous issues instead. The places Pragma once trips up in are likely to be issues for detecting modifications in incremental builds anyway.

There used to be a couple holdouts, but all major C++ compilers have supported it for years (https://en.wikipedia.org/wiki/Pragma_once).

Prarma once works in the vast majority of cases. However there are some rare ones where it fails. Every attempt to fix those last ones breaks some other rare case or profilings shows significant compile time increases.

use pragma once where it works in internal code but never in headers you ship to someone else is a simple rule that should work well enough.

> However there are some rare ones where it fails.

As I said in my previous comment, those cases are very very often cases where the compialtion model is broken, and it's held together by luck.

> Every attempt to fix those last ones breaks some other rare case

My experience (and I have experiences of this) have been that the cases where pragma once fails, other tools (source control, built tools) cause "random" problems that usually are hand waved away with "oh that problem, just run this other makefile target that someone has put together to clear that file and rebuild".

> or profilings shows significant compile time increases.

Again, my experience here has been that the compile time change is usually a result of a broken project model, and that there are other gotchas like "oh you can only include files a.h and c.h but if you include b.h then you'll break the internal build tool". Also, that taking the hit to make your build correct unlocks optimisations that weren't possible before.

Also, the projects that have these kinds of warts are usually allergic to doing anything new whatsoever, making any changes or improvements, upgrading compilers and libraries. I suspect using C++17 is enough to scare them off in many cases.

If it's good enough for QT or LLVM, it's good enough for me.

It isn't luck - I know exactly what I did to my package manage to get that file installed into two different locatian. I know exactly which -I options I passed to the compiler causes that one file to be found in different locations depending on quotes or brackets to be used. And it works great if I don't use pragma.

i also know why I had to do that aweful abuse to what anyone sane would call wholesome. I don't like it but there are other things going on and I don't want to talk about it anymore.

I've been using #pragma once in my C++ libraries for a decade and nobody ever reported any problem with that. I did get bug report about using perfectly standard C++ features that were not properly implemented in some compilers.

> the same include file is accessible under different path names (granted, that's a very esoteric scenario)

And most likely a build system problem anyway if, say, different versions of the same library get included in your build.

I use it and ran into issuses when I put a file into two different locations using my package manager. The reason I wanted a file in two different locations is something I don't want to talk about.

Reply on news.ycombinator.com