Search Results

Search found 5 results on 1 pages for 'rimo'.

Page 1/1 | 1 

• const return value and template instantiation

  - by Rimo

  From Herb Sutter's GotW #6 Return-by-value should normally be const for non-builtin return types. .... Note: Lakos (pg. 618) argues against returning const value, and notes that it is redundant for builtins anyway (for example, returning "const int"), which he notes may interfere with template instantiation. .... While Sutter seems to disagree on whether to return a const value or non-const value when returning an object of a non-built type by value with Lakos, he generally agrees that returning a const value of a built-in type (e.g const int) is not a good idea. While I understand why that is useless because the return value cannot be modified as it is an rvalue, I cannot find an example of how that might interfere with template instantiation. Please give me an example of how having a const qualifier for a return type might interfere with template instantiation.

  Read the article

• When does a const return type interfere with template instantiation?

  - by Rimo

  From Herb Sutter's GotW #6 Return-by-value should normally be const for non-builtin return types. ... Note: Lakos (pg. 618) argues against returning const value, and notes that it is redundant for builtins anyway (for example, returning "const int"), which he notes may interfere with template instantiation. While Sutter seems to disagree on whether to return a const value or non-const value when returning an object of a non-built type by value with Lakos, he generally agrees that returning a const value of a built-in type (e.g const int) is not a good idea. While I understand why that is useless because the return value cannot be modified as it is an rvalue, I cannot find an example of how that might interfere with template instantiation. Please give me an example of how having a const qualifier for a return type might interfere with template instantiation.

  Read the article

• Why is T() = T() allowed?

  - by Rimo

  I believe the expression T() creates an rvalue (by the Standard). However, the following code compiles (at least on gcc4.0): class T {}; int main() { T() = T(); } I know technically this is possible because member functions can be invoked on temporaries and the above is just invoking the operator= on the rvalue temporary created from the first T(). But conceptually this is like assigning a new value to an rvalue. Is there a good reason why this is allowed? Edit: The reason I find this odd is it's strictly forbidden on built-in types yet allowed on user-defined types. For example, int(2) = int(3) won't compile because that is an "invalid lvalue in assignment". So I guess the real question is, was this somewhat inconsistent behavior built into the language for a reason? Or is it there for some historical reason? (E.g it would be conceptually more sound to allow only const member functions to be invoked on rvalue expressions, but that cannot be done because that might break some existing code.)

  Read the article

• Why is T() = T() allowed in C++?

  - by Rimo

  I believe the expression T() creates an rvalue (by the Standard) However the following code compiles (at least on gcc4.0) class T {... }; int main() { T() = T(); } I know technically this is possible because member functions can be invoked on temporaries and the above is just invoking the operator= on the r-value temporary created from T(). But conceptually this is like assigning a new value to an r-value. Is there a good reason why this is allowed?

  Read the article

• The pImpl idiom and Testability

  - by Rimo

  The pImpl idiom in c++ aims to hide the implementation details (=private members) of a class from the users of that class. However it also hides some of the dependencies of that class which is usually regarded bad from a testing point of view. For example if class A hides its implementation details in Class AImpl which is only accessible from A.cpp and AImpl depends on a lot of other classes, it becomes very difficult to unit test class A since the testing framework has no access to the methods of AImpl and also no way to inject dependency into AImpl. This has been a problem for me lately and I am beginning to think that the pImpl idiom and writing testable code don't mix well. Has anyone come across this problem before? and have you found a solution?

  Read the article

1