public headers

Hello,
i want to create c++ libraries (for my use) but I don't know how I
must do to have headers which contain only the public declarations.
I used in C to put the private declarations in *.c and the public
declaration in *.h. But how to do that in c++.
If someone could help me, he would be nice.
Thank you.

iesvs@free.fr wrote:What difference do you think exists between C and C++ in that
respect? Put your public declarations in .h files, put your private
declarations and definitions in .cpp. Now, don't let the presence
of 'public' and 'private' access specifiers confuse you. Those are
not what you used to have in C (as I understand it), those are to
prevent errors, not really to protect your intellectual property.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

What difference do you think exists between C and C++ in thatMany.
Yeah but I mean I got a class with private and public members and I
just want the public appear in headers not private.
I know it, I just think that if a member is private it must not be
present in headers.

On Sep 25, 9:38 pm, "ie...@free.fr" <ie...@free.frwrote:
That's incorrect. It must be in the header or the compiler will not
be able to create the object correctly, since it has to create ("new")
any instances with the space for the private items in the correct
spots.

If you really want to hide those details, you need to implement an
abstract base class, or something along those lines.

That's incorrect. It must be in the header or the compiler will notI know now why I refuse for many years to develop in c++. It confirms
what I thought. I get back to C.

"iesvs@free.fr" <iesvs@free.frwrites:

[...]
Note that while the compiler needs to know the types and sizes of the
objects, it doesn't need to know their names. If your goal is to
hide the internal workings of your code, you could certainly change:

private:
int secretNumber;
MasterKey *key;
double doubleSecret;

to:

private:
int adfoiwjeofijasdoijfaoeiwjpowiejapwoei;
void *oaisjpoijpj8p9ja89jjdlskjvas8vap9e8jw;
double ap98fjas98ejfpzs9vzd8a9pwe89pwejrp98awj98awjef;

when you distribute the code. This form of obfuscation is common in
Java and Javascript, and tools area available to do the conversion
automatically. I haven't come across any for C++, but they may exist,
and if not it wouldn't be too hard to write a simple one.

This will hide your private variables about as well as you can
reasonably expect; after all, the contents of those variables are
readily available to anybody with a debugger.

Hope this helps,

----Scott.

I know now why I refuse for many years to develop in c++. It confirmsHow do you do this in C?

On Sep 26, 7:08 am, Adam Nielsen <adam.niel...@remove.this.uq.edu.au>
wrote:####################

//list.c

struct list
{
int *hd;
LIST *tl;
}

int *get_hd_unsafe (LIST *l) //private for example
{
return l->hd;
}

int get_hd (LIST *l) //public for example
{
if (l == NULL)
return NULL;
get_hd_unsafe (l);
}

#####################

//list.h

typedef struct list LIST;

int get_hd (LIST *);

//list.cBut those public and private functions are global - when you combine
them into a class, it's like using a struct - how would you do this in C?
That's the problem from a C++ point of view - you have one complete
structure but you want to hide part of it - it's not possible in C or C++.

Of course you might be looking at this the wrong way. Why do you want
to hide the private members in your classes? Anyone using the class
won't be able to access them because they're private, but what if
someone wants to extend one of your classes to enhance it? If all the
data members are hidden (as opposed to being declared as protected),
then you could limit the usefulness of your classes, by preventing
people from expanding them.

Cheers,
Adam.

That's the problem from a C++ point of view - you have one completeWhat does my example ?
Because when someone (me for example) want to use the library he reads
the .h (or .hpp with c++) and he know which objects (struct) exist and
which function exist (an API reference), I don't want him to see a
function that he hasn't to use. If he want to use an internal
function, he can but it's his problem, not mine.
I don't use protected (it's useless). I don't want him to know how
work my class in internal, because it could change if I use a new
method (new algorithm, I change an int into a char etc.), but I never
change the public (it's a fundamental principle). And I don't want him
to see the internal of my class. I'm a part of guys who think that
look at the source code of others is heretical.

What does my example ?

See the question in my last message - how would you make 'hd' private
and 'tl' public, while leaving them all inside struct 'list'?
This isn't how programming languages generally work, they're not
supposed to be closed because let's face it, a bunch of text files isn't
really that secure. If someone is determined to see how your code works
they'll figure it out eventually. Hiding code like this will only trick
you into thinking it's secure.
I find it quite useful myself. I suspect you've never come across a
problem that could be solved with the use of protected members :-)
This is the whole idea behind private members. You're not supposed to
use them because they could change without warning. It doesn't matter
whether you can see them or not, only a foolish programmer would
'illegally' use somebody else's private data members. It's like an
honesty system - you're telling people not to use the private members,
and if they go ahead and use them, then it's their own fault when you
change something and their code breaks. Serves them right for ignoring
you :-)
Then I feel sorry for you :-) Sharing source code is amazingly
productive, you can learn a huge amount from reading someone else's
code. Not sharing source code is like painting an amazing picture and
then refusing to show it to anyone - how can people respect your skill
as a programmer if they can't see your code?

If you don't want people to see your code, then the safest way is to
simply not write any classes - that's the only way you can guarantee
that nobody will see your code ;-)

(or you could use abstract base classes, as has already been suggested:
http://www.parashift.com/c++-faq-lite/abcs.html)

Cheers,
Adam.

On Sep 26, 11:04 am, Adam Nielsen <adam.niel...@remove.this.uq.edu.au>
wrote:I never put variables in public area. I always create function to
access the variables. I learnt with an object language where the
variables are private (no choice).
I don't want to hide my code (it's technologically impossible, even
with a binary, which is a source code for the system's language). I
just want to give a complete API in .h, someone using it doesn't need
to look inside the .c, but if he wants (Why ? I don't know) he can.
I use public method, it works. I think that if a derived class could
use a method, anything else must. I find the opposite weird.
It matters, it's not clean. Have you ever seen in an API the library's
interior ? Me, never.
I made it sometimes, but temporary.
We agree.
I share source code for the reasons you said, and others (portability,
which is nearly impossible with binaries). But I think that if someone
want to use my libraries he just has to read the .h (which are here
for that in my opinion).
And personally I respect the skill of someone as a programmer when I
don't have to read his .c to understand how works his library and just
have to read the .h. Each time I respect someone for those reasons,
when I take a look inside his code I find it marvelous, because when a
guy is clean at exterior he is always clean inside (but it's very
rare).
Not so good in my opinion.

iesvs@free.fr wrote:A private thing is the interface for itself and friends. So,
technically it *is* part of the interface. Unless, of course,
it's data. Then it's part of the object state.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

A private thing is the interface for itself and friends. So,The interface is by definition for the exterior so not for the class
itself. And Like I don't use protected I don't use friend, in my
opinion protected and friend are hacks (a bandage if this is not use
like this in English) create for those who don't know how to use
objects.

I specify I'm a fundamentalist, this is why I just use public and
private, don't use virtual except for the pure virtual (virtual ... =
0) and don't want a private member appears in headers. So don't be
surprised if I got strange ideas.

On 2007-09-26 17:39, iesvs@free.fr wrote:Since the private members are needed when instantiating an object in the
users's code they must by definition be part of the interface (the
user's code is the exterior you are talking about).

--
Erik Wikström

iesvs@free.fr wrote:I haven't read this whole back-and-forth, but I totally understand where
iesvs is coming from here. I've often wished I could declare just the public
part of a class in a header, and the private part elsewhere. And there's no
deep reason I shouldn't be able to do that; it's just a missing language
feature. C++ already supports incomplete struct/class types, which
correspond to the special case where everything is hidden. It could just as
well support partially complete types. I can even think of a reasonably
intuitive syntax for it that doesn't require any new keywords:

// header

class A {
public:
float f;
void method();
... // <- that's a literal '...'
};

// private implementation

class A : public Base {
public:
float f; // must match (enforced by implementation)
void method();
private:
int x;
};

void A::method() { ... }

The current syntax "class A;" would be identical to "class A { ... };".

I suspect, though, that if I proposed this to the standards committee,
they'd say "use virtual functions". And indeed you can get exactly the same
effect with virtual functions:

// header

class A {
public:
float f;
virtual void method() = 0;
};

// private implementation

class A_impl : public A, public Base {
public:
void method();
private:
int x;
};

void A_impl::method() { ... }

So this is what I recommend to the original poster. As far as I can tell, it
does exactly what you want. The only advantage of incomplete class
declarations would be efficiency: in a typical implementation they'd save
you a machine word per object and a hard-to-predict indirect jump per method
call.

-- Ben

// headerSome have already suggested that (I think).
I don't want to create a new class (A_impl) to do that. It's a hack
and I refuse hacks, I'm too fundamentalist for that.

On Sep 27, 6:50 pm, Ben Rudiak-Gould <br276delet...@cam.ac.ukwrote:In a way, yes. On the other hand, supporting this would create
very serious implementation problems. Perhaps if you find a
reasonable way to implement it, it could be adopted; at present,
the best compiler experts I know don't consider it implementable
(while still allowing value semantics, of course).
If they had the same restrictions as incomplete types, maybe.
But then, you'd need to define a special syntax, etc., to define
them. And what does it buy you? What can you do with them that
you can't already do with incomplete types.
Exactly.

Note that if you allow declaring instances of the "partially
complete" class A, you run into serious implementation problems.
And if you don't, your partially complete class doesn't provide
any advantage with respect to the above.
And the compilation firewall idiom allows replacing the virtual
function call with a non-virtual one (but imposes an additional
indirection on the data accesses, or a second function call).

This is, perhaps, the reason why C++ does things the way it
does. You, as programmer, choose the compromize; it's not
forced on you by the language. For large, complex objects,
where the compile time dependencies are an issue, you use either
an abstract base class or the compilation firewall idiom. For
simple, time critical values (e.g. things like std::complex),
you declare the private members in the header, so that the
compiler can optimize their use. You have the choice; it isn't
imposed on you by the language.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
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