C-style unit -> C++ class, implementation function / structure issue

J

Jason Doucette

// --- auto.h ---
class Car{
private:
struct car;
car *theCar;
};

// --- auto.cpp ---

struct Car::car{
...........
}

Is that what you were/are doing?

This is what I am doing now, yes. So, now the structure is define in
the .cpp file, and can change, without affecting the interface, or
being visible in the interface. Just like it was back in the C-style
code.

Jason
 
J

Jason Doucette

Typically, declaring
The more the compiler knows, the better it can optimize.

Ah, of course. Kind of like how it can inline code, but only if it
has access to the code to inline (in the .h file). Probably a much
simpler example, but the same concept.

In
this case, however, I was thinking more along the lines of being
able to allocate the data directly on the stack, or in the
class, rather than needing a dynamic allocation.

Right, with knowledge of the struct, it could place it on the stack,
or within the class data members, without requiring that extra pointer
(in both cases) that dynamic allocation would require, and the extra
dereference required by that point will slow things down.

I guess all of my structs are so large that I want them dynamically
allocated. I am somewhat paranoid about stack space, since it's easy
to forget how much you're using, so, all structs are passed by
pointers (or reference, which is the same thing, internally -- just a
pointer on the stack). But, I get your point.

If you want to see just how high the real cost can be, implement
a trivial Complex class (e.g. "double real, imag ;"---no need
for the operators for this test), then reimplement it using the
compilation firewall idiom (
class Complex
{
class Impl ;
Impl * myImp ;
public:
// ...
} ;
).
Now create an std::vector of a couple of million of each:).

Oh, right, of course, that extra dereference each time will be a
killer. I already had structures, and they were so large, that I was
already dynamically allocating them, and I don't have many instances
of such classes. Still, to access the data in these structs, I need
that deference. And if the structs were right in the class
themselves, then they wouldn't need that dereference. I'll keep this
in mind. Having the struct definition itself public isn't really a
problem, as long as the instance of it within the class is private, it
should be ok (although this entire thread commenced at my desire to
solve exactly this -- to make the struct definition private, as well).

The question is what the difference is, and when. Using the
compilation firewall idiom requires an allocation in the
constructor, a delete in the destructor, and (generally) an
extra indirection in every function call. If the object
lifetimes are long, and the functions are complex, the
difference isn't measurable. If objects are frequently created
and destroyed (value semantics with deep copy, for example), and
the functions are almost trivial (complex::eek:perator+), the
difference can be important.

Creation/destruction hardly ever happens. But, the data in the struct
will be accessed, and there will be a dereference each time. I'll
make a note of this to test it out. For the most part, if there's any
serious data accessing going on, I get a direct pointer to that data,
and directly access it... instead of dereferencing it each time.

Jason
 
J

Jason Doucette

I made 2 posts via Google Groups to this thread yesterday, and I don't
see them... I'll post a short note here to see if this works...
perhaps Google is merely delayed...

Jason
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top