Sign in to follow this  
Kiput

Passing string( "foo" ) to string&.

Recommended Posts

Hi. Consider following code:
#include <string>
#include <cstdio>

using namespace std;

void foontf( string& str )
{
    printf( str.c_str( ) );
}

int main( )
{
    foontf( string( "foo\n" ) );

    return 0;
}
Compiles fine (and works) on MSVC7, but not on g++ (gcc 3.3.1).
c:\Cplusplus\foo>g++ foo.cpp
foo.cpp: In function `int main()':
foo.cpp:13: error: could not convert `string("foo\n", (&allocator<char>()))' to

   `std::string&'
foo.cpp:7: error: in passing argument 1 of `void foontf(std::string&)'
What's wrong with that code? Is one of the STL implementations buggy? Thanks.

Share this post


Link to post
Share on other sites
Consider the following code:

void foontf( string* str )
{
printf( str->c_str( ) );
}

int main( )
{
foontf( &(string("foo\n")) );
return 0;
}



It's <<basically>> the same as the one you posted.
Referencing a temporary value is not something you should normally do.

gcc is known to be much more strict than Visual. Thant's why it declined your request for implicit cast:
string -> string&.

( I'm right, am I? )

Share this post


Link to post
Share on other sites
Quote:
Original post by deffer
Consider the following code:
*** Source Snippet Removed ***
( I'm right, am I? )


Well, right in that it looks like that should compile.

Referencing a temporary variable with a reference is just as safe as referecing a temporary variable with a pointer, however. The temporary isn't destroyed until the statement completes, by which point your function is no longer being called and your references, via reference or pointer, are gone. You may be thinking of returning LOCAL variables by reference, which is bad, because the local variable will be destroyed when the function ends - as you're returning - leaving you having returned a reference to an allready destroyed object.

Dranith hit the nail on the head when he said the function should take a const reference, and I'd agree with you on compiler strictness (GCC vs VS) although I don't really know this for a fact myself :-).

Share this post


Link to post
Share on other sites
Quote:
Original post by chad_420
I wouldn't say gcc is stricter...


It's not about what it implements, it's about following the standards blindly.
Example?

I had some code full of templates with internal typedefs written in MSVC. As sometimes it is required to use "typename" keyword, and I didn't knew exactly when or why (I do now), I ended up typing it everywhere, like:
typedef typename TemplatedClass<TParam> CClassName;

When I was porting it to gcc, I found out I'm only allowed to use the keyword where it <has to> be used. And that was not helpful at all.
Anyway, in the end I just had to learn whens and whys of typename, which turned out for the best for me.

So I'm not saying MSVC does better job, it just does better semantics ;)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this