4 ms·

Spoken like a true c++ fanatic. Good encapsulation does not require splitting things up in different files that are later conditionally merged back together by

by Too 11y ago

Spoken like a true c++ fanatic. Good encapsulation does not require splitting things up in different files that are later conditionally merged back together by a dumb non language aware text pre processor. Other languages manages this fine without it. And "Template instantiation"? Thats an implementation detail I don't want to think about. C++ does have its nice parts and it does have its uses but some parts truly are shit, get out of the Stockholm syndrome and admit it.

melted 11y ago
You don't have to split, though. You can put all your code in the header file. Your compile times will suck mightily, but you can do it, if managing headers is such a burden.
roel_v 11y ago
Call me a barbarian, but I like having the API separate from the implementation. OK there are some 'private: struct MyImpl* _impl;' things in headers, and yes templates (but you can put those in a .inl file and be on your merry way...) but overall - I much prefer .h/.cpp over .java or .cs. Sure other languages 'manage' it fine. And if you want, you can put everything in your headers in C++, there's hardly any 'need' for .cpp files. Of course it will blow up your compile times, especially without precompiled headers (which are a pita with gcc, and relatively recent there too - gcc only started supporting them in 2006).
a-nikolaev 11y ago
Can't agree more. IMHO, this Stockholm syndrome / religious cultist mentality is so horrible, the most horrible thing about C++.. Don't get me wrong, I can forgive all shortsighted design choices and all the bullshit that piled up over the years. Nothing is perfect, true. But what C++ does to otherwise intelligent people.. This technological enslavement is just fascinating.
Ace17 11y ago
No need to be rude! Let's get this straight: I'm not advocating for the preprocessor here. I will happily put it in the trashbin where it belongs as soon as I have support for modules in C++ (By the way, 90% of the code I write is written in the D programming language, which has modules, and no preprocessor). I'm advocating for interface files. Whatever mechanism you use, you still need a way to separate interface files from implementation files. Interface files can be header files, they can be java files containing a single java 'interface', they can be "D interface" files (.di). It doesn't matter which mechanism you use for this, as long as you have a way for your caller not to depend on the implementation of callee (which might, for example, directly depend on a specific audio API, for example). My point is, if you want the caller to be properly isolated from the implementation of the callee, having to maintain signatures in an interface file is unavoidable.

by Too 11y ago

melted 11y ago

You don't have to split, though. You can put all your code in the header file. Your compile times will suck mightily, but you can do it, if managing headers is such a burden.

roel_v 11y ago

Call me a barbarian, but I like having the API separate from the implementation. OK there are some 'private: struct MyImpl* _impl;' things in headers, and yes templates (but you can put those in a .inl file and be on your merry way...) but overall - I much prefer .h/.cpp over .java or .cs. Sure other languages 'manage' it fine. And if you want, you can put everything in your headers in C++, there's hardly any 'need' for .cpp files. Of course it will blow up your compile times, especially without precompiled headers (which are a pita with gcc, and relatively recent there too - gcc only started supporting them in 2006).

a-nikolaev 11y ago

Can't agree more. IMHO, this Stockholm syndrome / religious cultist mentality is so horrible, the most horrible thing about C++.. Don't get me wrong, I can forgive all shortsighted design choices and all the bullshit that piled up over the years. Nothing is perfect, true. But what C++ does to otherwise intelligent people.. This technological enslavement is just fascinating.

Ace17 11y ago

No need to be rude! Let's get this straight: I'm not advocating for the preprocessor here. I will happily put it in the trashbin where it belongs as soon as I have support for modules in C++ (By the way, 90% of the code I write is written in the D programming language, which has modules, and no preprocessor). I'm advocating for interface files. Whatever mechanism you use, you still need a way to separate interface files from implementation files. Interface files can be header files, they can be java files containing a single java 'interface', they can be "D interface" files (.di). It doesn't matter which mechanism you use for this, as long as you have a way for your caller not to depend on the implementation of callee (which might, for example, directly depend on a specific audio API, for example). My point is, if you want the caller to be properly isolated from the implementation of the callee, having to maintain signatures in an interface file is unavoidable.