error: cannot convert 'std::string' to 'std::string*' in assignment??

Printable View

06-01-2010
Programmer_P

error: cannot convert 'std::string' to 'std::string*' in assignment??

This is weird...
My compiler just gave me the following message:

Quote:

error: cannot convert 'std::string' to 'std::string*' in assignment

in regards to this code:

Code:

string* CenumOperations::getEnum() { string* pEnumStrings = enumStrings; //get a pointer to the string member 'enumStrings' return pEnumStrings; //return the pointer }

The error is at the line where I create a string pointer and initialize it to point at the 'enumStrings' member string of the class "CenumOperations" in the same line.

And if, I change it to this instead:

Code:

string* CenumOperations::getEnum() { string* pEnumStrings = NULL; pEnumStrings = enumStrings; //get a pointer to the string member 'enumStrings' return pEnumStrings; //return the pointer }

there's no change. Still the same error.
06-01-2010
jeffcobb

try string *pEnumStrings = &enumStrings;
06-01-2010
Programmer_P

Quote:

Originally Posted by jeffcobb

try string *pEnumStrings = &enumStrings;

Oh, duh...I cannot believe I forgot that. :rolleyes:
I guess I got so used to pointing pointers at pointers (or more accurately, pointing pointers at the addresses contained in other pointers) where using the '&' operator is not necessary, that I didn't think to use it for a string instance. Stupid me...

Thanks.
06-01-2010
cpjust

Maybe returning a reference to a string would be better? I always prefer references over pointers whenever possible.
06-01-2010
Programmer_P

Quote:

Originally Posted by cpjust

Maybe returning a reference to a string would be better? I always prefer references over pointers whenever possible.

Yeah, I suppose so.
According to this document, the only advantage that pointers have over references is that they can be incremented to the next location in memory, while references can't. References appear to be safer and also easier to use, because you don't have to use the dereferencing * operator.
06-01-2010
jeffcobb

Don't feel bad Programmer_ninja; you try more than many how come here for advice. Because you try you will get more help than most too :)
06-02-2010
iMalc

Pointers can also be NULL, which makes them useful for optional parameters, they are also better suited for functions exposed through a DLL interface because that makes them useable through other languages.
But yes, certainly if the value is never meant to be optional or externally exposed, then using a reference is best.
06-02-2010
Elysia

Also, pointers can be reassigned; references cannot. Another important fact between them.
06-02-2010
Sebastiani

Quote:

Originally Posted by Elysia

Also, pointers can be reassigned; references cannot. Another important fact between them.

Sure they can...

Code:

template < typename Type > struct reference { reference( Type& data ) : data( data ) { } Type& data; }; int main( void ) { int i = 1024, j = i + 1; reference< int > r( i ); cout << r.data << endl; new( &r ) reference< int >( j ); cout << r.data << endl; }

...it just ain't kosher. :p
06-02-2010
Elysia

I could think of better ways to do that. But regardless, that isn't a reference. It's a class that emulates a reference.
06-02-2010
Sebastiani

Quote:

I could think of better ways to do that.

Such as..?

Quote:

But regardless, that isn't a reference. It's a class that emulates a reference.

Or rather, a class that *contains* a reference. At any rate, the code I posted does, in fact, "reassign a reference", so you are still wrong.
06-02-2010
Elysia

Quote:

Originally Posted by Sebastiani

Such as..?

I was thinking of a "reassign" member function, instead of having to use placement new.

Quote:

Or rather, a class that *contains* a reference. At any rate, the code I posted does, in fact, "reassign a reference", so you are still wrong.

No, it doesn't. What it does is create a new struct and initializes that reference. So while you could say it reassigns it, technically it does not.
06-02-2010
iMalc

Quote:

Originally Posted by Sebastiani

Or rather, a class that *contains* a reference. At any rate, the code I posted does, in fact, "reassign a reference", so you are still wrong.

If you start posting non-kosher code examples like that, I think you're obliged to pay attention to the distinction between "reassigning a reference" and "unscroupulously causing the underlying memory occupied by a reference to change".

No code example like that is going to negate the fact that references cant be reassigned.
06-02-2010
Sebastiani

Quote:

No, it doesn't. What it does is create a new struct and initializes that reference. So while you could say it reassigns it, technically it does not.

Sorry, but that's incorrect - the code just invokes the constructor on an existing object, so the reference member 'data' does indeed get reassigned.

Gawd, I love it when you're wrong, Elysia - you'll go to almost any length to avoid admitting it! :D
06-02-2010
Elysia

And what does the constructor do? Hint: it constructs a new object.
06-02-2010
laserlight

Well, if Programmer_P ever uses Sebastiani's idea, then comes round asking why there was a mismatch in the number of constructor and destructor invocations, then Sebastiani better be at hand to give a good answer, or we get to roast him over a slow burning fire :D

Quote:

Originally Posted by Sebastiani

Sorry, but that's incorrect - the code just invokes the constructor on an existing object, so the reference member 'data' does indeed get reassigned.

No, it does not. We're dealing with a new object. What happens is that the constructor is invoked to create a new object, which is then placed in memory in the same location as an existing object.
06-02-2010
Sebastiani

Quote:

Originally Posted by iMalc

If you start posting non-kosher code examples like that, I think you're obliged to pay attention to the distinction between "reassigning a reference" and "unscroupulously causing the underlying memory occupied by a reference to change".

No code example like that is going to negate the fact that references cant be reassigned.

Hey - I was just pointing out that it is possible! And the distinction you make is understandable, if pedantic - my example was 100% portable C++, with clearly defined behaviour, and the reference in question is *effectively* reassigned. It ain't pretty, and it may very well raise eyebrows in a code review, but it nonetheless works just fine.
06-02-2010
laserlight

Quote:

Originally Posted by Sebastiani

Hey - I was just pointing out that it is possible! And the distinction you make is understandable, if pedantic - my example was 100% portable C++, with clearly defined behaviour, and the reference in question is *effectively* reassigned.

I am not sure about that:

Quote:

Originally Posted by C++03 Section 8.5.3 Paragraph 2

A reference cannot be changed to refer to another object after initialization.

Quote:

Originally Posted by Sebastiani

It ain't pretty, and it may very well raise eyebrows in a code review, but it nonetheless works just fine.

Even if we accept that it is "100% portable C++, with clearly defined behaviour", the program must be incorrect: it cannot possibly be correct that there are two constructor invocations but only one destructor invocation. I would completely slam it in a code review, on the grounds of correctness.

EDIT:
I suppose you could correct the code by explicitly invoking the destructor on r before placement new, but then you would need very calm colleagues for them to merely "raise eyebrows in a code review".
06-02-2010
Sebastiani

Quote:

Well, if Programmer_P ever uses Sebastiani's idea, then comes round asking why there was a mismatch in the number of constructor and destructor invocations, then Sebastiani better be at hand to give a good answer, or we get to roast him over a slow burning fire :D

Fair enough, but let's face it - given his track record, the chances that he actually follows any advice here is pretty slim. :D

Quote:

No, it does not. We're dealing with a new object. What happens is that the constructor is invoked to create a new object, which is then placed in memory in the same location as an existing object.

Actually, the constructor is invoked on the existing object, just as if it had been declared at the point of the "placement new" call.

Code:

template < typename Type > struct reference { reference( Type& data ) : data( data ) { cout << "Construct: " << static_cast< void* >( this ) << endl; } Type& data; }; int main( void ) { int i = 1024, j = i + 1; reference< int > r( i ); cout << r.data << endl; new( &r ) reference< int >( j ); cout << r.data << endl; }

Output:

Quote:

Construct: 0x28ff10
1024
Construct: 0x28ff10
1025

Two constructor calls, one address.
06-02-2010
laserlight

Quote:

Originally Posted by Sebastiani

Actually, the constructor is invoked on the existing object, just as if it had been declared at the point of the "placement new" call.

That does not make sense. You cannot construct an object twice.

Quote:

Originally Posted by Sebastiani

Two constructor calls, one address.

That confirms the statement that the new object is placed in the same location as the existing object. In fact, this should be well known to you, since it is an intended effect of placement new.
06-02-2010
Programmer_P

Quote:

Originally Posted by Sebastiani

Fair enough, but let's face it - given his track record, the chances that he actually follows any advice here is pretty slim. :D

And yet I'm playing with your code right now... :p
06-02-2010
Sebastiani

Quote:

I am not sure about that: A reference cannot be changed to refer to another object after initialization.

As a syntactic feature, yes, insomuch as you can't reassign a "raw" reference. But the rules governing the behaviour of "placement new" guarantee that it can be done "in practice", on structures that contain references.

Quote:

Even if we accept that it is "100% portable C++, with clearly defined behaviour", the program must be incorrect: it cannot possibly be correct that there are two constructor invocations but only one destructor invocation. I would completely slam it in a code review, on the grounds of correctness.

Well, in this case the destructor invocation is superfulous, but yes, matching the calls is, of course, the correct way to do it.

I should probably reiterate at this point that I am not advocating this sort of practice - I just have this odd fascination with "bending the rules" of the language. It's a hobby, I guess. :p
06-02-2010
laserlight

Quote:

Originally Posted by Sebastiani

BAs a syntactic feature, yes, insomuch as you can't reassign a "raw" reference. But the rules governing the behaviour of "placement new" guarantee that it can be done "in practice", on structures that contain references.

Then we simply disagree. In my opinion, you are not doing such a thing in practice. You are merely deceiving yourself by not recognising that the reference member belongs to another object that is placed into the same location as the existing object (EDIT: or perhaps, into the location of an explicitly destroyed object).
06-02-2010
syzygy

I enjoyed the debate. I would still say you cannot reassign a reference, but I think it's more an argument of semantics at this point. It seems that, effectively, it is possible.
06-02-2010
Programmer_P

Quote:

Originally Posted by laserlight

Then we simply disagree. In my opinion, you are not doing such a thing in practice. You are merely deceiving yourself by not recognising that the reference member belongs to another object that is placed into the same location as the existing object.

Yes, I would say laserlight is right.
You're not actually reassigning the reference to the first object to the second object, per se. You're only getting a new reference (though using the same name) to a new object at the same memory address as that held by the former object.

The difference though is after reassigning a pointer, you're pointing at a different memory address altogether, while with the reference using your method, you're using the same memory address, only a different object.
06-02-2010
Sebastiani

Quote:

That does not make sense. You cannot construct an object twice.

Sure you can. A constructor is nothing more than a function call, after all.

Quote:

That confirms the statement that the new object is placed in the same location as the existing object. In fact, this should be well known to you, since it is an intended effect of placement new.

There is no "new object". The compiler generates the same code as it did when the object was declared, eg: a pointer to the *original* object is passed to the class constructor. Consider:

Code:

int main( void ) { int i = 1024, j = i + 1; unsigned char b[ sizeof( reference< int > ) ]; reference< int >& r( *( reference< int >* )b ); new( &r ) reference< int >( i ); cout << r.data << endl; new( &r ) reference< int >( j ); cout << r.data << endl; }

Output:

Quote:

Construct: 0x28ff10
1024
Construct: 0x28ff10
1025
06-02-2010
laserlight

Quote:

Originally Posted by Sebastiani

Sure you can. A constructor is nothing more than a function call, after all.

You might want to read GotW #66 to learn about object lifetimes.

Quote:

Originally Posted by Sebastiani

There is no "new object". The compiler generates the same code as it did when the object was declared, eg: a pointer to the *original* object is passed to the class constructor.

It sounds like you are thinking from the perspective of C rather than C++, but C does not have constructors. A constructor is used to create a new object, by definition. Hence, it is fundamentally impossible to create the same object twice, even though a constructor call is otherwise just a function call.
06-02-2010
Sebastiani

Quote:

You might want to read GotW #66 to learn about object lifetimes.
[...]
It sounds like you are thinking from the perspective of C rather than C++, but C does not have constructors. A constructor is used to create a new object, by definition. Hence, it is fundamentally impossible to create the same object twice, even though a constructor call is otherwise just a function call.

...and for that, I award you the Pedantic Argument of the Day. :p

Okay, in terms of "object lifetimes", this is indeed true. Nonetheless, the code generated by the compiler is *precisely* the same whether it is dealing with a "standard" constructor invocation or a "manual" one (eg: "placement new"). Moreover, to "create" an object, the compiler simply (1) sets aside enough memory for the object, and then (2) passes a pointer to the object to the class constructor. When you invoke "placement new" on the object, you are just repeating step #2. So, more accurately, "A constructor is used to initialize a (typically, but not necessarily) new object".
06-02-2010
laserlight

Quote:

Originally Posted by Sebastiani

I award you the Pedantic Argument of the Day.

Thank you, thank you. I shall forgo the acceptance speech :D

Quote:

Originally Posted by Sebastiani

Moreover, to "create" an object, the compiler simply (1) sets aside enough memory for the object, and then (2) passes a pointer to the object to the class constructor. When you invoke "placement new" on the object, you are just repeating step #2.

To justify my pedantic argument award: the pointer at that point points to the memory set aside, since the object does not yet exist, and in typical usage of placement new, step #2 is done once rather than repeated (unless the memory is merely reused incidentally).

Quote:

Originally Posted by Sebastiani

So, more accurately, "A constructor is used to initialize a (typically, but not necessarily) new object".

That implies that a constructor can initialize an existing object. Yes, not assignment to an existing object, but initialisation. Maybe it makes sense to you, but it definitely makes no sense to me. It is like turning the semantics upside down.
06-02-2010
Sebastiani

Quote:

Originally Posted by laserlight

Thank you, thank you. I shall forgo the acceptance speech :D

To justify my pedantic argument award: the pointer at that point points to the memory set aside, since the object does not yet exist, and in typical usage of placement new, step #2 is done once rather than repeated (unless the memory is merely reused incidentally).

That implies that a constructor can initialize an existing object. Yes, not assignment to an existing object, but initialisation. Maybe it makes sense to you, but it definitely makes no sense to me. It is like turning the semantics upside down.

Okay, fair enough. And for the record, your arguments, pedantic or otherwise, are usually spot on, and so I encouraged you to display your award prominently - right next to all of those "Best Damn Advice of the Day" awards you've racked up. :)
06-02-2010
phantomotap

Is anyone else reminded of the insane and crappy code Sebastiani posted to "bend the rules" to allow a "null reference" and the resulting arguments?

Soma
06-02-2010
Sebastiani

Quote:

Originally Posted by phantomotap

Is anyone else reminded of the insane and crappy code Sebastiani posted to "bend the rules" to allow a "null reference" and the resulting arguments?

Soma

Are you kidding? That was a gem! It doesn't hurt to think outside of the box, you know...
06-02-2010
phantomotap

Like I said then, if you are going to break the rules, break the $*&# out of them. If you are going to pretend to reassign a reference, why not go all the way?

[Edit]
I read your post pre-edit. You didn't need to change it. I assumed you were poking at me much the same as I was poking at you.
[/Edit]

[Edit]
AND WHY DOES CBOARD INSIST ON EATING MY EDITS!?
[/Edit]

Soma
06-02-2010
Sebastiani

Quote:

Originally Posted by phantomotap

Like I said then, if you are going to break the rules, break the $*&# out of them. If you are going to pretend to reassign a reference, why not go all the way?

Soma

FYI, using a tool in an unorthodox way does not equate to using it incorrectly.

Anyway, I'm not suprised by your response, really. You were, after all, the one who so brilliantly suggested that we allow the MiniBasic virtual machine to segfault on a malformed program! Apparently, designing robust software is much less important to you than writing "orthodox" code. How droll.
06-02-2010
phantomotap

Quote:

FYI, using a tool in an unorthodox way does not equate to using it incorrectly.

LMAO!

You are talking to a master jury rigger. I practically have a PhD in "unintended purposes". I also never implied you were doing anything incorrectly.

Quote:

You were, after all, the one who so brilliantly suggested that we allow the MiniBasic virtual machine to segfault on a malformed program!

This I have a problem with. I never said anything of the sort. The compiler should catch a malformed program before the virtual machine has a chance to process it.

I suggested that the virtual machine behave realistically. I said that if a programmer misused my imagining of the `PUSH'/`PEEK' implementation to trample over the instruction area they should face the consequences. I stand by this.

Soma
06-02-2010
VirtualAce

You guys make my head hurt. :)

I prefer using references when it comes to std::string. In fact if I ever see std::string * it usually throws up a red flag in my book. That is not to say it isn't valid it is just something I'm not all that used to seeing.
06-02-2010
StainedBlue

Quote:

Originally Posted by Bubba

You guys make my head hurt. :)

I prefer using references when it comes to std::string. In fact if I ever see std::string * it usually throws up a red flag in my book. That is not to say it isn't valid it is just something I'm not all that used to seeing.

If Programmer_P get his way, that will surely change!

all in good fun
06-03-2010
Elysia

Quote:

Originally Posted by Sebastiani

Gawd, I love it when you're wrong, Elysia - you'll go to almost any length to avoid admitting it! :D

Who was right, and who was wrong? Eh? Eh???! :p :p :p
On a side note, it is always interesting when you try to break the language. I love it. But you shouldn't go about calling it or naming it to something that it isn't. Pedantic views are always the best. I think.
06-03-2010
Programmer_P

Quote:

Originally Posted by StainedBlue

If Programmer_P get his way, that will surely change!

all in good fun

You guys crack me up... :D
I couldn't stop laughing after reading some of the posts in this thread.
06-03-2010
Sebastiani

Quote:

Originally Posted by Elysia

Who was right, and who was wrong? Eh? Eh???! :p :p :p

Oh, fine! You were right, Elysia. :rolleyes:

<villainous voice>: "I would have gotten away with it, too, if it weren't for you meddling pedanticists!!!" :D
06-03-2010
Elysia

Quote:

Originally Posted by Sebastiani

<villainous voice>: "I would have gotten away with it, too, if it weren't for you meddling pedanticists!!!" :D

Ah, but you should know by now that this board is full of us pedanticists who specializes in knowing the ins and outs of the language, down to the very definitions in the standardese text! ;)

All times are GMT -6. The time now is 10:56 AM.