3 ms·

Noted. From my perspective it's the same class of issues as with using _t suffix for custom C types - also reserved, so technically not good, but trivial to fix

Noted. From my perspective it's the same class of issues as with using _t suffix for custom C types - also reserved, so technically not good, but trivial to fix if it ever causes any trouble. PS. In practice, the use of underscores, both single and double, as a name prefix is wide-spread. From the use of _foo notation to pass arguments to functions, to using _bar() to designate member functions that should be called under some sort of lock, to using __xxx for macros - I mean, yes, all this doesn't align with the C++ standard, but it exists, it's actively used in live code and it also leads to the coding habits that are hard to change. Hence the use of __f() in this particular library.

zabzonk 7y ago
> he use of underscores, both single and double, as a name prefix is wide-spread. Leading single underscores are OK at class scope, so OK for member variables or functions. They are not OK at global scope, in either C++ or C. And, yes it is wide-spread, as are many other dangerous bad practices. It's something that is easy not to do, and which has no worth, so why do it?
- apankrat 7y ago
  Because it's not a "dangerous bad practice". There are examples of actually bad and dangerous language misuse, but this is not one of them. It's mostly pedantry. Like using KiB instead of KB.
  - zabzonk 7y ago
    It is dangerous. If you (illegally) #define a reserved name in your own code and then include a standard header file that (legally) uses that name, the results can be almost impossible to diagnose. There is never any need to do it, so not doing it is not "pedantry", it is simple good practice. The rules about double-underscores exist for very good reasons.
    - apankrat 7y ago
      > the results can be almost impossible to diagnose Humor me - concote a case with a standard header using __f name in a way that will make a conflict with this particular __f() macro "almost impossible to diagnose". I can't think of any. Following overly broad rules that go against established practices without any due need is exactly that - pedantry. Look at it this way - if a language spec was serious about reserving the __ name prefix, it's not hard to enforce it at the compiler level. But it's been a while since this made it into a spec and yet it's not enforced. So whatever the good reasons were behind this bit of spec, they were not a strong enough of concern to warrant any practical enforcement.
      - jfk13 7y ago
        I haven't looked into what your macro definition would do to it, but just running grep -r '\b__f\b' /usr/include/ on my system shows a bunch of uses of this symbol. Looks like it's generally used as a parameter, though I also see it as a field name in a union, e.g. in /usr/include/math.h: __header_always_inline int __inline_signbitf(float __x) { union { float __f; unsigned int __u; } __u; __u.__f = __x; return (int)(__u.__u >> 31); } I wonder how the compiler likes it if you try to #include that header after you've defined a __f() macro?
      - gpderetta 7y ago
        If you look at a standard library implementation, they go to extreme pain to uglify their symbols not to conflict with the user namespace. If you encroach on the library namespace your code deserves to be broken.
  - saagarjha 7y ago
    > Like using KiB instead of KB. They mean different things.
    - deleted 7y ago
      [deleted]
    - Bjartr 7y ago
      Outside of the context of hard drives, KB is almost always used to mean KiB
  - brandmeyer 7y ago
    This detail is just one part of the library's broader disregard for the scope of names. One of the most difficult parts of managing large projects is dividing up the global namespace in a way that is equitable to all authors. This library has a number of naming problems: It claims names that are reserved for the compiler and runtime libraries. It puts names into the global namespace. Worse, it puts generic names like "parser" and "store" into the global namespace. It also claims an extremely broad category as its own project name (Serialization++? Seriously?). It doesn't matter how clever your particular library is. In total, the impact of those naming problems makes your library disrespectful to the broader C++ community.
    - apankrat 7y ago
      Get off your high horse and step away from the espresso machine. Readme> It's not meant to be an universal serialization library, but rather a real-life working example of one of many ways to do serialization. It's an extract from the existing code base. It is TRIVIAL to put the whole thing into a separate namespace. It's TRIVIAL to change the names if they really rub you the wrong way. The point of this repo is to show a _technique_ for doing serialization, and yet here you are fuming and nitpicking on petty details. > Disrepectful to the broader C++ community This is so ridiculous I'm not sure how this anything but trolling.
gpderetta 7y ago
Single underscores outside of the global namespace are perfectly fine in C++ (_foo is a common naming notation for members). Using double underscores in identifiers is dangerous as you risk colliding with implementation macros or builtin, but of course if you make the identifier long enough the risk is minimal. But defining a double underscore single letter identifier and the using it for a macro is really inexcusable.
- apankrat 7y ago
  __f is a questionable name for a macro. But it's a petty irrelevant detail. I can't fathom how anyone could seriously see this is as a subject worthy of a prolonged discussion. The repo is a demo for a serialization technique, yet only one comment out of 30 is on that. Can't say I'm shocked, but it is moderately disappointing.
  - gpderetta 7y ago
    Welcome to HN! That's what we like to do here. In all fairness that macro is a pretty prominent part of the library interface. (Also full disclosure, I've also used one letter macros in my c++ experiments and yes I'm moderately ashamed).
    - apankrat 7y ago
      Heh, yeah. It wasn't this bad in 2008 when I first got here... though I suspect it's more of a language issue. C++ tends to prompt a discussion of a poorer quality. Every second person is an senior expert that feels obliged to teach everyone else the true ways of the language. Hence all the focus on irrelevant minor fluff like here. Especially evident when compared to C threads, where nitpicks are of a far better quality and actually relevant.
      - ryandrake 7y ago
        It takes at least two to tango. It looks like you’re responding to this criticism very defensively. An initial simple “thanks for pointing that out” response could have probably avoided the whole thread. C++ tends to bring out the language lawyers because it is such a minefield of undefined, implememtation-defines, and unspecified behavior.
mike_hock 7y ago
> trivial to fix if it ever causes any trouble So your library exposes __foo or foo_t, a program depends on your library and some other library. Now a new standard comes out and adds __foo or foo_t to the standard library, and the program upgrades to the new standard. So far everything works. Now the other library upgrades to the new standard as well and uses standard __foo or foo_t. Now the program experiences weird linker errors or runtime undefined behavior. Trivial to fix.

zabzonk 7y ago

> he use of underscores, both single and double, as a name prefix is wide-spread. Leading single underscores are OK at class scope, so OK for member variables or functions. They are not OK at global scope, in either C++ or C. And, yes it is wide-spread, as are many other dangerous bad practices. It's something that is easy not to do, and which has no worth, so why do it?

apankrat 7y ago
Because it's not a "dangerous bad practice". There are examples of actually bad and dangerous language misuse, but this is not one of them. It's mostly pedantry. Like using KiB instead of KB.
- zabzonk 7y ago
  It is dangerous. If you (illegally) #define a reserved name in your own code and then include a standard header file that (legally) uses that name, the results can be almost impossible to diagnose. There is never any need to do it, so not doing it is not "pedantry", it is simple good practice. The rules about double-underscores exist for very good reasons.
  - apankrat 7y ago
    > the results can be almost impossible to diagnose Humor me - concote a case with a standard header using __f name in a way that will make a conflict with this particular __f() macro "almost impossible to diagnose". I can't think of any. Following overly broad rules that go against established practices without any due need is exactly that - pedantry. Look at it this way - if a language spec was serious about reserving the __ name prefix, it's not hard to enforce it at the compiler level. But it's been a while since this made it into a spec and yet it's not enforced. So whatever the good reasons were behind this bit of spec, they were not a strong enough of concern to warrant any practical enforcement.
    - jfk13 7y ago
      I haven't looked into what your macro definition would do to it, but just running grep -r '\b__f\b' /usr/include/ on my system shows a bunch of uses of this symbol. Looks like it's generally used as a parameter, though I also see it as a field name in a union, e.g. in /usr/include/math.h: __header_always_inline int __inline_signbitf(float __x) { union { float __f; unsigned int __u; } __u; __u.__f = __x; return (int)(__u.__u >> 31); } I wonder how the compiler likes it if you try to #include that header after you've defined a __f() macro?
    - gpderetta 7y ago
      If you look at a standard library implementation, they go to extreme pain to uglify their symbols not to conflict with the user namespace. If you encroach on the library namespace your code deserves to be broken.
- saagarjha 7y ago
  > Like using KiB instead of KB. They mean different things.
  - deleted 7y ago
    [deleted]
  - Bjartr 7y ago
    Outside of the context of hard drives, KB is almost always used to mean KiB
- brandmeyer 7y ago
  This detail is just one part of the library's broader disregard for the scope of names. One of the most difficult parts of managing large projects is dividing up the global namespace in a way that is equitable to all authors. This library has a number of naming problems: It claims names that are reserved for the compiler and runtime libraries. It puts names into the global namespace. Worse, it puts generic names like "parser" and "store" into the global namespace. It also claims an extremely broad category as its own project name (Serialization++? Seriously?). It doesn't matter how clever your particular library is. In total, the impact of those naming problems makes your library disrespectful to the broader C++ community.
  - apankrat 7y ago
    Get off your high horse and step away from the espresso machine. Readme> It's not meant to be an universal serialization library, but rather a real-life working example of one of many ways to do serialization. It's an extract from the existing code base. It is TRIVIAL to put the whole thing into a separate namespace. It's TRIVIAL to change the names if they really rub you the wrong way. The point of this repo is to show a _technique_ for doing serialization, and yet here you are fuming and nitpicking on petty details. > Disrepectful to the broader C++ community This is so ridiculous I'm not sure how this anything but trolling.

gpderetta 7y ago

Single underscores outside of the global namespace are perfectly fine in C++ (_foo is a common naming notation for members). Using double underscores in identifiers is dangerous as you risk colliding with implementation macros or builtin, but of course if you make the identifier long enough the risk is minimal. But defining a double underscore single letter identifier and the using it for a macro is really inexcusable.

apankrat 7y ago
__f is a questionable name for a macro. But it's a petty irrelevant detail. I can't fathom how anyone could seriously see this is as a subject worthy of a prolonged discussion. The repo is a demo for a serialization technique, yet only one comment out of 30 is on that. Can't say I'm shocked, but it is moderately disappointing.
- gpderetta 7y ago
  Welcome to HN! That's what we like to do here. In all fairness that macro is a pretty prominent part of the library interface. (Also full disclosure, I've also used one letter macros in my c++ experiments and yes I'm moderately ashamed).
  - apankrat 7y ago
    Heh, yeah. It wasn't this bad in 2008 when I first got here... though I suspect it's more of a language issue. C++ tends to prompt a discussion of a poorer quality. Every second person is an senior expert that feels obliged to teach everyone else the true ways of the language. Hence all the focus on irrelevant minor fluff like here. Especially evident when compared to C threads, where nitpicks are of a far better quality and actually relevant.
    - ryandrake 7y ago
      It takes at least two to tango. It looks like you’re responding to this criticism very defensively. An initial simple “thanks for pointing that out” response could have probably avoided the whole thread. C++ tends to bring out the language lawyers because it is such a minefield of undefined, implememtation-defines, and unspecified behavior.

mike_hock 7y ago

> trivial to fix if it ever causes any trouble So your library exposes __foo or foo_t, a program depends on your library and some other library. Now a new standard comes out and adds __foo or foo_t to the standard library, and the program upgrades to the new standard. So far everything works. Now the other library upgrades to the new standard as well and uses standard __foo or foo_t. Now the program experiences weird linker errors or runtime undefined behavior. Trivial to fix.