By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,728 Members | 2,488 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,728 IT Pros & Developers. It's quick & easy.

what are the rules for writing header files?

P: n/a

Hello all,

I have written a class with many private data members.and i am putting
it in a separate dll file.
Now when i link that file while writing my main program
module,natuarally i have to use the header file of the class developed
by me to access its functionality.
so what should be there in the header file?
Only the public methods declaration / data members of that class or the
whole layout of the class along with its all private members?
(
IMO the private section restricts the accessibility of the class and
the user of the class is abstracted from the exact layout of the
class.So there should be no need to show the internal layout of my
class by putting the private variable inside the header file of that
class.
)

I encountered severe crasing problem when I declare the class without
the private members in the header file? but everything works fine when
i put the exact layout of the class correctly inside the header file.
(i have defined all the public methods inside a separate cpp file with
the scope resolution operator)

Thanks and Regards,
Yogesh
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 25 '06 #1
Share this Question
Share on Google+
24 Replies


P: n/a

yp*********@indiatimes.com wrote:
Hello all,

I have written a class with many private data members.and i am putting
it in a separate dll file.
Now when i link that file while writing my main program
module,natuarally i have to use the header file of the class developed
by me to access its functionality.
so what should be there in the header file?
Only the public methods declaration / data members of that class or the
whole layout of the class along with its all private members?
(
IMO the private section restricts the accessibility of the class and
the user of the class is abstracted from the exact layout of the
class.So there should be no need to show the internal layout of my
class by putting the private variable inside the header file of that
class.
) I encountered severe crasing problem when I declare the class without
the private members in the header file? but everything works fine when
i put the exact layout of the class correctly inside the header file.
(i have defined all the public methods inside a separate cpp file with
the scope resolution operator)


In a moment you'll probably get flamed with the old "C++ has no concept
of dlls" (or shared objects or any other kind of loadable library).

Anyway, when you are exporting a class you want to export the interface
only. That means one of two things:

- Use an abstract base class and a factory
- Use a pImpl

I don't know your knowledge of the language but basically they mean as
follows:

- Abstract base class: has at least one pure virtual method. In your
case probably all of them will be pure virtual. Ensure you also have a
virtual destructor.
- Class factory: This will usually be an object but can be a function
to generate instance of the class.

Note that as the classes have to be allocated with "new", there will
need to be a defined deleter. Your library should provide a deleter.
(Again it can be a function or functior). Then the library using the
class must use the deleter to destroy the object. A boost::shared_ptr
can take a deleter. Note that for a custom deleter, one option is to
make this concrete (in a generic header) but have itself an abstract
pointer. It invokes a method on the abstract pointer (when operator()
is called) which at the same time should delete itself, so the deleter
has the same life-span as the object.

- The pImpl uses a "pointer to implementation" of a type that is only
forwardly declared (but is known in the implementation of your library
class). Your class will then forward all implementation to this pImpl
class. Note that as a pImpl is a pointer, you have to overload the
destructor, and handle also assignment and copy-construction (or
disable them). This method has the advantage of allowing users to
create a class directly without a factory (and therefore to be able to
more eaily manage destroying them) and that these classes can also be
created on the heap.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 25 '06 #2

P: n/a
In article <11*********************@o13g2000cwo.googlegroups. com>,
yp*********@indiatimes.com writes
I have written a class with many private data members.and i am putting
it in a separate dll file.
Now when i link that file while writing my main program
module,natuarally i have to use the header file of the class developed
by me to access its functionality.
so what should be there in the header file?
Only the public methods declaration / data members of that class or the
whole layout of the class along with its all private members?
(
IMO the private section restricts the accessibility of the class and
the user of the class is abstracted from the exact layout of the
class.So there should be no need to show the internal layout of my
class by putting the private variable inside the header file of that
class.
)

I encountered severe crasing problem when I declare the class without
the private members in the header file? but everything works fine when
i put the exact layout of the class correctly inside the header file.
(i have defined all the public methods inside a separate cpp file with
the scope resolution operator)


Your problem has nothing to do with using a DLL. The issue is very
simple, the compiler needs to know some details about the data so that
it can set aside sufficient storage for the constructor to construct an
instance.

If you are willing to walk in undefined behaviour territory, you could
(though I really do not advise it) simply declare a large enough array
of char as a private member of the class in the header file. Then you
could provide the full and correct class definition in the
implementation file without including the header. Of course you might
still hit problems if the (dynamic) linker is sufficiently clever to use
something such as a checksum to ensure that the class definitions in
separate TUs are identical.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 25 '06 #3

P: n/a
yp*********@indiatimes.com wrote:
I have written a class with many private data members.and i am putting
it in a separate dll file.
Now when i link that file while writing my main program
module,natuarally i have to use the header file of the class developed
by me to access its functionality.
so what should be there in the header file?
Only the public methods declaration / data members of that class or the
whole layout of the class along with its all private members?
Where else than in the class definition would you put its private members?
There is no other place.
(
IMO the private section restricts the accessibility of the class and
the user of the class is abstracted from the exact layout of the
class. So there should be no need to show the internal layout of my
class by putting the private variable inside the header file of that
class.
)


However, having the private members there won't hurt the users either.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 25 '06 #4

P: n/a
You must declare *all* members in the headers, they describe the
"layout" the data will have in memory. That's why you are getting
crashes, internally your class has one layout but externally it has
another.

But you can make a little trick called "Pimpl idiom" to hide your
private members in a pointer to an incomplete type. See:

http://www.boost.org/libs/smart_ptr/...ues.html#pimpl
http://www.gotw.ca/gotw/024.htm
http://www.gotw.ca/publications/mill05.htm
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 25 '06 #5

P: n/a
<yp*********@indiatimes.com> wrote:

I have written a class with many private data members.and i am putting
it in a separate dll file.
Now when i link that file while writing my main program
module,natuarally i have to use the header file of the class developed
by me to access its functionality.
so what should be there in the header file?
Only the public methods declaration / data members of that class or the
whole layout of the class along with its all private members?


Put everything up to and including the semicolon ending the type definition
that started with "class" in the header file.

E.g., class { ....};

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 25 '06 #6

P: n/a
However, having the private members there won't hurt the users either.

But doesn't it violate the abstraction priniciple.?

If user can see what(type) and how(arrangement) I am using my private
variables,how come the variables will be termed as private.

As user can easily hack my classlayout by writing another consistent
layout to my class and manipulate the variables without using any of
the member function provided by my class to access the private
variables.

After i started getting confusion about the private members,i read many
header file( i am using VC7) and they all declare the private members
inside then.This is a big surprise to me as so far I have been studying
and reading it everywhere that user should not be made aware of the
private variables present inside your class.

Thanks and Regards,
Yogesh Joshi
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 25 '06 #7

P: n/a
yp*********@indiatimes.com wrote:
However, having the private members there won't hurt the users either. But doesn't it violate the abstraction priniciple.?

If user can see what(type) and how(arrangement) I am using my private
variables,how come the variables will be termed as private.


Be careful not to confuse "private:" with personal privacy.
In C++ only the class and its friends can access private members
(functions or data).
As user can easily hack my classlayout by writing another consistent
layout to my class and manipulate the variables without using any of
the member function provided by my class to access the private
variables.
What means "hack"? Get access to the private members?
I'm pretty sure most linkers (not compilers) will not complain if you
modify the definition of a class so that everything is public.
Just for fun, try the following:

#define private public
#define class struct
#include "foo.h" // for Foo

void bar(Foo& foo)
{
// access Foo's private member here
}

However I consider such tricks "malicious coding", i.e., the user WANTS
to break the rules.
Compare with normal coding errors:

class Singleton {
private:
// construction by the class itself only
Singleton();
// prevent copying: NOT implemented
Singleton(const Singleton&);
public:
// get the only instance
static Singleton& instance();
};

void foo()
{
Singleton mgr = Singleton::instance();
// ^Error: copy constructor is private
// should be Singleton& instead
}

After i started getting confusion about the private members,i read many
header file( i am using VC7) and they all declare the private members
inside then.This is a big surprise to me as so far I have been studying
and reading it everywhere that user should not be made aware of the
private variables present inside your class.


Consider the alternative, the PIMPL idiom. While this is certainly a
valid option for "long-life" classes, e.g., ThePrinterManager, its a
performance (and implementation) hit for heavily used classes with a
short lifetime, such as the STL iterators.

Regards, Stephan

Jan 25 '06 #8

P: n/a
yp*********@indiatimes.com wrote:
However, having the private members there won't hurt the users either. But doesn't it violate the abstraction priniciple.?

If user can see what(type) and how(arrangement) I am using my private
variables,how come the variables will be termed as private.


Be careful not to confuse "private:" with personal privacy.
In C++ only the class and its friends can access private members
(functions or data).
As user can easily hack my classlayout by writing another consistent
layout to my class and manipulate the variables without using any of
the member function provided by my class to access the private
variables.
What means "hack"? Get access to the private members?
I'm pretty sure most linkers (not compilers) will not complain if you
modify the definition of a class so that everything is public.
Just for fun, try the following:

#define private public
#define class struct
#include "foo.h" // for Foo

void bar(Foo& foo)
{
// access Foo's private member here
}

However I consider such tricks "malicious coding", i.e., the user WANTS
to break the rules.
Compare with normal coding errors:

class Singleton {
private:
// construction by the class itself only
Singleton();
// prevent copying: NOT implemented
Singleton(const Singleton&);
public:
// get the only instance
static Singleton& instance();
};

void foo()
{
Singleton mgr = Singleton::instance();
// ^Error: copy constructor is private
// should be Singleton& instead
}

After i started getting confusion about the private members,i read many
header file( i am using VC7) and they all declare the private members
inside then.This is a big surprise to me as so far I have been studying
and reading it everywhere that user should not be made aware of the
private variables present inside your class.


Consider the alternative, the PIMPL idiom. While this is certainly a
valid option for "long-life" classes, e.g., ThePrinterManager, its a
performance (and implementation) hit for heavily used classes with a
short lifetime, such as the STL iterators.

Regards, Stephan

Jan 25 '06 #9

P: n/a

<yp*********@indiatimes.com> skrev i meddelandet
news:11**********************@g44g2000cwa.googlegr oups.com...
However, having the private members there won't hurt the users
either. But doesn't it violate the abstraction priniciple.?

If user can see what(type) and how(arrangement) I am using my
private
variables,how come the variables will be termed as private.


They are there for the compiler, not for other programmers. How are
the compiler supposed to allocate space for objects of your class, if
you don't tell the compiler what it contains?

As user can easily hack my classlayout by writing another
consistent
layout to my class and manipulate the variables without using any of
the member function provided by my class to access the private
variables.


The language rules is there to protect the well behaved user, not to
stop hacking. Consider what this piece of code would do:

#defined private public

(apart from breaking the rules).
Using private protects the class members from being used by accident,
not from anything else.
Bo Persson

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 26 '06 #10

P: n/a
yp*********@indiatimes.com wrote:
If user can see what(type) and how(arrangement) I am using my private
variables,how come the variables will be termed as private. C++ is designed to prevent accidents, not fraud.

Yes, it is possible for your users to access private members. You
mentioned one way. There's also
#define private public
before including a header file, which isn't legal -- but I doubt that
there
are very many compilers that would reject it.

Still another way would be to take the address of your object, convert
it to a char*, and manipulate it from there... if the private members
couldn't be seen, this would take some experimentation, but it could
be done. It's called "hacking," as you are apparently aware:
As user can easily hack my classlayout by writing another consistent
layout to my class and manipulate the variables without using any of
the member function provided by my class to access the private
variables.
Yes, and this is actually pretty important during debugging. Most
debuggers will allow you to look at private members. This doesn't
break encapsulation either... it's what's in the program that counts.

C++ is designed to prevent accidents, not fraud. None of the
techniques listed above can possibly be an accident. If your users
decide to break the rules this way, they're asking for trouble... the
first time you make even the tiniest change to your class, their
hacks are in danger of not working anymore. When code uses your
public interface, this shouldn't be a problem.
After i started getting confusion about the private members,i read many
header file( i am using VC7) and they all declare the private members
inside then.This is a big surprise to me as so far I have been studying
and reading it everywhere that user should not be made aware of the
private variables present inside your class.


That's right, they should not be "aware" of your private members as in
"depending on." They should use your public interface only.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 26 '06 #11

P: n/a
> > However, having the private members there won't hurt the users either.
But doesn't it violate the abstraction priniciple.?
Yes, somewhat, as the user can see some of how you implemented things.
If user can see what(type) and how(arrangement) I am using my private
variables,how come the variables will be termed as private.
Private means you can not access them, such as object.MyPrivateData1.
It does not mean that you can't hack it (for example, a user could
theoretically figure out from the header file what the offset of a
variable is, then read or write that memory location). But as far as
the language is concerned they can not be accessed directly.
...
After i started getting confusion about the private members,i read many
header file( i am using VC7) and they all declare the private members
inside then.This is a big surprise to me as so far I have been studying
and reading it everywhere that user should not be made aware of the
private variables present inside your class.


The theory is nice and can be implemented directly in other languages,
but not in C++. In C++ the class definition must have the private
stuff declared. Other posters have explained techniques for
accomplishing what you would like to accomplish -- it is not
impossible, but it is not directly supported by the language.

Batya
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 26 '06 #12

P: n/a
yp*********@indiatimes.com wrote:
However, having the private members there won't hurt the users either. But doesn't it violate the abstraction priniciple.?

If user can see what(type) and how(arrangement) I am using my private
variables,how come the variables will be termed as private.


private means that the user of your class can't use those members, not that
he can't see them.
As user can easily hack my classlayout by writing another consistent
layout to my class and manipulate the variables without using any of
the member function provided by my class to access the private
variables.


And why should he do that? You can't get total security against deliberate
sabotage. That's not what the access specifiers are for anyway. Their
purpose is to help the user to not use your class the wrong way by
accident. If he _wants_ to screw up, there is always a way.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 26 '06 #13

P: n/a
yp*********@indiatimes.com wrote:
However, having the private members there won't hurt the
users either. But doesn't it violate the abstraction priniciple.?


Why? The user (programmer) doesn't have to know anything about
the private members. (The compiler does, so that it can lay out
the class correctly. But that's no concern of the user.)
If user can see what(type) and how(arrangement) I am using my
private variables,how come the variables will be termed as
private.
Because the user cannot access them.
As user can easily hack my classlayout by writing another
consistent layout to my class and manipulate the variables
without using any of the member function provided by my class
to access the private variables.
I forget who originally said it (Steve Clamage?), but C++ is
designed to protect against Murphy, not against Machiavelli.
After i started getting confusion about the private members,i
read many header file( i am using VC7) and they all declare
the private members inside then. This is a big surprise to me
as so far I have been studying and reading it everywhere that
user should not be made aware of the private variables present
inside your class.


I think you're confusing the issues. A user needs to know the
interface he's addressing; typically, this will NOT include
private data members. If the user is writing a derived class,
the interface very probably will include private virtual
functions which he must override. And of course, the fact that
the copy constructor or the assignment operator are declared
private has repercussions in the interface which is available to
all users. And of course, if the user is the author of a friend
class, he has access to everything -- typically, however, you
will document what he may and may not do. (Typically, of
course, the author of a friend class is the author of the class
granting friendship:-).)

The role of private is simply to avoid accidentally accessing
things you're not supposed to access. It is not to "hide"
anything, at least not in the literal sense of hide.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 26 '06 #14

P: n/a
Rolf Magnus wrote:
However, having the private members there won't hurt the users either.


It sure will because it will make them physically dependent on
implementation details and increase coupling.
--
Gerhard Menzl

#dogma int main ()

Humans may reply by replacing the thermal post part of my e-mail address
with "kapsch" and the top level domain part with "net".

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 26 '06 #15

P: n/a
Ted

"Earl Purple" <ea********@gmail.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

yp*********@indiatimes.com wrote:
Hello all,

I have written a class with many private data members.and i am putting
it in a separate dll file.
Now when i link that file while writing my main program
module,natuarally i have to use the header file of the class developed
by me to access its functionality.
so what should be there in the header file?
Only the public methods declaration / data members of that class or the
whole layout of the class along with its all private members?
(
IMO the private section restricts the accessibility of the class and
the user of the class is abstracted from the exact layout of the
class.So there should be no need to show the internal layout of my
class by putting the private variable inside the header file of that
class.
)
I encountered severe crasing problem when I declare the class without
the private members in the header file? but everything works fine when
i put the exact layout of the class correctly inside the header file.
(i have defined all the public methods inside a separate cpp file with
the scope resolution operator)


In a moment you'll probably get flamed with the old "C++ has no concept
of dlls" (or shared objects or any other kind of loadable library).

Anyway, when you are exporting a class you want to export the interface
only. That means one of two things:

- Use an abstract base class and a factory
- Use a pImpl

I don't know your knowledge of the language but basically they mean as
follows:

- Abstract base class: has at least one pure virtual method. In your
case probably all of them will be pure virtual. Ensure you also have a
virtual destructor.
- Class factory: This will usually be an object but can be a function
to generate instance of the class.

Note that as the classes have to be allocated with "new", there will
need to be a defined deleter. Your library should provide a deleter.


Or just define another "lifetime" mgr class wrapper for the object:

class MyClassInst // could derive from the MyClass interface also
{ // but then you'd have to provide forwarding
// methods to the implementation class.
MyClass* my_class;
public:
MyClassInst()
{
my_class = c_CreateMyClass(); // DLL exported create func
}

~MyClassInst()
{
c_DestroyMyClass(my_class); // DLL exported destroy func
}
operator MyClass*(){ return my_class; }
};

MyClassInst my_inst; // instantiate an instance of MyClass from DLL
(Again it can be a function or functior).
Or a class as above.
Then the library using the
class must use the deleter to destroy the object. A boost::shared_ptr
can take a deleter. Note that for a custom deleter, one option is to
make this concrete (in a generic header) but have itself an abstract
pointer. It invokes a method on the abstract pointer (when operator()
is called) which at the same time should delete itself, so the deleter
has the same life-span as the object.

- The pImpl uses a "pointer to implementation" of a type that is only
forwardly declared (but is known in the implementation of your library
class). Your class will then forward all implementation to this pImpl
class. Note that as a pImpl is a pointer, you have to overload the
destructor, and handle also assignment and copy-construction (or
disable them). This method has the advantage of allowing users to
create a class directly without a factory (and therefore to be able to
more eaily manage destroying them) and that these classes can also be
created on the heap.


And provides a way to derive from classes when you don't have the source
code except for the interface header. (Gee, wouldn't some new C++ syntax
be narly in that scenario :)).

Ted
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 28 '06 #16

P: n/a
Ted

"Francis Glassborow" <fr*****@robinton.demon.co.uk> wrote in message
news:wk**************@robinton.demon.co.uk...
In article <11*********************@o13g2000cwo.googlegroups. com>,
yp*********@indiatimes.com writes
I have written a class with many private data members.and i am putting
it in a separate dll file.
Now when i link that file while writing my main program
module,natuarally i have to use the header file of the class developed
by me to access its functionality.
so what should be there in the header file?
Only the public methods declaration / data members of that class or the
whole layout of the class along with its all private members?
(
IMO the private section restricts the accessibility of the class and
the user of the class is abstracted from the exact layout of the
class.So there should be no need to show the internal layout of my
class by putting the private variable inside the header file of that
class.
)

I encountered severe crasing problem when I declare the class without
the private members in the header file? but everything works fine when
i put the exact layout of the class correctly inside the header file.
(i have defined all the public methods inside a separate cpp file with
the scope resolution operator)


Your problem has nothing to do with using a DLL. The issue is very
simple, the compiler needs to know some details about the data so that
it can set aside sufficient storage for the constructor to construct an
instance.

If you are willing to walk in undefined behaviour territory, you could
(though I really do not advise it) simply declare a large enough array
of char as a private member of the class in the header file. Then you
could provide the full and correct class definition in the
implementation file without including the header. Of course you might
still hit problems if the (dynamic) linker is sufficiently clever to use
something such as a checksum to ensure that the class definitions in
separate TUs are identical.


That is bizarre! Just expose the public methods in an interface, create
an exported Create function and be done with it. (Some consideration
fo fine-grained vs. coarse-grained object interfaces would be prudent
for the developer considering using interfaces).

Ted
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 28 '06 #17

P: n/a
Ted

"kanze" <ka***@gabi-soft.fr> wrote in message news:11**********************@f14g2000cwb.googlegr oups.com...
yp*********@indiatimes.com wrote: The role of private is simply to avoid accidentally accessing
things you're not supposed to access. It is not to "hide"
anything, at least not in the literal sense of hide.


Yes, you know they are there but they are not accessible. If the
private things were always accessible, you'd never get any work
done... umm nevermind!

Ted
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 28 '06 #18

P: n/a
Ted

<yp*********@indiatimes.com> wrote in message news:
11**********************@g44g2000cwa.googlegroups. com...
However, having the private members there won't hurt the users
either.

But doesn't it violate the abstraction priniciple.?

If user can see what(type) and how(arrangement) I am using my private
variables,how come the variables will be termed as private.


Perhaps it's not a good idea to expose your privates. (hehe).

Ted
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 28 '06 #19

P: n/a
Ted

<yp*********@indiatimes.com> wrote in message news:
11*********************@o13g2000cwo.googlegroups.c om...

Hello all,

I have written a class with many private data members.and i am putting
it in a separate dll file.
Now when i link that file while writing my main program
module,natuarally i have to use the header file of the class developed
by me to access its functionality.
so what should be there in the header file?
Only the public methods declaration / data members of that class or
the
whole layout of the class along with its all private members?

You may want to try interfaces: expose only the public methods of the
class and use a factory function to get objects of that class from
the DLL.

Ted
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 28 '06 #20

P: n/a
Ted wrote:

Perhaps it's not a good idea to expose your privates. (hehe).


Remember, only you and your friends can play with your private parts!

red floyd

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 28 '06 #21

P: n/a
In article <11*********************@o13g2000cwo.googlegroups. com>,
yp*********@indiatimes.com wrote:
Hello all,

I have written a class with many private data members.and i am putting
it in a separate dll file.
Now when i link that file while writing my main program
module,natuarally i have to use the header file of the class developed
by me to access its functionality.
so what should be there in the header file?
Only the public methods declaration / data members of that class or the
whole layout of the class along with its all private members?
(
IMO the private section restricts the accessibility of the class and
the user of the class is abstracted from the exact layout of the
class.So there should be no need to show the internal layout of my
class by putting the private variable inside the header file of that
class.
)

I encountered severe crasing problem when I declare the class without
the private members in the header file? but everything works fine when
i put the exact layout of the class correctly inside the header file.
(i have defined all the public methods inside a separate cpp file with
the scope resolution operator)


You have some very valid concerns. As you have learned, you can't change
the header file without recompiling all the object files that include
it. By putting the data in the header file, even in the private part of
a class, all of the object files (the DLL and *all* programs that depend
on that DLL) will have to be recompiled every time you make any change
in the data.

Edson Manoel gave you the best advice by far. Use the pimpl idiom to
solve this problem:

// file y.h
class X;

class Y {
// remove all the private parts
X* px_;
public:
Y();
Y( const Y& other );
~Y();
Y& operator=( const Y& other );
// ...
};

// file y.cpp
class X {
// everything that was private in Y
};

Y::Y() : px_( new X ) {}
Y::Y( const Y& other ) {
*px_ = other.px_;
}
Y::~Y() { delete px_; }
Y& operator=( const Y& other ) {
*px_ = other.px_;
}
By doing the above, you will be able to add/remove private bits without
having to recompile users of the Y class.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 28 '06 #22

P: n/a
In article <a-*********************@news.east.earthlink.net>, Daniel T.
<a@b.c> wrote:

Edson Manoel gave you the best advice by far. Use the pimpl idiom to
solve this problem:

// file y.h
class X;

class Y {
// remove all the private parts
X* px_;
public:
Y();
Y( const Y& other );
~Y();
Y& operator=( const Y& other );
// ...
};

// file y.cpp
class X {
// everything that was private in Y
};

Y::Y() : px_( new X ) {}
Y::Y( const Y& other ) {
*px_ = other.px_;
}
Y::~Y() { delete px_; }
Y& operator=( const Y& other ) {
*px_ = other.px_;
}

This produces a shallow copy that is:
Y a;
Y b(a);
a and b have the same values of private data and if when they are
destructed one of the destructors will delete a deleted pointer. Ouch!!
its not quite so simple. You must deep copy the pointers , create a
pointer to a copy of the class X, not just a copy of the X *.

Y:Y() {p_x = new X;}
Y:Y(const Y &r) {p_x = new X(*r.p_x);}
Y & operator () (const Y &r)
{
X *p = new X(*r.p_x); // in case of self assign.
delete p_x;
p_x = p;
return *this;
}
Y:~Y() {delete p_x;}

comes to mind. These ctor's will throw if there is insufficient memory,
but otherwise make Y Copyable and Assignable.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 29 '06 #23

P: n/a
In article <28***************************@adelphia.net>,
Carl Barron <cb********@adelphia.net> wrote:
In article <a-*********************@news.east.earthlink.net>, Daniel T.
<a@b.c> wrote:

Edson Manoel gave you the best advice by far. Use the pimpl idiom to
solve this problem:

// file y.h
class X;

class Y {
// remove all the private parts
X* px_;
public:
Y();
Y( const Y& other );
~Y();
Y& operator=( const Y& other );
// ...
};

// file y.cpp
class X {
// everything that was private in Y
};

Y::Y() : px_( new X ) {}
Y::Y( const Y& other ) {
*px_ = other.px_;
}
Y::~Y() { delete px_; }
Y& operator=( const Y& other ) {
*px_ = other.px_;
}

This produces a shallow copy that is:
Y a;
Y b(a);
a and b have the same values of private data and if when they are
destructed one of the destructors will delete a deleted pointer. Ouch!!
its not quite so simple. You must deep copy the pointers , create a
pointer to a copy of the class X, not just a copy of the X *.

Y:Y() {p_x = new X;}
Y:Y(const Y &r) {p_x = new X(*r.p_x);}
Y & operator () (const Y &r)
{
X *p = new X(*r.p_x); // in case of self assign.
delete p_x;
p_x = p;
return *this;
}
Y:~Y() {delete p_x;}

comes to mind. These ctor's will throw if there is insufficient memory,
but otherwise make Y Copyable and Assignable.


Sorry, I was a little short with my code, for example my copy c_tor, and
op= wouldn't compile as they stand...

Y::Y() : px_( new X ) { }
Y::Y( const Y& o ): px_( new X( *o.px_ ) ) { }

The above is a bit better than your c_tors
<http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.6> In my
original copy c_tor, I forgot to create a new X then tried to
dereference it which is bad.

The big difference between our code is the op=, I see nothing wrong
with mine (other than the missing dereference.)

Y& operator=( const Y& o ) {
*px_ = *o.px_;
}

All the hoops you jump through in your op= are wholly unnecessary,
unless class X doesn't have an op=. (And if it has a copy c_tor, it darn
well should have an op= as well.)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 29 '06 #24

P: n/a
In article <po******************************@news.east.earthl ink.net>,
Daniel T. <po********@earthlink.net> wrote:

The big difference between our code is the op=, I see nothing wrong
with mine (other than the missing dereference.)

Y& operator=( const Y& o ) {
*px_ = *o.px_;
}

All the hoops you jump through in your op= are wholly unnecessary,
unless class X doesn't have an op=. (And if it has a copy c_tor, it darn
well should have an op= as well.)

If X has an assignment operator then yours is faster. I wrote it
off the cuff and did not want to create another double delete error.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jan 30 '06 #25

This discussion thread is closed

Replies have been disabled for this discussion.