Converting to/from pointer

[Martin Ambuhl]

OK, maybe in C there's some subtelty that I haven't worked out, but
definitely in C++ - one of the main "soundbite to remember" in my C++
class was "an array is just the same thing as a constant pointer".

That is wrong in both C++ and C. Either your instructor was grossly in
error or you misunderstood.

 

[Barry Schwarz]

No, a pointer to a float is the same as an array of float.

#include <stdio.h>
int main(void)
{
float array[10] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
float *pointer = array;

printf("%lu %lu\n", sizeof array, sizeof pointer);

It would be better to cast the last two arguments so someone whose
system did not #define size_t as unsigned long would not invoke
undefined behavior.

return 0;
}

Displays "40 4" on my system. So? They're the same but one is ten times
bigger?

At least now we know what the original poster meant by superset.


Remove del for email

 

[Malcolm McLean]

No, a pointer to a float is the same as an array of float.

#include <stdio.h>
int main(void)
{
float array[10] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
float *pointer = array;

printf("%lu %lu\n", sizeof array, sizeof pointer);
return 0;
}

Displays "40 4" on my system. So? They're the same but one is ten times
bigger?

So there's a bug in the standard that breaks array pointer equivalence? It
happens to even the best languages.
Deprectate sizeof( object) and only allow sizeof(type) and the pro

 

[Keith Thompson]

I really find it hard to understand the bile and negativity that seems
to be this Group's bread and butter! I've read any number of Groups and
Forums and by and large they're all pretty friendly places, but here all
I've got is a torrent of abuse!

You have been advised repeatedly, and in many cases quite politely,
that your question is about C++, not about C, and that you should post
it in comp.lang.c++, not in comp.lang.c. And yet you persist in
posting to comp.lang.c.

You are being rude. It's not surprising that some people here in
comp.lang.c are rude to you in response. There *may* have been some
overreaction; I suggest you ignore it and move on.

It should be obvious by now that you're *not* going to get any useful
responses from comp.lang.c. I don't know what you expect to
accomplish by continuing to post here.

[...]

I really don't understand what this code is doing! I think you
misunderstood my question - &MyVector.front() already works, the problem
is to convert pointer/array to vector without having to copy all data by
hand.

Don't worry about understanding the code; the author was being
sarcastic. He was *pretending* that your question is a valid question
about C (it must have been, since you posted it to comp.lang.c).
Since C doesn't have "vectors", he invented a set of C declarations
for which "&MyVector.front()" would be valid C. The fact that the
resulting code doesn't address your problem is a result of your
posting your question to the wrong newsgroup. (He sprinkled the code
with C++ keywords used as identifiers, guaranteeing that it's not
valid C++, just to emphasize the point.)

Incidentally, I can't tell who wrote the code because you deleted the
attribution lines. Please don't do that.

Your real question, I think, is how to copy the contents of an array
into a C++ vector without copying each element individually. (I don't
know the answer to that, since I'm not sufficiently familiar with C++.
It may well be that the best solution is to copy the elements one at a
time in a loop. Or perhaps std::vector provides an operation to do
what you want in one fell swoop, though such an operation probably
works internally by looping over the elements.) You should ask *that*
question, and you should ask it in comp.lang.c++, where it's perfectly
topical. You'll probably get numerous excellent and well-informed
answers. You might even get some good advice on how to re-structure
your code so the operation you're looking for isn't needed in the
first place.

I suggest starting a new thread in comp.lang.c++, since this one's
signal-to-noise ratio has degraded considerably.

Or you can continue to waste everyone's time by whining about how rude
we've been to you. It's up to you.

 

[James Kanze]

True, but if they had followed usenet etiquette and lurked,

It depends. The original poster apparently cross-posted
(although his question has nothing to do with clc). You can
lurk for a long time in clc++, and not know who Richard
Heathfield is. (Another reason why cross-posting is bad.)

 

[Clark Cox]

No, a pointer to a float is the same as an array of float.

#include <stdio.h>
int main(void)
{
float array[10] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
float *pointer = array;

printf("%lu %lu\n", sizeof array, sizeof pointer);
return 0;
}

Displays "40 4" on my system. So? They're the same but one is ten times
bigger?

So there's a bug in the standard that breaks array pointer equivalence?

It's not a bug, it's that way by design. Pointers and arrays have never
been equivalent.

It happens to even the best languages.
Deprectate sizeof( object) and only allow sizeof(type) and the pro

Not only would that break perfectly valid code, it wouldn't change
anything; arrays would still not be pointers:

#include <stdio.h>
int main(void)
{
printf("%lu %lu\n", (unsigned long)sizeof(float[10]), (unsigned
long)sizeof(float*));
return 0;
}

[OT in clc]
And, in C++, since you can take references to arrays, the situations in
which they are not equivalent to pointers are even greater in number.
[/OT]

 

[James Kanze]

Kind of. It very helpful to know C if youa re trying to
understand why C++ is the way it is.

If you're interested in the history, yes. As they currently
stand, C and C++ are two very different languages, with very
different idioms.

C structs lay out variables contiguously in memory.

Except when it doesn't. Both C and C++ allow padding. (C++, of
course, allows rearrangement as well, in certain cases.)

C++ classes extend that
idea to tie functions to the data types they operate on then, and this is
the clever part, express relationships between different functions and data
types.

C++ classes do a lot more than that (although that is an
important part). In particular, C++ classes have constructors
and a destructor, a concept completely foreign to C.

 

[James Kanze]

No, a pointer to a float is the same as an array of float.

#include <stdio.h>
int main(void)
{
float array[10] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
float *pointer = array;
printf("%lu %lu\n", sizeof array, sizeof pointer);
return 0;
}
Displays "40 4" on my system. So? They're the same but one is ten times
bigger?

So there's a bug in the standard that breaks array pointer equivalence?

There is no array pointer equivalence in C++. There wasn't in
C, either, back when I was programming in C (in the 1980's), and
I'd be very surprised if they'd added one since.

It
happens to even the best languages.
Deprectate sizeof( object) and only allow sizeof(type) and the pro

I don't think that sizeof( float[10] ) will be equal to sizeof(
float* ), either.

Arrays and pointers in C++ work exactly as they did in C90.
Unless C99 radically changed this in the language (which would
really surprise me), arrays and pointers are two different
things, just as they are in C++.

And array will convert to a pointer in certain circumstances.
But then, a double will also convert to an int in certain
circumstances. An array is no more a pointer, however, than a
double is an int.

 

[Flash Gordon]

Malcolm McLean wrote, On 03/06/07 21:33:

No, a pointer to a float is the same as an array of float.

#include <stdio.h>
int main(void)
{
float array[10] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
float *pointer = array;

printf("%lu %lu\n", sizeof array, sizeof pointer);
return 0;
}

Displays "40 4" on my system. So? They're the same but one is ten
times bigger?

So there's a bug in the standard that breaks array pointer equivalence?

This is not a bug in the standard, just one example of pointers and
arrays being fundamentally different things.

It happens to even the best languages.
Deprectate sizeof( object) and only allow sizeof(type) and the pro

So you want to deprecate something which makes it easier to program
correctly because you don't like the way the language works. If you
don't like C or C++ find another language.

 

[BobR]

Malcolm McLean wrote in message...
[snip]

We hate C++ here because it is runing our nice language.

"runing"? <G> LMAO.

[snip]

I know C++ is bad, but surely not.

You do know that this is cross-posted to 'comp.lang.c++', don't you?
That makes your post a 'troll'!! You trying to start a flame-war? <G>

 

[Mark McIntyre]

So, you think a poster should search up the name of everyone he replies
too? I don't think so somehow.

Here's the situation: a self-confessed novice posts a question.
Someone answers him, but he's confused by the answer. Does he say to
himself

a) hmm,I'm a novice, I have no clue, I'll reread those posts and see
what I missed.
or
b) hmm, I know have no clue but I'll still write a correction, cos I
don't like admitting I'm lost.

I would point out that while he was wrong, the OP was neither rude nor
disrespectful. A polite correction is far more valid than a lecturing on
how great one might think Richard Heathfield or another regular is.

Imagine someone asked a question about relativity, and Albert Einstein
answered. Imagine if the questioner then started to correct Einstein's
answer based on his own (possibly incorrect) understanding. Wouldn't
that be hilarious?
--
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

 

[Richard Heathfield]

Keith Thompson said:

It should be obvious by now that you're *not* going to get any useful
responses from comp.lang.c.

He's had plenty of useful responses from comp.lang.c - not our fault if
he can't recognise them as such.

I don't know what you expect to accomplish by continuing to post here.

He might learn more about C. He'll certainly learn more about
comp.lang.c.

<snip>

 

[Default User]

You have been advised repeatedly, and in many cases quite politely,
that your question is about C++, not about C, and that you should post
it in comp.lang.c++, not in comp.lang.c. And yet you persist in
posting to comp.lang.c.

Why do people keep responding to this idiot? It's pretty obvious he's
trolling at this point, whether or not he was merely clueless in the
beginning.

Killfile or ignore and move on.




Brian

 

[Richard Heathfield]

James Kanze said:

It depends. The original poster apparently cross-posted

No, he didn't. He posted to clc. I tried to move the whole thing over to
clc++ by crossposting it there and setting followups, but someone
removed my followup suggestion.

You can lurk for a long time in clc++, and not know who Richard
Heathfield is.

Strange but true.

 

[Lame Duck]

Somehow I doubt that - my instructor was a C++ expert who'd programmed
for more than one very big company.

 

[Lame Duck]

You have been advised repeatedly, and in many cases quite politely,
that your question is about C++, not about C, and that you should post
it in comp.lang.c++, not in comp.lang.c. And yet you persist in
posting to comp.lang.c.

No I'm posting this now in comp.lang.c++.

You are being rude. It's not surprising that some people here in
comp.lang.c are rude to you in response. There *may* have been some
overreaction; I suggest you ignore it and move on.

It should be obvious by now that you're *not* going to get any useful
responses from comp.lang.c. I don't know what you expect to
accomplish by continuing to post here.

[...]

I really don't understand what this code is doing! I think you
misunderstood my question - &MyVector.front() already works, the problem
is to convert pointer/array to vector without having to copy all data by
hand.

Don't worry about understanding the code; the author was being
sarcastic. He was *pretending* that your question is a valid question
about C (it must have been, since you posted it to comp.lang.c).
Since C doesn't have "vectors", he invented a set of C declarations
for which "&MyVector.front()" would be valid C. The fact that the
resulting code doesn't address your problem is a result of your
posting your question to the wrong newsgroup. (He sprinkled the code
with C++ keywords used as identifiers, guaranteeing that it's not
valid C++, just to emphasize the point.)

Well it only served to confuse not enlighten, let me assure you.

Incidentally, I can't tell who wrote the code because you deleted the
attribution lines. Please don't do that.

Your real question, I think, is how to copy the contents of an array
into a C++ vector without copying each element individually. (I don't
know the answer to that, since I'm not sufficiently familiar with C++.
It may well be that the best solution is to copy the elements one at a
time in a loop. Or perhaps std::vector provides an operation to do
what you want in one fell swoop, though such an operation probably
works internally by looping over the elements.) You should ask *that*
question, and you should ask it in comp.lang.c++, where it's perfectly
topical. You'll probably get numerous excellent and well-informed
answers. You might even get some good advice on how to re-structure
your code so the operation you're looking for isn't needed in the
first place.

I've asked that in this thread, but got no answer except the one you
suggested of copying every element manually. The whole point was to try
to avoid having to do that!

 

[Ben Pfaff]

No I'm posting this now in comp.lang.c++.

....and to comp.lang.c too. That's really not necessary.

 

[Ian Collins]

Lame Duck wrote:

Don't top-post.

Somehow I doubt that - my instructor was a C++ expert who'd programmed
for more than one very big company.

He was still wrong.

 

[Ian Collins]

No I'm posting this now in comp.lang.c++.

Then why did you cross-post? This time, observe the follow-up.

 

[Richard Heathfield]

[Top-posting fixed]

Lame Duck said:

Somehow I doubt that - my instructor was a C++ expert who'd programmed
for more than one very big company.

Nevertheless, either he was mistaken or you misunderstood him. No matter
what his expertise, the language specification always trumps an
instructor.