Is the book <<Thinking in C++>> Wrong?
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 1 of 2 12 LastLast
Results 1 to 15 of 28

Thread: Is the book <<Thinking in C++>> Wrong?

  1. #1
    Join Date
    Sep 2006
    Posts
    141

    Is the book <<Thinking in C++>> Wrong?

    An example in the book Thinking in C++:

    Code:
    class X{};
    
    X f() {
    	return X();
    }
    
    void g1(X&){}
    void g2(const X&){}
    
    
    int main(){
    
    	g1(f());
    	return 0;
    }
    According to the book the compiler should report error because f() returns a temporary object which is defined by the compiler as "const".
    However I compile this code using VS 2005 it works. Is the book wrong?

    Thanks!

  2. #2
    Join Date
    Oct 2002
    Location
    Austria
    Posts
    1,284

    Re: Is the book <<Thinking in C++>> Wrong?

    Looks like ms compiler is wrong
    My output
    Code:
    gfx.cc: In function 'int main()':
    gfx.cc:13: error: invalid initialization of non-const reference of type 'X&' from a temporary of type 'X'
    gfx.cc:7: error: in passing argument 1 of 'void g1(X&)'
    Kurt

  3. #3
    Join Date
    Dec 2005
    Posts
    642

    Arrow Re: Is the book <<Thinking in C++>> Wrong?

    See this recent thread.

  4. #4
    Join Date
    Aug 2005
    Location
    San Diego, CA
    Posts
    1,054

    Question Re: Is the book <<Thinking in C++>> Wrong?

    googler, are you suggesting that the default copy constructor is being called to create a new object that the reference can be assigned to? The thread was kinda going in many different directions so it was rather hard to follow. Was it ever established that this is how a compiler SHOULD work?

    regards,

    Shawn

  5. #5
    Join Date
    Jan 2006
    Location
    Singapore
    Posts
    6,719

    Re: Is the book <<Thinking in C++>> Wrong?

    Just answered a similiar question on a different messageboard...

    Thinking in C++ is right, this behaviour is a non-standard extension in VS2005. When you set the warning level to /W4, you will get:
    Code:
    warning C4239: nonstandard extension used : 'argument' : conversion from 'X' to 'X &'
    A non-const reference may only be bound to an lvalue
    C + C++ Compiler: MinGW port of GCC
    Build + Version Control System: SCons + Bazaar

    Look up a C/C++ Reference and learn How To Ask Questions The Smart Way
    Kindly rate my posts if you found them useful

  6. #6
    Join Date
    Feb 2005
    Location
    Normandy in France
    Posts
    4,590

    Re: Is the book <<Thinking in C++>> Wrong?

    Anyway, Thinking in C++ is wrong if it says that returned values are const. They're rvalues, but not const unless explicitly qualified.
    "inherit to be reused by code that uses the base class, not to reuse base class code", Sutter and Alexandrescu, C++ Coding Standards.
    Club of lovers of the C++ typecasts cute syntax: Only recorded member.

    Out of memory happens! Handle it properly!
    Say no to g_new()!

  7. #7
    Join Date
    Jun 2007
    Location
    ShangHai China
    Posts
    24

    Re: Is the book <<Thinking in C++>> Wrong?

    You'd better check the assembly generated by your VS2005 for the code "g1(f());"
    ,maybe no assembly code generated here since function g1() is empty .

  8. #8
    Join Date
    Feb 2005
    Location
    "The Capital"
    Posts
    5,306

    Re: Is the book <<Thinking in C++>> Wrong?

    Quote Originally Posted by LddLinan
    You'd better check the assembly generated by your VS2005 for the code "g1(f());"
    ,maybe no assembly code generated here since function g1() is empty .
    The code needs to be semantically correct! Doesn't matter if there is any code generated or not.

  9. #9
    Join Date
    Feb 2005
    Location
    Normandy in France
    Posts
    4,590

    Re: Is the book <<Thinking in C++>> Wrong?

    I think that this is a documented extension, and it will create a temporary variable holding the value (not necessarily physically if the code can be optimized out), and destroyed at the end of the current full expression, as for rvalues bound to const references, with the difference that the temporary will be non-const, and thus modifiable without invoking undefined behavior.
    "inherit to be reused by code that uses the base class, not to reuse base class code", Sutter and Alexandrescu, C++ Coding Standards.
    Club of lovers of the C++ typecasts cute syntax: Only recorded member.

    Out of memory happens! Handle it properly!
    Say no to g_new()!

  10. #10
    Join Date
    Jun 2007
    Location
    ShangHai China
    Posts
    24

    Re: Is the book <<Thinking in C++>> Wrong?

    Quote Originally Posted by exterminator
    The code needs to be semantically correct! Doesn't matter if there is any code generated or not.
    There got to be some order in semantic or syntax evaluation.

    The example code below is way out of the clue, since macro is always evaluated before sematic check, but you can get my point. Standard doesn't say which code is doomed to be compiled.
    Code:
    #define NULLFunc(x)
    ...
    NULLFunc(0=0);
    Maybe VS2005 just treat g1(f()); as f() in the middle of compilation since g1() is empty function.
    God I wish I had a VS2005 at hand...
    Last edited by LddLinan; June 26th, 2007 at 02:57 AM.

  11. #11
    Join Date
    Feb 2005
    Location
    "The Capital"
    Posts
    5,306

    Re: Is the book <<Thinking in C++>> Wrong?

    Quote Originally Posted by LddLinan
    There got to be some order in semantic or syntax evaluation.

    Standard doesn't say which code is doomed to be compiled.
    There are various things that the compiler does. Checking the code for syntax is one of the first phases. It has to be passed. The standard does not mandate over the compiling process but the compiler cannot ignore something uncompilable seeing that it does nothing. Just because copy construction can be optimized out by the compiler doesn't mean that a non-compilable copy constructor containing code will successfully compile. And surely the standard lays down the syntax rules. It states specifications for correct compilable code as well as constructs that are ill-formed. The case of this thread falls under a direct spec of the standards and hence should not compile. It still compiles because, as SuperKoko said, its a non-standard VS2005 extension. To confirm, you can compile the code with the extensions turned off and see what happens (if still compiles - try increasing the warning level).

  12. #12
    Join Date
    Jun 2007
    Location
    ShangHai China
    Posts
    24

    Re: Is the book <<Thinking in C++>> Wrong?

    If you are right, there must be very good reasons for MS to do this so-called extension, is there any guru could give me some clue?

  13. #13
    Join Date
    Feb 2005
    Location
    Normandy in France
    Posts
    4,590

    Re: Is the book <<Thinking in C++>> Wrong?

    Quote Originally Posted by exterminator
    The case of this thread falls under a direct spec of the standards and hence should not compile.
    Maybe it should not compile, but the standard permits the implementation to successfully compile the program provided that a diagnostic message is output, i.e. a warning message.
    If the diagnostic message is not fatal, the behavior of the produced program is undefined but may be reliable if the implementation documents it.
    Quote Originally Posted by exterminator
    It still compiles because, as SuperKoko said, its a non-standard VS2005 extension.
    It's non-standard because it's not specified by the standard, but that doesn't make VS2005 automatically non conforming. Non-standard extensions are allowed in conforming implementations.
    "inherit to be reused by code that uses the base class, not to reuse base class code", Sutter and Alexandrescu, C++ Coding Standards.
    Club of lovers of the C++ typecasts cute syntax: Only recorded member.

    Out of memory happens! Handle it properly!
    Say no to g_new()!

  14. #14
    Join Date
    Feb 2005
    Location
    "The Capital"
    Posts
    5,306

    Re: Is the book <<Thinking in C++>> Wrong?

    Quote Originally Posted by LddLinan
    If you are right, there must be very good reasons for MS to do this so-called extension, is there any guru could give me some clue?
    It could be an unfixed bug (probably fixed now - see below) - http://forums.microsoft.com/MSDN/Sho...20081&SiteID=1

    Some mechanism like NRVO could make this work with VS2005 but this surely isn't reliable (well could be for that compiler, could be a bug as well) but surely is non-portable C++ code. Move to a different compiler and the compilation stops. You should avoid doing that as I don't see any good reason to use it.
    Quote Originally Posted by SuperKoko
    Maybe it should not compile, but the standard permits the implementation to successfully compile the program provided that a diagnostic message is output, i.e. a warning message. If the diagnostic message is not fatal, the behavior of the produced program is undefined but may be reliable if the implementation documents it.
    In fact, I could not find any documentation on this extension but finally could search this out which suggests the bug has been fixed - http://msdn2.microsoft.com/en-us/lib...dc(vs.80).aspx

    Might need a patch upgrade?
    Last edited by exterminator; June 26th, 2007 at 06:48 AM.

  15. #15
    Join Date
    Dec 2005
    Posts
    642

    Arrow Re: Is the book <<Thinking in C++>> Wrong?

    Quote Originally Posted by SuperKoko
    Maybe it should not compile, but the standard permits the implementation to successfully compile the program provided that a diagnostic message is output, i.e. a warning message.
    If the diagnostic message is not fatal, the behavior of the produced program is undefined but may be reliable if the implementation documents it.
    Where exactly in the C++ standard do you see the words "warning" or a distinction made between fatal and non-fatal diagnostics?
    As far as I can tell, the only distinction is between errors that the compiler can or cannot catch at compile time.
    For instance, dereferencing a null pointer is not an error that the compiler can reliably catch at compile time, so it's underfined behavior and no diagnostic is required.
    Some errors that the compiler can catch at compile time are specifically excluded by explicitly saying "no diagnostic is required".
    Would you consider a compiler that allows the programmer to omit semi-colons at the end of statements a compliant compiler? According to you, the compiler can simply issue warnings but compile the program anyway.
    Binding an rvalue to a non-const reference is an error that can be reliably caught at compile time, since it's based on the static types of the objects involved. I don't agree that a compiler that permits this or just issues a warning is a compliant compiler.
    As an example of legitimate use of warnings - implicit narrowing conversions (i.e. converting long to short), signed vs unsigned comparisons. These are all things that are not an error at all in the standard. Compilers may issue warnings about them because they may lead to bugs, that's all.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This a Codeguru.com survey!


On-Demand Webinars (sponsored)