OSDev.org

When you develop an object file (.o) as part of a big application, there is one bad thing with C++:
You must put much of the code into header files. This thwarts the OOP principles like encapsulation/hiding.

Do you know about any OOP language who doesn't do that?

Greetings
Peter

I'm not clear what code needs to go in header files. Could you elucidate?

iansjack wrote:I'm not clear what code needs to go in header files. Could you elucidate?

I mean the private parts of a class (I count variable definitions as code here.) which have to go into a header file.

Furthermore I quote http://yosefk.com/c++fqa/defective.html
"In naturally written C++ code, changing the private members of a class requires recompilation of the code using the class."

I think there must be better OOP solutions. "Better" here means not having the above problems.

Greetings
Peter

Ah. I see what you're on about. I wouldn't define variable declarations as "code", but I see what you mean about encapsulation.

Surely the Pimpl Idiom deals with this problem?

PeterX wrote:Do you know about any OOP language who doesn't do that?

Languages like Java and C# solved this problem by having a bytecode format that includes all of the necessary metadata about classes.

Languages like Python solve this problem by representing nearly everything with a flexible map datastructure - you don't need to know what a class or even a superclass looks like at a compile time (and Python does compile, so it has a compile time) if you rely on duck typing and your methods and members are identified by strings at runtime.

C++ suffers from being purely textual in its compilation. The compiler needs to know what functions and members exist in a class so it can call the right offset into a vtable or whatever, but there's no encapsulated module format that can hide away the code and provide the compiler only a parseable machine representation of that information.

Not sure if you're looking for an alternative language, but I just saw mention of some in chat, & thought I'd pass it on.

incidentally yesterday i've stumbuled upon and took a brief look at some of these newfangled "c replacement" languages: zig, odin, v. i've also learned about nim, but it is my understanding nim's not so newfangled albeit looks quite nice.
there's a notable hole between c and something like rust, that's where these fit in

Nim looks the most mature and (I guess) suitable. "Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula." https://nim-lang.org/

The other 3 highlight their simplicity above all else. I don't know if that's what you'd want if you started with C++. Links because I have them handy: https://vlang.io/ http://odin-lang.org/ https://ziglang.org/

eekee wrote:Not sure if you're looking for an alternative language, but I just saw mention of some in chat, & thought I'd pass it on.

incidentally yesterday i've stumbuled upon and took a brief look at some of these newfangled "c replacement" languages: zig, odin, v. i've also learned about nim, but it is my understanding nim's not so newfangled albeit looks quite nice.
there's a notable hole between c and something like rust, that's where these fit in

Nim looks the most mature and (I guess) suitable. "Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula." https://nim-lang.org/

The other 3 highlight their simplicity above all else. I don't know if that's what you'd want if you started with C++. Links because I have them handy: https://vlang.io/ http://odin-lang.org/ https://ziglang.org/

These are some interesting suggestions.

1.) I already checked and excluded for various reasons: Forth, Rust, Go, D, normal Oberon, V.

2.) I also think that these are powerful but are too unpopular: Ada2012, ActiveOberon, Simula.
And these have difficult syntax for many programmers: Scheme, Smalltalk.
EDIT: I have to explain this: I want to make a open source community-based project.

3.) I will check the three [four] suggestions and Java.
The two languages that stick, are: C# and Python. As mentioned by klange.

Thanks to eekee and klange.

Happy hacking
Peter

Oh yeah, the pursuit of popularity is constraining. I almost cited 9front as an example of a thoroughly non-standard system which has nonetheless gained a small crowd, but then I remembered its status as a fork of Thompson and Ritchie's work gives it a big advantage. Despite that advantage, it's only gained a small crowd so far. Attempts to keep "Labs Plan 9"* alive and raise the popularity of Inferno* are not doing much better.

*: Thomson and Ritchie's original non-Unix OSs. 9front is forked from Plan 9.

You're welcome!

Would you elaborate on why the Pimpl idiom doesn't solve your "problem", or what your "problem" actually is?

Because most of the "solutions" mentioned here have their own set of "problems" with encapsulation, just a different kind of them...

Solar wrote:Would you elaborate on why the Pimpl idiom doesn't solve your "problem", or what your "problem" actually is?

Because most of the "solutions" mentioned here have their own set of "problems" with encapsulation, just a different kind of them...

Yes, there are problems with the solutions, too. That's normal.

I am still investigating pimpl. I'm using Python right now. I must emphasize that this is not for system programming.(I think in "General programming" forum it's ok to post about non-system-programming?)

Thanks to everyone.
Peter

PeterX wrote:I am still investigating pimpl.

CppReference.com's piece on the pattern.

Solar wrote:

PeterX wrote:I am still investigating pimpl.

CppReference.com's piece on the pattern.

I quote from that page:

pImpl breaks this compilation dependency; changes to the implementation do not cause recompilation. Consequently, if a library uses pImpl in its ABI, newer versions of the library may change the implementation while remaining ABI-compatible with older versions.

That's indeed a solution to my problem. Thanks.

Greetings
Peter

Note that C++ does not specify a stable ABI in the first place; ABI compatibility is implementation-defined. This means that changes in compiler, yes even a different compiler version, can make your libraries incompatible.

This is most pronounced when looking at Windows: A C++ library compiled with the MinGW compiler won't work with VisualC, and vice versa. I remember this being quite a hassle during GCC's 3.x version run as well, which brought numerous ABI changes.

Imagine what happens when a library offers a function call taking a std::string argument. The implementation of std::string that the library was "seeing" during compilation might be different from the one the client is "seeing" during compilation...

That is why many libraries written in C++ internally provide a C interface externally. Utility libraries, like Boost, being the obvious exception.