On Apr 6, 7:55am, "copx" <c...@gazeta.pl> wrote:
> "Richard Heathfield" <r...@see.sig.invalid> schrieb im Newsbeitragnews:NKOdnfOFf_8s8WXanZ2dnUVZ8vKdnZ2d@b t.com...
>
> > copx said:
> >> Are their any counter-arguments against Stroustroups claim?
>
> > My favourite example is a 450-line C++ program I was shown, about eight
> > years ago, which had taken four man-years to write and took about 10
> > minutes to process a fairly trivial amount of data. I rewrote it from spec
> > (because I saw no point in rewriting it from the code) in a single day, in
> > C. My version took considerably less than a second to process the same
> > amount of data. There is more to efficiency than mere language choice.
>
> Of course, a bad programmer will write worse code in any language compared
> to a good programmer. However, the question here is - assuming programmers
> of equal skill - who would produce more efficient code if one used C and the
> other used C++. So far the answer seems to be the C++ guy would win

Assuming two programmers of equal skill, on the whole the one writing
in C will write far nicer code than the one in C++ (nicer in terms of
ease of readibility, maintainability, and lack of bugs). And he will
write it quicker.

Assuming the resulting C++ program actually works as intended, it will
run at pretty much the same speed as the C one.

Assumming a team of C++ programmers, the useful subset of the bloated
nightmare of C++ that they know in common is called C.

C++ is a virus. There will come a day when it is wiped from the Earth.

> On Sun, 06 Apr 2008 00:24:06 -0700, bc1891 wrote:

> C++ is a virus. There will come a day when it is wiped from the Earth.

ouch! , sometimes I wonder why people give such titles to C++.

:: Is C++ powerful ?

yes, a lot.



:: Is C++ complex ?

of course.



:: Is C++ monstrous and efficient ?

yes, of course it is like this heck a lot :O)



:: Is programming in C hard ?

Nah, it is a *lot* harder than what you do with other languages.


I am still looking for the day when more and more people will give titles
to VB, .NET or Java rather than yanking their brains around C vs C++
flame-wars.

you may be young and this young-time of yours is too precious to waste to
C vs C++. If you are really interested please use it on "VB vs any Good
Language" ( Python, Common Lisp, Ruby, Ada etc etc)

I give the same advice to "copx" (the OP)



--
http://lispmachine.wordpress.com/

Please remove capital 'V's when you reply
to me via e-mail.

> On Sun, 06 Apr 2008 13:30:22 +0500, arnuld wrote:


> :: Is C++ powerful ?
>
> yes, a lot.

> ....[SNIP]....

> I give the same advice to "copx" (the OP)

Oh.. no. I unintentionally f*cked-up the thread from other NG. Negligence
is on my part.

I apologize for the mistake & inconvenience I have caused.



--
http://lispmachine.wordpress.com/

Please remove capital 'V's when you reply
to me via e-mail.

bc1891@googlemail.com wrote:
> Assuming two programmers of equal skill, on the whole the one writing
> in C will write far nicer code than the one in C++ (nicer in terms of
> ease of readibility, maintainability, and lack of bugs). And he will
> write it quicker.

Here we have a perfect example of the C-hacker syndrome.

I bet you are a big fan of Linus Torvalds. (Heck, you may even *be*
Linus Torvalds. Exactly the same type of trolling.)

arnuld <arnVuld@ippiVmail.com> wrote in news:pan.2008.04.06.08.30.19.428735
@ippiVmail.com:

>> On Sun, 06 Apr 2008 00:24:06 -0700, bc1891 wrote:
>
>> C++ is a virus. There will come a day when it is wiped from the Earth.
>
> ouch! , sometimes I wonder why people give such titles to C++.

My guess is that they are bad and/or lazy programmers and blame the
language for not being able to learn it. I'm not fond of several languages
but their existence doesn't bother me. I just choose not to use them.

> On Sun, 06 Apr 2008 12:59:26 +0300, Juha Nieminen wrote:

> I bet you are a big fan of Linus Torvalds.




> (Heck, you may even *be*
> Linus Torvalds. Exactly the same type of trolling.)


Linus also gives same types on ideas on why he did not choose a
microkernel based design.



-- http://lispmachine.wordpress.com/

Please remove capital 'V's when you reply to me via e-mail.

On Sun, 06 Apr 2008 12:59:26 +0300, Juha Nieminen wrote:

> bc1891@googlemail.com wrote:
>> Assuming two programmers of equal skill, on the whole the one writing
>> in C will write far nicer code than the one in C++ (nicer in terms of
>> ease of readibility, maintainability, and lack of bugs). And he will
>> write it quicker.
>
> Here we have a perfect example of the C-hacker syndrome.
>
> I bet you are a big fan of Linus Torvalds. (Heck, you may even *be*
> Linus Torvalds. Exactly the same type of trolling.)


I happen to like both C and C++, but there _are_ cases where C++ makes
things a little less clear than they could be. As a trivial example:

int x = 3, y;

y = func(x);

Quick: what's the value of x?

In C the answer's easy: the value is 3. In C++, there is absolutely no
way to know, at the point of calling, what will happen to the variable.

This makes the same code, in C, somewhat easier to read, as the
indicators of whether the value will be modified or not are right there,
in your face - or not. In C++, there's no indication whatsoever, meaning
you have to hunt for the called function, check its interface, realize
that yes, it modifies the value and add this to the growing list of
pointless things to remember which shouldn't need remembering.

On 8 Apr., 19:20, Kelsey Bjarnason <kbjarna...@gmail.com> wrote:
> On Sun, 06 Apr 2008 12:59:26 +0300, Juha Nieminen wrote:
> > bc1...@googlemail.com wrote:
> >> Assuming two programmers of equal skill, on the whole the one writing
> >> in C will write far nicer code than the one in C++ (nicer in terms of
> >> ease of readibility, maintainability, and lack of bugs). And he will
> >> write it quicker.
>
> > Here we have a perfect example of the C-hacker syndrome.
>
> > I bet you are a big fan of Linus Torvalds. (Heck, you may even *be*
> > Linus Torvalds. Exactly the same type of trolling.)
>
> I happen to like both C and C++, but there _are_ cases where C++ makes
> things a little less clear than they could be. As a trivial example:
>
> int x = 3, y;
>
> y = func(x);
>
> Quick: what's the value of x?
>
> In C the answer's easy: the value is 3. In C++, there is absolutely no
> way to know, at the point of calling, what will happen to the variable.
>
> This makes the same code, in C, somewhat easier to read, as the
> indicators of whether the value will be modified or not are right there,
> in your face - or not.
Right. But this is only true in such trivial cases as the above where
you allow such an absurd name. Replace the name with some reasonable
one, such as square or fibonacci, and no one will be in doubt. I have
heard others complain like you, but never found statements such as the
above to be a real problem.
A much larger problem has been in absurd declaration such as the
above. Are you quite sure that it should read int x = 3; int y; (as
you imply) and not int x = (3,y); ? ;-)
> In C++, there's no indication whatsoever, meaning
> you have to hunt for the called function, check its interface, realize
> that yes, it modifies the value and add this to the growing list of
> pointless things to remember which shouldn't need remembering.

If you need to look at the code, you should know what func does
anyway!

/Peter

On Apr 8, 12:20pm, Kelsey Bjarnason <kbjarna...@gmail.com> wrote:
> I happen to like both C and C++, but there _are_ cases where C++ makes
> things a little less clear than they could be. As a trivial example:
>
> int x = 3, y;
>
> y = func(x);
>
> Quick: what's the value of x?

Maybe with a name better than "func" it would be less ambiguous.

> In C the answer's easy: the value is 3. In C++, there is absolutely no
> way to know, at the point of calling, what will happen to the variable.

And in C, there's absolutely no way to know who's fiddling around with
your struct members because you can't restrict access to them.

lbonafide@yahoo.com said:

<snip>

> And in C, there's absolutely no way to know who's fiddling around with
> your struct members because you can't restrict access to them.

Wrong. Maybe *you* can't restrict access to them, but I can, and so can
quite a few others in comp.lang.c. The technique is not difficult.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

peter koch <peter.koch.larsen@gmail.com> writes:
> On 8 Apr., 19:20, Kelsey Bjarnason <kbjarna...@gmail.com> wrote:
[...]
>> int x = 3, y;
>>
>> y = func(x);
>>
>> Quick: what's the value of x?
[...]
> A much larger problem has been in absurd declaration such as the
> above. Are you quite sure that it should read int x = 3; int y; (as
> you imply) and not int x = (3,y); ? ;-)
[...]

Yes. An initializer must be an assigment-expression, which means it
cannot have a comma operator at its top level.

The same restriction applies to function arguments. In both cases,
it's because the comma is used as a delimiter in that context, so it's
not allowed as an operator.

I suppose this:
int x = 3;
int y;
would be clearer, but I have no problem with either form.

--
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Apr 8, 12:20pm, Kelsey Bjarnason <kbjarna...@gmail.com> wrote:
> int x = 3, y;
>
> y = func(x);
>
> Quick: what's the value of x?
>
> In C the answer's easy: the value is 3. In C++, there is absolutely no
> way to know, at the point of calling, what will happen to the variable.
>
> This makes the same code, in C, somewhat easier to read, as the
> indicators of whether the value will be modified or not are right there,
> in your face - or not. In C++, there's no indication whatsoever, meaning
> you have to hunt for the called function, check its interface, realize
> that yes, it modifies the value and add this to the growing list of
> pointless things to remember which shouldn't need remembering.

ITYM "... realize that yes, it /could modify/ the value ....". Unless
you look at func's definition, one cannot know for sure (just from
checking its interface) if it actually modifies 'x' or not.

- Anand

[snips]

On Tue, 08 Apr 2008 10:45:09 -0700, peter koch wrote:

> Right. But this is only true in such trivial cases as the above where
> you allow such an absurd name. Replace the name with some reasonable
> one, such as square or fibonacci, and no one will be in doubt.


Really? Fine: try this:

string a, b;

a = somevalue;
b = trim(a);

If the intent of trim is to act like the similar function in PHP - i.e.
to remove leading and trailing whitespace - what does this tell us about
the effect, if any, on a?

Oh, right, nothing. Hmm. So what's a good name for this? How about, oh,
trim_which_modifies_its_parameter()? I don't want to type that.

> I have
> heard others complain like you, but never found statements such as the
> above to be a real problem.

Yet the problem remains: C++ makes the issue of whether a passed
parameter gets modified or not absolutely indeterminate at point of call
- meaning the poor bastard having to maintain the code has no hope, by
reading the portion of code he's trying to work on, of figuring out what
is actually going on.

This is not a particularly good design.


> A much larger problem has been in absurd declaration such as the above.
> Are you quite sure that it should read int x = 3; int y; (as you imply)

I implied that? Where? I wrote int x = 3, y; There's only one semicolon
in there, only one instance of "int". Why would you think this somehow
"implies" a completely different manner of writing code? Does your way
of writing it imply it should be re-done in Pascal? No? Why not? You
seem to be taking purely arbitrary paths, so why not that one?


> If you need to look at the code, you should know what func does anyway!

Why? Since it cannot modify the passed parameter, what it does is
fundamentally irrelevant to debugging the local problem. That is, unless
someone invented a method of passing parameters which would then be
modified, but making this absolutely invisible to the maintenance
programmer looking at the calling code.

Oh, yeah, they did exactly that, didn't they? Good, now instead of
focusing on *this* piece of code, one has to examine every called
function, not for its effects on output and the like, but its effects on
*local* variables it gives absolutely no indication it will be modifying.

Information hiding can be good. This sort is bad.

On Tue, 08 Apr 2008 11:35:10 -0700, Anand Hariharan wrote:

> On Apr 8, 12:20Âpm, Kelsey Bjarnason <kbjarna...@gmail.com> wrote:
>> Â int x = 3, y;
>>
>> Â y = func(x);
>>
>> Quick: what's the value of x?
>>
>> In C the answer's easy: the value is 3. ÂIn C++, there is absolutely no
>> way to know, at the point of calling, what will happen to the variable.
>>
>> This makes the same code, in C, somewhat easier to read, as the
>> indicators of whether the value will be modified or not are right
>> there, in your face - or not. ÂIn C++, there's no indication
>> whatsoever, meaning you have to hunt for the called function, check its
>> interface, realize that yes, it modifies the value and add this to the
>> growing list of pointless things to remember which shouldn't need
>> remembering.
>
> ITYM "... realize that yes, it /could modify/ the value ....". Unless
> you look at func's definition, one cannot know for sure (just from
> checking its interface) if it actually modifies 'x' or not.

Indeed. However, the more important point is that you can be reasonably
certain that it will *not* be modifying values unless there's a pointer
involved somewhere, which is generally *visible* at the point of the call.

eg:

void func1(void)
{
int x = 3;

func2(x);
}


Anyone seeing this sort of thing wouldn't _need_ to examine "func2" to
see if x is modified. It's not. Simple as that. Unless you're using C+
+, in which case you have no way to tell either way.

Kelsey Bjarnason <kbjarnason@gmail.com> writes:
> [snips]
>
> On Tue, 08 Apr 2008 10:45:09 -0700, peter koch wrote:
[...]
>> I have
>> heard others complain like you, but never found statements such as the
>> above to be a real problem.
>
> Yet the problem remains: C++ makes the issue of whether a passed
> parameter gets modified or not absolutely indeterminate at point of call
> - meaning the poor bastard having to maintain the code has no hope, by
> reading the portion of code he's trying to work on, of figuring out what
> is actually going on.
>
> This is not a particularly good design.
[...]

This thread is cross-posted between comp.lang.c and comp.lang.c++,
which is rarely a good idea, especially when what's being discussed is
a controversial difference between the two languages.

I'll just point out that there are plenty of programming languages in
which functions (procedures, subprograms, whatever) can modify their
arguments, and programmers who use those languages generally manage to
cope with the pain.

If I were inventing a new language, I might consider requiring a
special syntax to distinguish between arguments that are passed by
value and arguments whose value might be changed. For example:

sin(x) /* passed by value, can't modify x */
set_sin(@x) /* can modify x */

--
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 8 Apr., 21:40, Kelsey Bjarnason <kbjarna...@gmail.com> wrote:
> [snips]
>
> On Tue, 08 Apr 2008 10:45:09 -0700, peter koch wrote:
> > Right. But this is only true in such trivial cases as the above where
> > you allow such an absurd name. Replace the name with some reasonable
> > one, such as square or fibonacci, and no one will be in doubt.
>
> Really? Fine: try this:
>
> string a, b;
>
> a = somevalue;
> b = trim(a);

In C++ you would never write as above. It would be
string a(somevalue);
string b(trim(a));

or

string a = somevalue;
string b = trim(a);


>
> If the intent of trim is to act like the similar function in PHP - i.e.
> to remove leading and trailing whitespace - what does this tell us about
> the effect, if any, on a?

I would assume this would mean that there would be no effect on a. If
trim would trim its parameter, the name of the function would indicate
this.

>
> Oh, right, nothing. Hmm. So what's a good name for this? How about, oh,
> trim_which_modifies_its_parameter()? I don't want to type that.

to_trim would be my choice, as_trim being the non-modifying name in
those rare cases where I would be in doubt.

>
> > I have
> > heard others complain like you, but never found statements such as the
> > above to be a real problem.
>
> Yet the problem remains: C++ makes the issue of whether a passed
> parameter gets modified or not absolutely indeterminate at point of call
> - meaning the poor bastard having to maintain the code has no hope, by
> reading the portion of code he's trying to work on, of figuring out what
> is actually going on.
>
> This is not a particularly good design.
I can't see how else you could design the code (unless you suggest
demanding pointers for the parameters which is not at all clearer), so
lets not discuss the design of C++ here. It is designed as it is and
not anything we can really do anything about.
>
> > A much larger problem has been in absurd declaration such as the above.
> > Are you quite sure that it should read int x = 3; int y; (as you imply)
>
> I implied that? Where? I wrote int x = 3, y; There's only one semicolon
> in there, only one instance of "int". Why would you think this somehow
> "implies" a completely different manner of writing code? Does your way
> of writing it imply it should be re-done in Pascal? No? Why not? You
> seem to be taking purely arbitrary paths, so why not that one?

It was just a remark about clarity - namely that I found your way of
declaring the variables unclear.
Also I do not see the connotion to Pascal. Here it was allowed (I
believe!) to declare several variables together - e.g. var i,j:
integer;

>
> > If you need to look at the code, you should know what func does anyway!
>
> Why? Since it cannot modify the passed parameter, what it does is
> fundamentally irrelevant to debugging the local problem. That is, unless
> someone invented a method of passing parameters which would then be
> modified, but making this absolutely invisible to the maintenance
> programmer looking at the calling code.

If you need to have a look at a piece of code, do you seriously
suggest that this can be done without at least a casual knowledge
about what called functions do?
>
> Oh, yeah, they did exactly that, didn't they? Good, now instead of
> focusing on *this* piece of code, one has to examine every called
> function, not for its effects on output and the like, but its effects on
> *local* variables it gives absolutely no indication it will be modifying.
>
> Information hiding can be good. This sort is bad.

Certainly. That is why you choose your function (and variable) names
with care.

/Peter

On 8 Apr., 20:21, Keith Thompson <ks...@mib.org> wrote:
> peter koch <peter.koch.lar...@gmail.com> writes:
> > On 8 Apr., 19:20, Kelsey Bjarnason <kbjarna...@gmail.com> wrote:
> [...]
> >> int x = 3, y;
>
> >> y = func(x);
>
> >> Quick: what's the value of x?
> [...]
> > A much larger problem has been in absurd declaration such as the
> > above. Are you quite sure that it should read int x = 3; int y; (as
> > you imply) and not int x = (3,y); ? ;-)
>
> [...]
>
> Yes. An initializer must be an assigment-expression, which means it
> cannot have a comma operator at its top level.
>
> The same restriction applies to function arguments. In both cases,
> it's because the comma is used as a delimiter in that context, so it's
> not allowed as an operator.
>
> I suppose this:
> int x = 3;
> int y;
> would be clearer, but I have no problem with either form.

Yup - it would be much clearer. I probably would not let that one pass
in a C++ code review (also because there is a potentially
uninitialised variable), but of course C is a different beast.

I certainly would not let int* i,j pass in either language.

/Peter

Kelsey Bjarnason wrote:
>
> Yet the problem remains: C++ makes the issue of whether a passed
> parameter gets modified or not absolutely indeterminate at point of call
> - meaning the poor bastard having to maintain the code has no hope, by
> reading the portion of code he's trying to work on, of figuring out what
> is actually going on.
>
So you would sacrifice the convenience of operator overloading to avoid
an obscure corner case that any half decent tagging editor would solve
in a blink of an eye?

--
Ian Collins.

peter koch <peter.koch.larsen@gmail.com> writes:
> On 8 Apr., 20:21, Keith Thompson <ks...@mib.org> wrote:
[...]
>> > On 8 Apr., 19:20, Kelsey Bjarnason <kbjarna...@gmail.com> wrote:
>> >> int x = 3, y;
[...]
>> I suppose this:
>> int x = 3;
>> int y;
>> would be clearer, but I have no problem with either form.
>
> Yup - it would be much clearer. I probably would not let that one pass
> in a C++ code review (also because there is a potentially
> uninitialised variable), but of course C is a different beast.
>
> I certainly would not let int* i,j pass in either language.

Agreed. But this:
int *i, j;
might be acceptable in C (except that "i" is a terrible name for a
pointer). But yes, I'd prefer
int *i; // or "int* i;" if you insist
int j;
in either language.

Note that this:
int *ptr;
tends to be the preferred spacing in C, and this:
int* ptr;
tends to be the preferred spacing in C++. There are valid reasons for
either convention.

--
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Tue, 08 Apr 2008 19:45:01 GMT, Kelsey Bjarnason
<kbjarnason@gmail.com> wrote:

>On Tue, 08 Apr 2008 11:35:10 -0700, Anand Hariharan wrote:
>
>> On Apr 8, 12:20Âpm, Kelsey Bjarnason <kbjarna...@gmail.com> wrote:
>>> Â int x = 3, y;
>>>
>>> Â y = func(x);
>>>
>>> Quick: what's the value of x?
>>>
>>> In C the answer's easy: the value is 3. ÂIn C++, there is absolutely no
>>> way to know, at the point of calling, what will happen to the variable.
>>>
>>> This makes the same code, in C, somewhat easier to read, as the
>>> indicators of whether the value will be modified or not are right
>>> there, in your face - or not. ÂIn C++, there's no indication
>>> whatsoever, meaning you have to hunt for the called function, check its
>>> interface, realize that yes, it modifies the value and add this to the
>>> growing list of pointless things to remember which shouldn't need
>>> remembering.
>>
>> ITYM "... realize that yes, it /could modify/ the value ....". Unless
>> you look at func's definition, one cannot know for sure (just from
>> checking its interface) if it actually modifies 'x' or not.
>
>Indeed. However, the more important point is that you can be reasonably
>certain that it will *not* be modifying values unless there's a pointer
>involved somewhere, which is generally *visible* at the point of the call.
>
>eg:
>
>void func1(void)
>{
> int x = 3;
>
> func2(x);
>}
>
>
>Anyone seeing this sort of thing wouldn't _need_ to examine "func2" to
>see if x is modified. It's not. Simple as that. Unless you're using C+
>+, in which case you have no way to tell either way.
>

Your objection is correct, but specious.

There are a myriad of C functions (both that you/someone else wrote)
as well as ones in the stdio/stdlib/etc., that take pointers as
parameters. You cannot tell just by looking at the call to them
whether they modify what's being pointed at either.

Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Richard Heathfield wrote:
> lbonafide@yahoo.com said:
>
> <snip>
>
>> And in C, there's absolutely no way to know who's fiddling around with
>> your struct members because you can't restrict access to them.
>
> Wrong. Maybe *you* can't restrict access to them, but I can, and so can
> quite a few others in comp.lang.c. The technique is not difficult.

I have always detested this kind of argument. "Maybe you can't, but we
who are better than you can", "it's quite easy", and then don't even
show this "easy" solution at all (which usually involves ugly hacks and
jumping through completely unnecessary hoops).

Reminds me of the C-hackers who insist that it's "easy" and "feasible"
to use dynamically bound "member functions" in structs, as if that
somehow made C as good as C++ (yet the big problem with that hack is
that each "member function" of the struct increases the size of the
struct, which in many cases is a completely useless waste and makes that
struct larger and more inefficient).

"Juha Nieminen" <nospam@thanks.invalid> wrote in message
news:47fc487e$0$23834$4f793bc4@news.tdc.fi...
> Richard Heathfield wrote:
>> lbonafide@yahoo.com said:
>>
>> <snip>
>>
>>> And in C, there's absolutely no way to know who's fiddling around with
>>> your struct members because you can't restrict access to them.
>>
>> Wrong. Maybe *you* can't restrict access to them, but I can, and so can
>> quite a few others in comp.lang.c. The technique is not difficult.
>
> I have always detested this kind of argument. "Maybe you can't, but we
> who are better than you can", "it's quite easy", and then don't even
> show this "easy" solution at all (which usually involves ugly hacks and
> jumping through completely unnecessary hoops).
>
> Reminds me of the C-hackers who insist that it's "easy" and "feasible"
> to use dynamically bound "member functions" in structs, as if that
> somehow made C as good as C++ (yet the big problem with that hack is
> that each "member function" of the struct increases the size of the
> struct, which in many cases is a completely useless waste and makes that
> struct larger and more inefficient).

Is this on topic:

http://groups.google.com/group/comp....b16567e49c42fc

?

Juha Nieminen said:

> Richard Heathfield wrote:
>> lbonafide@yahoo.com said:
>>
>> <snip>
>>
>>> And in C, there's absolutely no way to know who's fiddling around with
>>> your struct members because you can't restrict access to them.
>>
>> Wrong. Maybe *you* can't restrict access to them, but I can, and so can
>> quite a few others in comp.lang.c. The technique is not difficult.
>
> I have always detested this kind of argument.

Let's see whether I can amend it to your liking.

> "Maybe you can't, but we
> who are better than you can",

Not what I meant. Mr lbonafide said that there's absolutely no way, so I
presume he accepts that he can't do it, and that his inability to do it is
not in dispute. That doesn't mean I'm "better" than him. It does, however,
appear to mean that I know something he doesn't - which is easily fixed,
of course.

> "it's quite easy",

Aye, it is. Sorry.

> and then don't even
> show this "easy" solution at all

See below.

> (which usually involves ugly hacks and
> jumping through completely unnecessary hoops).

Um, it's not /that/ ugly a hack, and I assure you I'll only jump through
*necessary* hoops.

The technique involves a minimum of three files - the interface (.h), the
implementation (.c, which you *don't release*), and the driver, which the
user-programmer writes.

Here is our interface (which we ship):

#ifndef H_POINT
#define H_POINT 1

#include <limits.h>

#define POINT_INVALID INT_MIN

typedef struct point_ point;

point *point_make(int, int);
void point_destroy(point **);
int point_setx(point *, int);
int point_sety(point *, int);
int point_set(point *, int, int);
double point_diff(const point *, const point *);
#endif

The important point (if you'll forgive the word) is that the point type is
declared but *not* defined, so its members are not visible. More about
that shortly.

The totally unimportant point is that this is just an example, and so you
shouldn't expect to see a complete function suite here!

Implementation file (NOT shipped):

#include "point.h"

#include <stdlib.h>
#include <math.h>

struct point_
{
int x;
int y;
};

point *point_make(int x, int y)
{
point *new = malloc(sizeof *new);
if(new != NULL)
{
new->x = x;
new->y = y;
}
return new;
}
void point_destroy(point **old)
{
if(old != NULL)
{
free(*old);
*old = NULL;
}
}

int point_setx(point *p, int x)
{
int old = POINT_INVALID;

if(p != NULL)
{
old = p->x;
p->x = x;
}
return old;
}

int point_sety(point *p, int y)
{
int old = POINT_INVALID;

if(p != NULL)
{
old = p->y;
p->y = y;
}
return old;
}

int point_set(point *p, int x, int y)
{
int rc = POINT_INVALID;

if(p != NULL)
{
rc = 0;
p->x = x;
p->y = y;
}
return rc;
}

double point_diff(const point *pa, const point *pb)
{
double d = 0.0;

if(pa != NULL && pb != NULL)
{
double xd = pa->x - pb->x;
double yd = pa->y - pb->y;
d = sqrt(xd * xd + yd * yd);
}

return d;
}

We don't ship this to the user. Instead, we compile it, put the resulting
object code into a library, and ship the library.

Test driver:

#include "point.h"

#include <stdio.h>

int main(void)
{
point *p1 = point_make(1, 1);
if(p1 != NULL)
{
point *p2 = point_make(4, 5);
if(p2 != NULL)
{
double d = point_diff(p1, p2);
printf("The hypotenuse is %f\n", d);
point_destroy(&p2);
}
point_destroy(&p1);
}
return 0;
}

This works. (Try it.)

The following test driver does *not* work:

#include "point.h"

#include <stdio.h>

int main(void)
{
point *p1 = point_make(1, 1);
size_t size = sizeof *p1; /* can't do this */
point instance; /* can't do this either */

instance.x = 42; /* or this! */

if(p1 != NULL)
{
point *p2 = point_make(4, 5);
if(p2 != NULL)
{
double d = point_diff(p1, p2);
printf("The hypotenuse is %f\n", d);
point_destroy(&p2);
}
point_destroy(&p1);
}
return 0;
}

When I compile this, I get the following errors:

driver.c: In function `main':
driver.c:8: dereferencing pointer to incomplete type
driver.c:9: storage size of `instance' isn't known

Thus, you *can* restrict access to members of a struct, QED.


> Reminds me of the C-hackers who insist that it's "easy" and "feasible"
> to use dynamically bound "member functions" in structs, as if that
> somehow made C as good as C++ (yet the big problem with that hack is
> that each "member function" of the struct increases the size of the
> struct, which in many cases is a completely useless waste and makes that
> struct larger and more inefficient).

<shrug> The "as if that somehow made C as good as C++" bit is mere flame
bait. C and C++ are different languages with different goals and different
user bases. To claim that one is "better" than another, without specifying
in what way it is better and for whom, is to fail to understand that there
are good reasons for having more than one programming language.

Whilst it /is/ not only feasible but even easy to use dynamically bound
member functions in structs, it is certainly true that this incurs an
overhead for the pointer in every instance of the struct, and this cost
should be considered when deciding whether or not to pursue this course.

The way I resolve this myself is simple - either I'm going to be using a
lot of structs, in which case they're probably going to be in some kind of
container, so I'll put the pointers in the container instead - which is
normally okay because all the structs in any given container are generally
going to want to be processed in the same way), or I only have a few, in
which case the overhead is no big deal.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999