Re: Header Files and Interfaces Yet Again
From: Steven T. Hatton (susudata_at_setidava.kushan.aa)
Date: 06/11/04
- Next message: Dave Townsend: "Re: operator[] -- returning references"
- Previous message: John Black: "how to use for_each to collect some info from a vector into another vector"
- In reply to: Kai-Uwe Bux: "Re: Header Files and Interfaces Yet Again"
- Next in thread: Kai-Uwe Bux: "Re: Header Files and Interfaces Yet Again"
- Reply: Kai-Uwe Bux: "Re: Header Files and Interfaces Yet Again"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 11 Jun 2004 17:11:11 -0400
Kai-Uwe Bux wrote:
>> You really should try to get a copy of Stroustrup's book. It explains
>> how
>> both of these can be the case. That is, I get a foo.h user's header file
>> and the implementation has a foo_impl.h header file.
>
>
> That appears to be an interesting concept. But you have me wonder how this
> is possible. As you are refering to Java sometimes, let me describe, for
> the sake of exposition, what, in my mind, is one of the major conceptual
> differences between Java and C++: In Java all obects appear to be handles.
> Consider the code:
>
> a = b;
> b.some_modifying_method( arg );
Yes. Java's assignments are pointer assignments. You have to be more
explicit if you want a copy.
> This difference is important for the ways compiler can go about generating
> code. In Java any user defined class could always be represented by a
> pointer. Assignment is pointer assignement. Since actual objects are only
> created at runtime, it is the linker that must know about the sizes of the
> physical objects that the object handles point to. But the compiler can
> safely assume that an object handle has the size of one pointer. In C++,
> life is more tricky. If the library presents a header:
>
> // file: foo.h
>
> class PhoneDirectory {
> // private data fields suppressed.
> public:
>
> void insert ( const std::string & name,
> const std::string & number );
>
> ...
>
> }
>
> and client code says:
>
> // file: main.cc
>
> #include <PhoneDirectory.h>
>
> int main () {
> PhoneDirectory dir;
> ...
>
> }
>
> Then, how is the compiler supposed to deduce the size of the variable
> "dir"?
One answer is "don't do that". I've experimented with different approaches
to designing classes and found that putting variables instead of pointers
in classes can lead problems when working with headers. Unfortunately I've
found that when working with third party libraries it's not always possible
to have things my way.
This kind of thing presents a problem for me because I use certain design
approaches which rely on others. If for some reason I'm forced to violate
one of my established rules (or violate it accidentally), it often forces
another rule to be violated, or a behavior that I don't expect, because
I've forgotten all the consequences of violating the rule.
I am confident Stroustrup provides approaches for addressing the kind of
situation you have presented, but due to health reasons, I am not able to
focus on this right now. Part of the problem seems to point back to the use
of values rather than pointers in your class. I believe this is why what
are often called class declarations are technically definitions.
-- STH Hatton's Law: "There is only One inviolable Law" KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com Mozilla: http://www.mozilla.org
- Next message: Dave Townsend: "Re: operator[] -- returning references"
- Previous message: John Black: "how to use for_each to collect some info from a vector into another vector"
- In reply to: Kai-Uwe Bux: "Re: Header Files and Interfaces Yet Again"
- Next in thread: Kai-Uwe Bux: "Re: Header Files and Interfaces Yet Again"
- Reply: Kai-Uwe Bux: "Re: Header Files and Interfaces Yet Again"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
