when to use C and when to use C++

[jacob navia]

Ian Collins a écrit :

jacob navia wrote:
[...]


That is an array only in very special situations... In most cases it
will "decay" into a pointer to int. The size information is destroyed
or discarded and there it goes, a buffer overflow please...


This deficiency is being addressed, have a look at std::tr1::array. Not
standard yet, but on its way.

That's C++, isn't it? Did you perhaps momentarily forget which
newsgroup you're reading?

Oops, I forgot to stick to the group's main topics of insults and
accusations...

It won't happen again.

How true!

 

[jacob navia]

Skarmander a écrit :

Ian Collins wrote:

C with a garbage collector and exception handling would come a lot
closer to matching C++ (for those who insist).

I insist and I have made exactly such an implementation available

http://www.cs.virginia.edu/~lcc-win32

 

[Ian Collins]

Skarmander a écrit :

Not me squire, I don't agree with this. Please take greater care with
your quoting.

 

[jacob navia]

Richard Heathfield a écrit :

jacob navia said:

At first I wasn't sure if I'd take part in this C Vs C++ discussion, but
I'll dip my feet...

jacob navia:

This means in practice that lists, arrays and many other commonly used

data structures are absent from the C standard library.

int array[5];

That is an array only in very special situations...

Wrong. The array is always an array, throughout its lifetime.

In most cases it
will "decay" into a pointer to int.

Wrong. Its name does, but it doesn't.

The size information is destroyed
or discarded

Wrong. The size information is available via sizeof array, and the number of
elements in the array is available via the canonical expression:

sizeof array / sizeof array[0]

<snip>

[root@gateway tmp]# cat tarray.c
void fn(int array[8])
{
printf("sizeof array = %d\n",sizeof(array));
}

int main(void)
{
int array[8];

fn(array);
}
[root@gateway tmp]# gcc tarray.c
[root@gateway tmp]# ./a.out
sizeof array = 4
[root@gateway tmp]#

 

[Richard Bos]

Richard Heathfield a écrit :

jacob navia said:

Frederick Gotham wrote:

jacob navia:

This means in practice that lists, arrays and many other commonly used

data structures are absent from the C standard library.

int array[5];

This (which is a declaration of an array)...

That is an array only in very special situations...

Wrong. The array is always an array, throughout its lifetime.

The size information is destroyed or discarded

Wrong. The size information is available via sizeof array, and the number of
elements in the array is available via the canonical expression:

sizeof array / sizeof array[0]

[root@gateway tmp]# cat tarray.c
void fn(int array[8])

....is not at all the same as this, which is a function declaration which
includes a _pointer_ _argument_ which only looks like an array.

Richard

 

[Frederick Gotham]

jacob navia:

That is an array only in very special situations... In most cases it
will "decay" into a pointer to int. The size information is destroyed
or discarded and there it goes, a buffer overflow please...

An array can implicitly convert to a pointer to its first element.

A double can implicitly convert to an int.

I would be wrong to suggest that a double is just int because it can
implicitly convert to one. Similarly, you can't say that an array is just a
pointer simply because it can implicitly convert to one.

If you want to be able to pass an array to a function and still retain its
length, then simply do:

#include <stddef.h>

void Func(T *p,size_t len); /* Defined elsewhere */

#define FUNC(arr) (Func(arr,sizeof arr/sizeof*arr))

This would sort of be equivalent to the following C++ code:

#include <cstddef>

template<class T,std::size_t len>
void Func(T (&arr)[len]);

 

[Frederick Gotham]

Frederick Gotham:

#define FUNC(arr) (Func(arr,sizeof arr/sizeof*arr))

Of course, I should have parentheses around all appearances of the macro
parameter.

 

[jacob navia]

Richard Bos a écrit :

Richard Heathfield a écrit :

jacob navia said:


Frederick Gotham wrote:


jacob navia:

This means in practice that lists, arrays and many other commonly used


data structures are absent from the C standard library.

int array[5];

This (which is a declaration of an array)...

That is an array only in very special situations...

Wrong. The array is always an array, throughout its lifetime.


The size information is destroyed or discarded

Wrong. The size information is available via sizeof array, and the number of
elements in the array is available via the canonical expression:

sizeof array / sizeof array[0]

[root@gateway tmp]# cat tarray.c
void fn(int array[8])

...is not at all the same as this, which is a function declaration which
includes a _pointer_ _argument_ which only looks like an array.

Richard

What was I saying?

int array[5]: the size information is destroyed or discarded...

Yeah, looks like an array, feel like an array, but it is not an array.
Exactly what I was saying. Besides, passing it to another function
makes all the size information that *could* have been stored there get lost.

 

[jacob navia]

Frederick Gotham a écrit :

jacob navia:





An array can implicitly convert to a pointer to its first element.

A double can implicitly convert to an int.

Both SCALARS. And the conversion is not "in palce". Another object
is created, that contains the transformed value!!!

I would be wrong to suggest that a double is just int because it can
implicitly convert to one. Similarly, you can't say that an array is just a
pointer simply because it can implicitly convert to one.

If you want to be able to pass an array to a function and still retain its
length, then simply do:

#include <stddef.h>

void Func(T *p,size_t len); /* Defined elsewhere */

#define FUNC(arr) (Func(arr,sizeof arr/sizeof*arr))

This would sort of be equivalent to the following C++ code:

#include <cstddef>

template<class T,std::size_t len>
void Func(T (&arr)[len]);

All this would be unnecessary if I could declare:

int fn(int array[253]);

and have the expected semantics.

 

[Richard Heathfield]

jacob navia said:

int array[5];

What was I saying?

int array[5]:

The original, as you can see above, was not int array[5]: but int array[5];
and that means it was /not/ a parameter definition, but an ordinary array
definition.

If you want to talk about parameter definitions, fine, let's talk about
those, but they aren't arrays, so they're not relevant to your point, such
as it was.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

 

[Richard Heathfield]

jacob navia said:

All this would be unnecessary if I could declare:

int fn(int array[253]);

and have the expected semantics.

For those who have read K&R2, the expected semantics is "pointer to an int"
- and that's exactly what you get.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.

 

[jacob navia]

jacob navia said:

All this would be unnecessary if I could declare:

int fn(int array[253]);

and have the expected semantics.

For those who have read K&R2, the expected semantics is "pointer to an int"
- and that's exactly what you get.

The expected semantics are that sizeof(array) is 253*sizeof(int).
Obviously C has a different opinion about this, what I find is a
big problem for the language. Arrays are not first class objects.

 

[Frederick Gotham]

jacob navia:

The expected semantics are that sizeof(array) is 253*sizeof(int).
Obviously C has a different opinion about this, what I find is a
big problem for the language. Arrays are not first class objects.

Let's say that there's a country called Malingua. In Malingua, they
manufacture cars. These cars are just like the cars we have all over the
world, except that their accelerator and break pedals are switched.

What are the expected semantics of pressing the left pedal? Well that depends
entirely on how ignorant you are. There's the correct answer, and then
there's the incorrect answer which you hold to be true on account of your
ignorance.

To say, in this context, that the expected semantics for "sizeof array" is to
be equal to "253*sizeof(int)", is an expectation whose foundation is
ignorance.

Now, since _when_ can we make arguments based upon ignorance? Applying sizeof
to a pointer type yields the size of the pointer. Applying sizeof to an array
type yields the size of the array. If you don't like it, then tough -- but
don't use ignorance as an excuse to imply fault in the C programming
language.

 

[jacob navia]

jacob navia:





Let's say that there's a country called Malingua. In Malingua, they
manufacture cars. These cars are just like the cars we have all over the
world, except that their accelerator and break pedals are switched.

What are the expected semantics of pressing the left pedal? Well that depends
entirely on how ignorant you are. There's the correct answer, and then
there's the incorrect answer which you hold to be true on account of your
ignorance.

To say, in this context, that the expected semantics for "sizeof array" is to
be equal to "253*sizeof(int)", is an expectation whose foundation is
ignorance.

Now, since _when_ can we make arguments based upon ignorance? Applying sizeof
to a pointer type yields the size of the pointer. Applying sizeof to an array
type yields the size of the array. If you don't like it, then tough -- but
don't use ignorance as an excuse to imply fault in the C programming
language.

This is obvious. If I do not like some feature of the language, I am
an ignorant since I should know that "C is like that".

OK.

Be it

 

[Skarmander]

jacob navia:



Let's say that there's a country called Malingua. In Malingua, they
manufacture cars. These cars are just like the cars we have all over the
world, except that their accelerator and break pedals are switched.

What are the expected semantics of pressing the left pedal? Well that depends
entirely on how ignorant you are. There's the correct answer, and then
there's the incorrect answer which you hold to be true on account of your
ignorance.

To say, in this context, that the expected semantics for "sizeof array" is to
be equal to "253*sizeof(int)", is an expectation whose foundation is
ignorance.

Now, since _when_ can we make arguments based upon ignorance? Applying sizeof
to a pointer type yields the size of the pointer. Applying sizeof to an array
type yields the size of the array. If you don't like it, then tough -- but
don't use ignorance as an excuse to imply fault in the C programming
language.

No, let's go one step further. In Malingua, they have objects which
outwardly resemble cars. However, if you get into one, you find out that
they're actually showers. You can't drive them; they just happen to have
car-shaped enclosures.

If you're surprised by this, don't be: it's your own fault for assuming that
things that look like cars in Malingua are cars. If you don't like it, then
tough -- but don't use ignorance as an excuse to imply fault in Malingua's
culture.

Your point (that the semantics of a language are dictated, and match our
expectations only when they happen to do so) is well taken. It is, however,
disingenuous to pretend that therefore, a language can be designed in
whatever way we please and no-one can fault it for having syntax or
semantics that mislead a programmer's casual instincts. Whether you agree
with the criticism is one thing, but simply dismissing it as invalid is silly.

If programming were just a programmer reading the language standard and
henceforth magicking programs out of the void with the assimilated
knowledge, there would be no need to evaluate language design decisions.
However, it's not.

S.

 

[Mark McIntyre]

int array[5];

That is an array only in very special situations... In most cases it
will "decay" into a pointer to int.

Actually the wrong way round. Its a pointer in very special
situations, vis when you pass it as an argument to a function.

The size information is destroyed
or discarded and there it goes, a buffer overflow please...

The overflow or otherwise is a flaw of programme design and/or coding
mistake. Other languages also allow equally stupid programming
mistakes. If this were not so, then surely they'd have taken over the
world already.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

Richard Bos a écrit :

...is not at all the same as this, which is a function declaration which
includes a _pointer_ _argument_ which only looks like an array.

int array[5]: the size information is destroyed or discarded...

You fundamentally misunderstand whats going on here. Naturally, if you
convert it to something else, its not what it was any more.

Yeah, looks like an array, feel like an array, but it is not an array.

In what way is int array[8] not an array?
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

What a logic. This is 100% McIntyre:

When will you realise that insulting the regulars and being a dickhead
is not going to impress anyone? You behave like a teenager on a
hormone trip trying desperately to drink and pull simultaneously, and
rarely has a sigblock been more appropriate.

--
Mark McIntyre

"The lusers I know are so clueless, that if they were dipped in clue
musk and dropped in the middle of pack of horny clues, on clue prom
night during clue happy hour, they still couldn't get a clue."
--Michael Girdwood, in the monastery

 

[Frederick Gotham]

Skarmander:

No, let's go one step further. In Malingua, they have objects which
outwardly resemble cars. However, if you get into one, you find out that
they're actually showers. You can't drive them; they just happen to have
car-shaped enclosures.

OK, I'm with you so far...

If you're surprised by this, don't be: it's your own fault for assuming
that things that look like cars in Malingua are cars. If you don't like
it, then tough -- but don't use ignorance as an excuse to imply fault in
Malingua's culture.

Indeed, as a Westerner, I might find it quite strange that Malingua's
showers look like cars.

What can I do about it? Well, before travelling to Malingua, I can say,
"OK, I going to disregard everything I learned in Ireland, and I'm going to
start afresh in Malingua without making any presumptions as to how things
work."

Is this a viable choice? No, not when talking about going to a different
country.

However, we're talking about a programming language. When you're learning a
new programming language, you can't really build on past experience. You
need to confirm and clarify everything.

The simple fact of the matter is that you have to be in the know when it
comes to a programming language. Some people may presume that you can pass
an array by value, but alas they're wrong. Was their intuition flawed to
think they could simply write:

void Func(int arr[5]) {}

Maybe, maybe not. At the end of the day though, the C Standard is the C
Standard. You can either come to terms with the fact (however much you
dislike it) that Malingua's showers look like cars, or you can rant on
about how backwards Malingua is.

This reminds me of the argument posed recently whereby the following was
deemed to be bad style:

SomeAggregateType obj = {0};

in place of:

SomeAggregateType obj;
memset(&obj,0,sizeof obj);

(Let's forget for the moment that the latter form is only guaranteed to
work with integer types.)

The argument posed was that the former form wasn't explicit enough, i.e.
that the programmer wasn't expected to know that all the members/elements
would be default-initialised.

This, in my own humble opinion, is BS. The semantics of the former form are
perfectly well defined by the Standard, and that's good enough for me. One
shouldn't censor one's code because they think a particular feature might
be a little too advanced for some people.

The only compromise I would accept is the following:

SomeAggregateType obj = {0}; /* Everything ges default value */

I find it quite odd that a programmer would choose a flawed construct over
a simple comment. We have comments, use them if you like.

Your point (that the semantics of a language are dictated, and match our
expectations only when they happen to do so) is well taken. It is,
however, disingenuous to pretend that therefore, a language can be
designed in whatever way we please and no-one can fault it for having
syntax or semantics that mislead a programmer's casual instincts.

Yes, we can agree (slightly) on this one. Maybe C should have disallowed
the following:

void Func(int arr[5]) {}

Whether you agree with the criticism is one thing, but simply dismissing
it as invalid is silly.

It is the implication of a flaw in C that I was dismissing.

If programming were just a programmer reading the language standard and
henceforth magicking programs out of the void with the assimilated
knowledge, there would be no need to evaluate language design decisions.
However, it's not.

Oh but a boy can dream...

 

[Frederick Gotham]

Mark McIntyre:

<snip tripe>

While I disagree with quite a few of the points Jacob makes, I still think he
comes across as a nice, reasonable person. I've nothing bad to say about him.

I cannot the same for you.