Is the definition/declaration model all that important?

Started by
19 comments, last by Sc4Freak 16 years, 2 months ago
Quote:Original post by F-Kop
I've been searching for a while for a new language to use, mostly for Win32 programs. The more I research, the more I realize that C++, which I've been using for years, fits my needs more than any other language out there. At least of the ones I've seen, which is a lot.


I'm sorry, I have to bring this up. This doesn't have a THING to do with your question so why did you include it? You could have simply left all that out, asked your question, and been done. But you did say it and now it has me wondering your needs are that you think only C++ can fill them. So, why C++?

C++: A Dialog | C++0x Features: Part1 (lambdas, auto, static_assert) , Part 2 (rvalue references) , Part 3 (decltype) | Write Games | Fix Your Timestep!

Advertisement
One of the main reasons for the C++ compilation model is that Stroustrup wanted the early C++ compilers to work with linkers designed for C, since a linker is a non-trivial bit of software and being able to use C linkers (which already had well tested implementations on just about every platform) would make it much easier to port C++ to many different platforms. In fact the first C++ compiler generated C code and then used C compilers and linkers which meant it could easily be ported to any platform that had a C compiler and linker, which is pretty much the same thing as saying 'any platform'.

The Design and Evolution of C++ talks about this and helps explain many of the other idiosyncracies of C++ which can seem strange or arbitrary without knowing the language's history.

Game Programming Blog: www.mattnewport.com/blog

Quote:Original post by Oluseyi
Quote:Original post by F-Kop
Another thing that I often see questions about is hiding private members of classes. If there is no header to read, then all members are hidden. The only downfall to this is that documentation becomes more of a necessity for libraries that don't include source code.

You can ship C++ headers that exclude private members. They just provide interface declarations, after all.


Yep. You can do it in several ways, too.

1) Simply compile your code, then erase the private members from the header. Ship the modified header and the object file. This assumes that your intent is to provide a closed-source library.

2) Similarly, use the preprocessor:

foo.h
#ifndef FOO_H#define FOO_Hclass Foo {  #include "foo_internals.inl"  public:  // blahblahblah};#endif


foo_internals.inl
  int spam;  float quux;  // etc.


3) If your intent is to provide open source but simply avoid long compile times in development (due to constantly changing the header to add or remove private data), use the pImpl idiom. If you want polymorphic behaviour anyway, you can get the pImpl benefits for free: just make the "public" class be a wrapper that delegates to a polymorphic "implementation" class that is held by pointer (as the sole private member of the wrapper). To get the right copy semantics for the wrapper, just use the_edd's value_ptr (an idea I independently came up with, but didn't develop nearly as far).
Quote:Original post by Bregma
What these languages had in common was that they produced code that ran on hardware. C++ is an extension of that legacy, and continues to use the same separate comilation model and continues to produce code that runs on hardware.

The single-pass compilation model is not required to produce code that runs on hardware. Neither is it required to consume object code created by other languages. The forward declaration requirement is an anachronism.
Quote:Original post by Zahlman

1) Simply compile your code, then erase the private members from the header. Ship the modified header and the object file. This assumes that your intent is to provide a closed-source library.


Are you sure that will work? I thought client code needed to know the size of an object to instantiate it on the stack. If you do this, won't you get stack corruption? Please correct me if I'm wrong.

A better way (IMHO) is to provide an abstract class (and factory method) as an interface and derive the "real" class from that. Only ship the interface header.




if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight
Quote:Original post by ChaosEngine
Are you sure that will work? I thought client code needed to know the size of an object to instantiate it on the stack. If you do this, won't you get stack corruption? Please correct me if I'm wrong.

Yes, AFAIK you can only do this if the client is not allowed to instantiate the classes themselves (e.g. you could make the constructors private and provide a static Create method).

Quote:Original post by ChaosEngine
A better way (IMHO) is to provide an abstract class (and factory method) as an interface and derive the "real" class from that. Only ship the interface header.

That approach has the same problem - the client still cannot instantiate the "real" class because they don't even know what it is!
(I guess the upside tho, is that the client can't even attempt to do so)
Quote:Original post by Hodgman
Quote:Original post by ChaosEngine
A better way (IMHO) is to provide an abstract class (and factory method) as an interface and derive the "real" class from that. Only ship the interface header.

That approach has the same problem - the client still cannot instantiate the "real" class because they don't even know what it is!


That's what the factory method was for (i.e. a static "Create" as you said yourself). This is basically the COM model.
if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight
Quote:Original post by ChaosEngine
Quote:Original post by Zahlman

1) Simply compile your code, then erase the private members from the header. Ship the modified header and the object file. This assumes that your intent is to provide a closed-source library.


Are you sure that will work? I thought client code needed to know the size of an object to instantiate it on the stack. If you do this, won't you get stack corruption? Please correct me if I'm wrong.


Er, yeah, like Hodgman said. I didn't really think that through. ^^;;

Quote:A better way (IMHO) is to provide an abstract class (and factory method) as an interface and derive the "real" class from that. Only ship the interface header.


That's what the polymorphic pImpl approach does, except that additionally, the use of composition instead of inheritance (as well providing the correct copying semantics) allows the user to treat the instance as a value rather than a pointed-at thing. (Also, you can use normal constructor calls. [grin])
Just erasing private members could screw up vtable order, resulting in calls on the wrong function. This is bad juju.
Quote:Original post by nobodynews
Quote:Original post by F-Kop
I've been searching for a while for a new language to use, mostly for Win32 programs. The more I research, the more I realize that C++, which I've been using for years, fits my needs more than any other language out there. At least of the ones I've seen, which is a lot.


I'm sorry, I have to bring this up. This doesn't have a THING to do with your question so why did you include it? You could have simply left all that out, asked your question, and been done. But you did say it and now it has me wondering your needs are that you think only C++ can fill them. So, why C++?


That little introduction is sorta off topic, but my point was that I like a language that is object oriented, low-level (relatively), unmanaged, platform independent, and heavily supported. C++ meets all of these standards. Coding could be much quicker with a different model, but it would affect compile time. But compile time isn't all that important to me.
---------------------------------Upon thine ass shall I bust but a single cap.

This topic is closed to new replies.

Advertisement