Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Can I just say that the Ftxui source code is beautifully laid out, and is much more readable than I am used to seeing in Free Software projects? This library has absolutely exemplary presentation. [Edit: I see it uses clang-format. More projects should use that.]

Overuse of shared_ptr (what we call "Java Disease") is probably forgiveable in a UI toolkit. Even protected data members, often frowned upon in O-O circles, are probably OK, here. A note to the author (and, you know, everybody): the "#ifndef xxxx/#define xxxx" two-step is no longer necessary or useful; "#pragma once" is supported everywhere now.



I am terrified by #pragma once due to issues with relative include paths sometimes being mixed with absolute ones in various situations (none of which I personally cause). I recommend reading this post on StackOverflow by a GCC/autoconf maintainer on why he believes it is actually impossible to make it work correctly. I imagine it is thereby not in the standard, despite being widely implemented, "for good reason".

https://stackoverflow.com/a/34884735

> (Historical note: The only reason I didn't rip #pragma once and #import out of GCC when I had the authority to do so, ~12 years ago, was Apple's system headers relying on them. In retrospect, that shouldn't have stopped me.)


I read that SO page.

I find the argument unpersuasive for the same reasons commenters there did. The case for C++ is stronger because the set of current C++ compilers (which nowadays have integrated pre-processor) is much smaller than of C compilers that could be encountered in the wild.

Doing complicated things with header files and paths is inherently fragile, pragma or no pragma. So, don't do them. Absent fragile header file or include-path games, there is no problem.

In the foreseeable future, #include will begin to fade from C++ code, and with it #pragma once, include guards, and any sort of worries about them. (Then we might start to worry about module name collisions, instead.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: