reserved identifier violation

[elfring]

I would like to point out that identifiers like "_DGRAMCLIENT_H" and "_SELECT_H" do not fit to the expected naming convention of the C++ language standard. Would you like to adjust your selection for unique names?

[dermesser]

Resolved in 96811c5. Thanks for noticing, I didn't know it was against the standard.

[elfring]

Thanks for your software correction.

How do you think about to make your include guards not only standard-compliant but also really unique by appending a kind of UUID?

[dermesser]

Isn't #pragma once a better solution here? (https://en.wikipedia.org/wiki/Pragma_once) It's supported by all major implementations and in general better than include guards. Or is there any advantage of UUID'd include guards over the pragma?

[elfring]

The technique "#pragma once" is a popular compiler extension. You can choose by your build specification eventually if you prefer its service over standard-compliance.

[dermesser]

well, then I think I'll migrate the files to using the once pragma.

[elfring]

How do you think about to provide build options so that the users can decide on their own which compiler extensions will be accepted for their software generation?

[dermesser]

How would you do that? Like this? (alternatives using -DUSE_ONCE_PRAGMA)

# ifdef USE_ONCE_PRAGMA
# pragma once
# else
# define LIBSOCKET_STREAMCLIENT_H
# endif

[elfring]

I would prefer an approach like the following which could even be generated by a special macro.

#ifdef LIBSOCKET_USE_PRAGMA_ONCE
#  pragma once
#else
#  ifndef LIBSOCKET_STREAMCLIENT_H_UUID
#  define LIBSOCKET_STREAMCLIENT_H_UUID
#endif

A consistent use of your project name as a prefix might help at some places.

[dermesser]

Would it actually have disadvantages only to use #pragma once? I don't see any cases in which the compiler doesn't support it; all important Linux/Unix compilers support it (GCC, LLVM/clang, ICC). Using two alternatives with the exactly same effect in 99.9% of all cases doesn't make sense, I think. And the Pragma solution is the one connected with less work.

[elfring]

I guess that this detail matters in the choice between strict standard-compliance and occasional use of "nice" compiler extensions. I assume that the work difference is questionable if the relevant preprocessor code can be automatically generated by a specific macro.

[dermesser]

Why introduce complicated macros when the alternative, the once pragma, is a quasi-standard? I hink that the argument "not a standard" is not sufficient.

[elfring]

I disagree here. The compilers let their users choose by parameters to which "standard" the source code should be interpreted. It is your design decision if you would like to provide the users of your software library a similar freedom.

[elfring]

Would you like to delete the leading underscores from a variable name like "__verbose_errno_save"?

[elfring]

I would like to add another thought for your interest in the construct "#pragma once". Do you care for a "branding" of your source files?

[dermesser]

Sorry, what do you mean with "branding" in this context? And btw, I don't have a special interest in #pragma once; I'm also fine with include guards. And if you want, you also may append GUIDs. I just don't want to do that work all by myself :P