Earlier quoted context omitted.
Everything is a recipe for disaster one inheritance is in the picture :)
That's a blind, dogmatic position. Inheritance is a tool, as everything else.
Including all-public interfaces.
C++ Patterns: The Badge
151–160 of 160 posts
Re: C++ Patterns: The Badge
#152Earlier quoted context omitted.
> OOP also; I've seen so many crazy class architectures that could just be a handful of plain-old-functions, also, tons of "generic" numerical code with templates everywhere, where the only two possible instantiations are "float" and "double". Some people do really like to add useless complexity everywhere.
What's wrong with that? It seems like the easiest way to write code that works with either floats or doubles.
> It seems like the easiest way to write code that works with either floats or doubles.
You never really need to do that. In the rare cases you need to, once every five years or so, it is trivial to change your code.
Re: C++ Patterns: The Badge
#153Earlier quoted context omitted.
Doesn't subvert Device badges for me. Complete sample: template class Badge { friend T; Badge() {} }; template Badge FakeBadge() { struct Stub {}; return reinterpret_cast >(Stub()); }; class Device { public: static Badge getBadge() { return Badge (); } }; void needDeviceBadge(Badge badge) { } int main() { needDeviceBadge(Device::getBadge()); // no error needDeviceBadge(FakeBadge ()); // error! return 0; } g++ errors:…
It does, however, work fine if you use a proper "* (Badge * )&stub" cast.
Well, that's a problem in the C++ type system, isn't it; because it (effectively) constructs a value of type Badge, even though it's not a piece of code sitting in the Device class scope.
The rule should be that if the default constructor of T is not accessible in the scope, then any cast to T * or T & requires a diagnostic. Or something like that.
If I can allocate a suitably aligned buffer of sizeof (T) zeros, and then treat that as a T, I've effectively constructed a T.
Re: C++ Patterns: The Badge
#154Earlier quoted context omitted.
It does, however, work fine if you use a proper "* (Badge * )&stub" cast.
Isn't casting unrelated types undefined behavior?
Problem is that it doesn't require a diagnostic, and the actual behavior of casting one empty struct foo {} to another empty struct bar {} is likely harmless and portable.
Re: C++ Patterns: The Badge
#155Earlier quoted context omitted.
Isn't casting unrelated types undefined behavior?
Yes, in the standard it isn't defined, but on most--or maybe even all?--systems and compilers it's perfectly defined, since there is no reason why a compiler would layout two different empty structs in different ways; they're both empty anyways. Edit: Actually, from reading some of the other comments in the thread, the standard apparently specifies that empty structs are 1 byte in size, so technically they would both…
It's not defined on systems unless a document spells it out. However, the actual behavior can be deduced to be harmless from black-box testing. compiler source code and generate object code.
Re: C++ Patterns: The Badge
#156Earlier quoted context omitted.
> Python has a well-established convention of _underscore for intended-to-be-private members, with no enforcement, and it works fine. Python does not have access modifiers. C++ does. It makes absolutely no sense to write Python code in C++ while entirely oblivious to basic, age-old C++ features just because your background lies somewhere else and you failed or refused to learn even the basics. And you know what actua…
You keep accusing me of "failing to understand" or "refusing to learn" the "best practices" of using access specifiers. I understand them well, and I've experimented with their use in my own projects, and decided they're a minor complexity I don't need to bother with. And that decision has served me well. Dogmatic adherence to "best practices" is silly, even when people can agree on what they are. Learn them, yes, ev…
> and now every site out there takes 20 seconds to load with 10 little spinner icons while all the HTTP requests go out to their microservices on docker clusters, and everything requires a hundred-library-deep build stack
That’s just the cost of progress. Gotta break a few eggs to make an omelet. No pain, no gain. There are always casualties in war. Get with the times, grandpa.
Re: C++ Patterns: The Badge
#157Earlier quoted context omitted.
It does, however, work fine if you use a proper "* (Badge * )&stub" cast.
Well, that's a problem in the C++ type system, isn't it; because it (effectively) constructs a value of type Badge , even though it's not a piece of code sitting in the Device class scope. The rule should be that if the default constructor of T is not accessible in the scope, then any cast to T * or T & requires a diagnostic. Or something like that. If I can allocate a suitably aligned buffer of sizeof (T) zeros, and…
No, that's a good feature of the C++ type system, because it (effectively) allows the programmer to construct a value of type Badge, even if Device thinks it's okay to prevent that.
It would be better to do eg "return Device::private:get_badge()", but C++ defectively doesn't support that.
Re: C++ Patterns: The Badge
#158Earlier quoted context omitted.
> That's not how software development works ... ... in your setup. All shops are different. To each their own. There's no private/protected scaffolding in the Linux kernel to give the most obvious example.
Well last time I checked the Linux kernel was C and not C++, so that might explain why ;-). I don't know anything about kernel programming, but I assume that there's some very, very strict conventions about how the various parts of the Linux kernel interact, and nothing gets accepted for merging unless you follow them. This would be similar to imposing scope/visibility constraints at the language level, but consideri…
emm...
All we could say is that,
kernel programmers'/reviewers' technical background is much higher/better than average python programmers'/reviewers'.
Seen too many times these "Mr/Mrs. More or less" engineers simply modify the internal states as short cuts to compensate real engineering.
Re: C++ Patterns: The Badge
#159Earlier quoted context omitted.
> Python has a well-established convention of _underscore for intended-to-be-private members, with no enforcement, and it works fine. Python does not have access modifiers. C++ does. It makes absolutely no sense to write Python code in C++ while entirely oblivious to basic, age-old C++ features just because your background lies somewhere else and you failed or refused to learn even the basics. And you know what actua…
You keep accusing me of "failing to understand" or "refusing to learn" the "best practices" of using access specifiers. I understand them well, and I've experimented with their use in my own projects, and decided they're a minor complexity I don't need to bother with. And that decision has served me well. Dogmatic adherence to "best practices" is silly, even when people can agree on what they are. Learn them, yes, ev…
I strongly agree with your sentiment that 'best practices' act as a replacement for critical thought, and lead to messy, overcomplicated and flawed architectures. Every "best practice" would be best delivered with a criteria list of when it's actually applicable, and a shortcomings list of situations where its not.
Re: C++ Patterns: The Badge
#160Earlier quoted context omitted.
> OOP also; I've seen so many crazy class architectures that could just be a handful of plain-old-functions, also, tons of "generic" numerical code with templates everywhere, where the only two possible instantiations are "float" and "double". Some people do really like to add useless complexity everywhere.
What's wrong with that? It seems like the easiest way to write code that works with either floats or doubles.
Eh... I have seen the same in Rust. People write tests with i32. i32 implements the Copy trait which means your can blindly clone it all over the place. When you try using some libraries with String or anything else they don't work.