#ifndef — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #ifndef, aggregated by home.social.
-
It's a bit annoying that the version macro was not there from the beginning. If you don't ship an openxr.h with your source code, I'd recommend putting something like this in your code:
```
#ifndef XR_API_VERSION_1_0
#define XR_API_VERSION_1_0 XR_MAKE_VERSION(1, 0, XR_VERSION_PATCH(XR_CURRENT_API_VERSION))
#endif
``` -
It's a bit annoying that the version macro was not there from the beginning. If you don't ship an openxr.h with your source code, I'd recommend putting something like this in your code:
```
#ifndef XR_API_VERSION_1_0
#define XR_API_VERSION_1_0 XR_MAKE_VERSION(1, 0, XR_VERSION_PATCH(XR_CURRENT_API_VERSION))
#endif
``` -
It's a bit annoying that the version macro was not there from the beginning. If you don't ship an openxr.h with your source code, I'd recommend putting something like this in your code:
```
#ifndef XR_API_VERSION_1_0
#define XR_API_VERSION_1_0 XR_MAKE_VERSION(1, 0, XR_VERSION_PATCH(XR_CURRENT_API_VERSION))
#endif
``` -
It's a bit annoying that the version macro was not there from the beginning. If you don't ship an openxr.h with your source code, I'd recommend putting something like this in your code:
```
#ifndef XR_API_VERSION_1_0
#define XR_API_VERSION_1_0 XR_MAKE_VERSION(1, 0, XR_VERSION_PATCH(XR_CURRENT_API_VERSION))
#endif
``` -
It's a bit annoying that the version macro was not there from the beginning. If you don't ship an openxr.h with your source code, I'd recommend putting something like this in your code:
```
#ifndef XR_API_VERSION_1_0
#define XR_API_VERSION_1_0 XR_MAKE_VERSION(1, 0, XR_VERSION_PATCH(XR_CURRENT_API_VERSION))
#endif
``` -
CW: C/C++ hot take
as far as I can tell header files have no advantages over just putting your forward declarations at the top of your
.c/.cppfileslike it’s bad enough that you have to declare everything twice, but putting your second declaration in a totally separate file that you have to remember to keep updated? that will definitely bite you in the ass
also the existence of header files requires you to use some arcane rube goldberg build system like
makethat’s held together with chewing gum and rubber bands, and probably isn’t even portable. when instead you could literally just include your.c/.cppfiles directly and bypass that whole processand it’s not even hard to write a
.c/.cppfile that doesn’t need a headerfile:// inside of funcs.cpp: #ifndef FUNCS_CPP #define FUNCS_CPP int someFunc(); int someFunc() { return 666; } #endif // and you just import it like this: #include "./funcs.cpp"like why didn’t people figure this out decades ago. who even thought that headerfiles were a good idea. maybe I’m missing something but they genuinely seem to have only downsides and aren’t even the obvious way to solve this problem?
-
CW: C/C++ hot take
as far as I can tell header files have no advantages over just putting your forward declarations at the top of your
.c/.cppfileslike it’s bad enough that you have to declare everything twice, but putting your second declaration in a totally separate file that you have to remember to keep updated? that will definitely bite you in the ass
also the existence of header files requires you to use some arcane rube goldberg build system like
makethat’s held together with chewing gum and rubber bands, and probably isn’t even portable. when instead you could literally just include your.c/.cppfiles directly and bypass that whole processand it’s not even hard to write a
.c/.cppfile that doesn’t need a headerfile:// inside of funcs.cpp: #ifndef FUNCS_CPP #define FUNCS_CPP int someFunc(); int someFunc() { return 666; } #endif // and you just import it like this: #include "./funcs.cpp"like why didn’t people figure this out decades ago. who even thought that headerfiles were a good idea. maybe I’m missing something but they genuinely seem to have only downsides and aren’t even the obvious way to solve this problem?
-
CW: C/C++ hot take
as far as I can tell header files have no advantages over just putting your forward declarations at the top of your
.c/.cppfileslike it’s bad enough that you have to declare everything twice, but putting your second declaration in a totally separate file that you have to remember to keep updated? that will definitely bite you in the ass
also the existence of header files requires you to use some arcane rube goldberg build system like
makethat’s held together with chewing gum and rubber bands, and probably isn’t even portable. when instead you could literally just include your.c/.cppfiles directly and bypass that whole processand it’s not even hard to write a
.c/.cppfile that doesn’t need a headerfile:// inside of funcs.cpp: #ifndef FUNCS_CPP #define FUNCS_CPP int someFunc(); int someFunc() { return 666; } #endif // and you just import it like this: #include "./funcs.cpp"like why didn’t people figure this out decades ago. who even thought that headerfiles were a good idea. maybe I’m missing something but they genuinely seem to have only downsides and aren’t even the obvious way to solve this problem?
-
CW: C/C++ hot take
as far as I can tell header files have no advantages over just putting your forward declarations at the top of your
.c/.cppfileslike it’s bad enough that you have to declare everything twice, but putting your second declaration in a totally separate file that you have to remember to keep updated? that will definitely bite you in the ass
also the existence of header files requires you to use some arcane rube goldberg build system like
makethat’s held together with chewing gum and rubber bands, and probably isn’t even portable. when instead you could literally just include your.c/.cppfiles directly and bypass that whole processand it’s not even hard to write a
.c/.cppfile that doesn’t need a headerfile:// inside of funcs.cpp: #ifndef FUNCS_CPP #define FUNCS_CPP int someFunc(); int someFunc() { return 666; } #endif // and you just import it like this: #include "./funcs.cpp"like why didn’t people figure this out decades ago. who even thought that headerfiles were a good idea. maybe I’m missing something but they genuinely seem to have only downsides and aren’t even the obvious way to solve this problem?
-
CW: C/C++ hot take
as far as I can tell header files have no advantages over just putting your forward declarations at the top of your
.c/.cppfileslike it’s bad enough that you have to declare everything twice, but putting your second declaration in a totally separate file that you have to remember to keep updated? that will definitely bite you in the ass
also the existence of header files requires you to use some arcane rube goldberg build system like
makethat’s held together with chewing gum and rubber bands, and probably isn’t even portable. when instead you could literally just include your.c/.cppfiles directly and bypass that whole processand it’s not even hard to write a
.c/.cppfile that doesn’t need a headerfile:// inside of funcs.cpp: #ifndef FUNCS_CPP #define FUNCS_CPP int someFunc(); int someFunc() { return 666; } #endif // and you just import it like this: #include "./funcs.cpp"like why didn’t people figure this out decades ago. who even thought that headerfiles were a good idea. maybe I’m missing something but they genuinely seem to have only downsides and aren’t even the obvious way to solve this problem?
-
@funkylab it’s really to do with it not being standardised more than anything else. Like what is the expectation of preprocessing the following file lol.h
#ifndef foo
#define foo
#else
#pragma once
#endif
#include "lol.h"
YoIs it a single “Yo” or two lines of “Yo”?
If it was defined that it needed to be the first thing in a file following whitespace, I think i’f be fine with it.
-
@funkylab it’s really to do with it not being standardised more than anything else. Like what is the expectation of preprocessing the following file lol.h
#ifndef foo
#define foo
#else
#pragma once
#endif
#include "lol.h"
YoIs it a single “Yo” or two lines of “Yo”?
If it was defined that it needed to be the first thing in a file following whitespace, I think i’f be fine with it.
-
@funkylab it’s really to do with it not being standardised more than anything else. Like what is the expectation of preprocessing the following file lol.h
#ifndef foo
#define foo
#else
#pragma once
#endif
#include "lol.h"
YoIs it a single “Yo” or two lines of “Yo”?
If it was defined that it needed to be the first thing in a file following whitespace, I think i’f be fine with it.
-
@funkylab it’s really to do with it not being standardised more than anything else. Like what is the expectation of preprocessing the following file lol.h
#ifndef foo
#define foo
#else
#pragma once
#endif
#include "lol.h"
YoIs it a single “Yo” or two lines of “Yo”?
If it was defined that it needed to be the first thing in a file following whitespace, I think i’f be fine with it.
-
@funkylab it’s really to do with it not being standardised more than anything else. Like what is the expectation of preprocessing the following file lol.h
#ifndef foo
#define foo
#else
#pragma once
#endif
#include "lol.h"
YoIs it a single “Yo” or two lines of “Yo”?
If it was defined that it needed to be the first thing in a file following whitespace, I think i’f be fine with it.
-
@tknarr it's c
c23 has a way to mimick visibility, by building with `-Dmylib_private` and having:
```c
#ifndef mylib_private
#define mylib_private [[deprecated("private member")]]
#endif
```
but tbh even without that it's also possible to just say "do not touch any undocumented field, you've been warned" -- it's not like c doesn't already have api constraints that live in documentation (e.g. "this pointer may/may-not be NULL"), the less of those we have the better but one step at a time with improving semantics -
@swags
most of c++'s compile time include costs is template instantiation, and those can't really be "opaque" anyway, and a better solution to it is to modularize your api, and to https://include-what-you-use.org/
headers should only include other headers if they *need* the definitions that are in those headers. if your types or functions don't, then you include the other header in the translation unit that does -- yes, a lot of people include random things in the header because they use it in the c file, but that doesn't make it a good practice
and yes, you can also do some sort of polymorphism by making types opaque and changing the definition based on a backend, but that's an exception rather than a rule
"hiding things from the user" is not worth the mess and runtime costs you get from it, now every structure needs to be heap allocated, now every public field needs to have a getter and setter, your library is twice as painful to use, unnecessarily slower, for a small benefit on the general case
if i intend data to be poked at, i document it, otherwise don't touch it. in c23 you can even go a step further:
```c
#ifndef mylib_private
# define mylib_private [[deprecated("private field")]]
#endif
```
now you compile your code with `-Dmylib_private`, but clients of the library would need to actively bypass compiler warnings to do stupid shit, and if you really really want, pre c23, you can even do things like wrapping private data in a `.private` struct field
making the whole struct opaque doesn't just impact "users can't touch it", it impacts your whole api, adds runtime constraints and limitations, and complicates memory management in many cases -
-
@ayba to avoid features creep, I would say. We don't need `#pragma once`, because `#ifndef` already solves that problem. Keeping things simple (in the scientific sense of "composed of fewer elements") is the spirit of C. There are already many other languages that provide tons of features and many different ways to do the same thing, I'm glad C sticks to its specificity.
-
@tomasekeli It’s kind of ugly, but also kinda not?
It’s effectively the same thing as the #ifndef trick used by C and C++ for 3 decades.
-
Good news for people who may have repeatedly hit this panic when trying to install #OpenBSD in some pathological VM configs with an emulated legacy IDE CD-ROM drive.
"wdc_atapi_start: not ready, st = 50
Jonathan Matthew (jmatthew@) has found and fixed this in #OpenBSD -current, will be in an upcoming snapshot.
jmatthew@ modified src/arch/amd64/conf/RAMDISK: Add acpitimer so we get a working delay function on some (virtual) machines that lack acpihpet. This fixes crashes when installing from emulated IDE CD drives, as reported most recently by Nicole Findlay.
ok mlarkin@
jmatthew@ modified src/sys/dev/acpi/acpi.c: Move the code to attach acpitimer outside #ifndef SMALL_KERNEL so we can make the clock/delay setup on ramdisk kernels more like GENERIC.
ok mlarkin@
Context: https://marc.info/?l=openbsd-bugs&m=174780097017194&w=2
-
@jaromil Ran it manually, and it generated a file with the #ifndef __ASSETS_H__ #def __ASSETS_H__ and nothing else in the file, which causes a different error. I'm on Arch, have quite a bit of experience compiling code from various projects, but I don't know enough about the build process here to figure out why it's making essentially a blank file (with no #endif)
-
Discover how conditional compilation directives can enhance your C programming skills. Learn to use #ifdef, #ifndef, #undef, #if, #else, #elif, and #endif to create more flexible and efficient code. Unlock the power of the C preprocessor!
https://teguhteja.id/conditional-compilation-directives-unlock-c-preprocessor-power/
