3 ms·

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 pedantr

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.

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.