3 ms·

No defaulting to private is not backwards. It enforces having a reason to make something public, which is a stronger default when it comes to building well abst

No defaulting to private is not backwards. It enforces having a reason to make something public, which is a stronger default when it comes to building well abstracted, decoupled, modular code. C++ doesn't come from the web era, where you can push code filled with bugs and fix them over time in a process that's seamless and invisible to the user. C++ comes from a time when software couldn't be changed once it was shipped, and so it was more important to strive for integrity over raw ease of coding. Although I still don't see the argument for today's coding, as maintenance is the primary cost of web applications.

xerophtye 13y ago
precisely! The default private is because of encapsulation! By default, every thing is private and you only provide access to specific things.
- ygra 13y ago
  And yet, every class starts with public:, listing the public members. And in many cases the number of private things in the class is 1, for historical reasons due to how C++ (and C) manages "modules".
bad_user 13y ago
Precisely, C++ code is usually not riddled with all kinds of bugs and buffer overflows. </sarcasm> This argument is so backwards. Having a garbage collector or a VM that ensures memory access safety, now that's what contributes to less bugs. Enforcing the freaking default visibility of class members to be private, does not. If you try to make this argument, which defies common sense, then show me some numbers. And btw, good API design is not measured in the number of public members you have on a class.
- eropple 13y ago
  > Precisely, C++ code is usually not riddled with all kinds of bugs and buffer overflows. </sarcasm> Sarcasm aside: having more experience with C than C++, I find my C++ code rather significantly more resistant to buffer overflows, off-by-one errors, etc; it's when I'm interfacing with primarily C-based APIs that force me to do pointer math and so forth that I hurt myself. I don't have the confidence to write in C (fairly) quickly and correctly as opposed to C++. In this way C++ does come from that earlier era that the grandparent poster referred to: where Java didn't exist yet and the managed options weren't particularly fast, but C++ (even in its nascent form) could help you provide yourself tools for encouraging correctness that C could not. Today, it's a different story. The STL (particularly as of C++11) is advanced to the point where it's very possible to write code that is, relative to Java or other managed languages, generally very fast and definitely very portable, while retaining pretty solid guarantees of safety. And I either I or the compiler are more likely to either notice my mistakes, which I inevitably make, in C++ than C.
  - shmerl 13y ago
    You probably meant the stdc++, not the STL. But I agree, in C++11 one can use smart pointers which help avoiding many memory management pitfalls and make memory ownership mode more explicitly defined through the language itself.
    - wfunction 13y ago
      People nowadays never mean SGI (or anything other than the C++ standard library) when they say "STL", so it's a good time to stop correcting them.
      - shmerl 13y ago
        Still, it's not exactly correct. Unless you read STL as STandard Library.
    - eropple 13y ago
      In this case I did mean the STL-derived bits specifically. C++ collections, iterators and <algorithm> are awesome. When you're used to C for writing native code and your options are arrays, linked lists, or oh-god-I-hope-I-wrote-this-hashtable-correctly, this stuff is amazing. I guess they're not called the STL anymore, but I tend to use the term to refer to them specifically. I actually only very rarely use smart pointers in my main C++ project; my game has a simple lifecycle and wouldn't benefit from them much, though I could probably stand to use unique_ptr more than I do. The primary place I use them is to use std::auto_ptr to clean up after myself when dealing with try-catch blocks--I standardized on them before really understanding unique_ptr and my use of them is single-function-limited so I kept it consistent. The game itself is modeled on a stack-based state machine and I'm able to pretty easily reason about my object lifetimes within each state without smart pointers.
- Jormundir 13y ago
  bad_user why don't you go educate yourself and come back when you can make valuable comments. I've seen you trolling several posts now with comments that show your lack of Understanding of CS principles. In your attack on my comment, you're starting to argue against something I'm not talking about or implying. Good abstractions and code structure are created in a large part by being very careful about what's public. Defaulting to public helps a programming process that tends to ignore abstraction and structure, leading to heavy maintenance costs later. There's really no argument here, this is best practices established decades ago. It's fine to challenge establishments with new findings, but I find this article and your comments completely brain dead and unproductive because you're just lacking understanding of core principles.
  - nicolasgz 13y ago
    Every C++ class declaration ever looks like this: class Foo { public: stuff; private: other stuff; }; What's the point of private-by-default if everybody overrides it anyways?

xerophtye 13y ago

precisely! The default private is because of encapsulation! By default, every thing is private and you only provide access to specific things.

ygra 13y ago
And yet, every class starts with public:, listing the public members. And in many cases the number of private things in the class is 1, for historical reasons due to how C++ (and C) manages "modules".

bad_user 13y ago

Precisely, C++ code is usually not riddled with all kinds of bugs and buffer overflows. </sarcasm> This argument is so backwards. Having a garbage collector or a VM that ensures memory access safety, now that's what contributes to less bugs. Enforcing the freaking default visibility of class members to be private, does not. If you try to make this argument, which defies common sense, then show me some numbers. And btw, good API design is not measured in the number of public members you have on a class.

eropple 13y ago
> Precisely, C++ code is usually not riddled with all kinds of bugs and buffer overflows. </sarcasm> Sarcasm aside: having more experience with C than C++, I find my C++ code rather significantly more resistant to buffer overflows, off-by-one errors, etc; it's when I'm interfacing with primarily C-based APIs that force me to do pointer math and so forth that I hurt myself. I don't have the confidence to write in C (fairly) quickly and correctly as opposed to C++. In this way C++ does come from that earlier era that the grandparent poster referred to: where Java didn't exist yet and the managed options weren't particularly fast, but C++ (even in its nascent form) could help you provide yourself tools for encouraging correctness that C could not. Today, it's a different story. The STL (particularly as of C++11) is advanced to the point where it's very possible to write code that is, relative to Java or other managed languages, generally very fast and definitely very portable, while retaining pretty solid guarantees of safety. And I either I or the compiler are more likely to either notice my mistakes, which I inevitably make, in C++ than C.
- shmerl 13y ago
  You probably meant the stdc++, not the STL. But I agree, in C++11 one can use smart pointers which help avoiding many memory management pitfalls and make memory ownership mode more explicitly defined through the language itself.
  - wfunction 13y ago
    People nowadays never mean SGI (or anything other than the C++ standard library) when they say "STL", so it's a good time to stop correcting them.
    - shmerl 13y ago
      Still, it's not exactly correct. Unless you read STL as STandard Library.
  - eropple 13y ago
    In this case I did mean the STL-derived bits specifically. C++ collections, iterators and <algorithm> are awesome. When you're used to C for writing native code and your options are arrays, linked lists, or oh-god-I-hope-I-wrote-this-hashtable-correctly, this stuff is amazing. I guess they're not called the STL anymore, but I tend to use the term to refer to them specifically. I actually only very rarely use smart pointers in my main C++ project; my game has a simple lifecycle and wouldn't benefit from them much, though I could probably stand to use unique_ptr more than I do. The primary place I use them is to use std::auto_ptr to clean up after myself when dealing with try-catch blocks--I standardized on them before really understanding unique_ptr and my use of them is single-function-limited so I kept it consistent. The game itself is modeled on a stack-based state machine and I'm able to pretty easily reason about my object lifetimes within each state without smart pointers.
Jormundir 13y ago
bad_user why don't you go educate yourself and come back when you can make valuable comments. I've seen you trolling several posts now with comments that show your lack of Understanding of CS principles. In your attack on my comment, you're starting to argue against something I'm not talking about or implying. Good abstractions and code structure are created in a large part by being very careful about what's public. Defaulting to public helps a programming process that tends to ignore abstraction and structure, leading to heavy maintenance costs later. There's really no argument here, this is best practices established decades ago. It's fine to challenge establishments with new findings, but I find this article and your comments completely brain dead and unproductive because you're just lacking understanding of core principles.
- nicolasgz 13y ago
  Every C++ class declaration ever looks like this: class Foo { public: stuff; private: other stuff; }; What's the point of private-by-default if everybody overrides it anyways?