| comp.lang.c++@googlegroups.com | Google Groups |  |
| Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
| Nobody <nobody@nowhere.invalid>: Dec 08 10:18PM On Fri, 05 Dec 2014 12:20:47 +0000, Chicken Mcnuggets wrote: > but I thought it would be a good foundation to build on) and they > recommend two things that I wanted to clarify. > The second is never to use exceptions. When Google first wrote their style guide, exceptions had a (not entirely undeserved) reputation as something that popular compilers often got wrong. ISTR that they have said that if they were writing the style guide today, that rule wouldn't be there. But they now have a large codebase containing a large amount of C++ code (and some C code) which doesn't allow for exceptions. > This is the one I'm most thinking about. I recently got More Effective > C++ and item 15 was talking about the costs of using exceptions. Most of the cost of exceptions is only incurred if and when they are actually thrown. Allowing for the possibility of exceptions has some cost (related to foregoing certain optimisations which are only safe in the absence of exceptions), but not much. It's typically less than the cost of returning and checking status codes all over the place. As a rough guide, if failure is common, use a status return. If failure is exceptional, use an exception. E.g. if you're testing many candidate options until one succeeds, you want something which returns a status rather than throwing an exception on failure. |
| legalize+jeeves@mail.xmission.com (Richard): Dec 08 09:30PM [Please do not mail me a copy of your followup] In this month's meeting of the Utah C++ Programmers group, I'll be reviewing iterators, containers and algorithms in the standard library. Dinner will be provided by Utah Geek Events <http://www.utahgeekevents.com/>. We'd love to have you join us if you're in Salt Lake City or surrounding areas. Details here: <http://www.meetup.com/Utah-Cpp-Programmers/events/218665563/> -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| legalize+jeeves@mail.xmission.com (Richard): Dec 08 09:28PM [Please do not mail me a copy of your followup] I have been playing around with adding cppcheck and clang static analyzer to my continuous integration build for my github repository. This blog posts summarizes my results and shows you how to do it for your github repository: <http://legalizeadulthood.wordpress.com/2014/12/07/adding-static-analysis-to-your-c-github-repository/> -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| "Öö Tiib" <ootiib@hot.ee>: Dec 07 05:05PM -0800 On Monday, 8 December 2014 01:03:27 UTC+2, J.A. Belloc wrote: > if possible, one single example of the lvalue-to-rvalue conversion > being applied to a class type. Otherwise, I ask, why does §4.1/1 in > the Standard refer to this conversion? Maybe I misunderstand what you are asking. Ok, assignment accepts the parameter by reference to const so no conversion is needed. However for example if some other function (or operator or the like callable) accepts a parameter by value but lvalue is given as argument in call then there is lvalue-to-rvalue conversion applied to it. |
| "J.A. Belloc" <jabelloc@gmail.com>: Dec 08 04:02AM -0800 On Sunday, December 7, 2014 11:05:48 PM UTC-2, Öö Tiib wrote: > or the like callable) accepts a parameter by value but lvalue is given > as argument in call then there is lvalue-to-rvalue conversion applied to > it. "However for example if some other function (or operator or the like callable) accepts a parameter by value but lvalue is given as argument in call then there is lvalue-to-rvalue conversion applied to it." No there isn't, as the copy constructor is invoked and again, an lvalue binds to the constructor's parameter. No need for an lvaue-to-rvalue conversion. |
| "J.A. Belloc" <jabelloc@gmail.com>: Dec 08 05:35AM -0800 On Monday, December 8, 2014 10:04:26 AM UTC-2, J.A. Belloc wrote: > > it. > "However for example if some other function (or operator or the like callable) accepts a parameter by value but lvalue is given as argument in call then there is lvalue-to-rvalue conversion applied to it." > No there isn't, as the copy constructor is invoked and again, an lvalue binds to the constructor's parameter. No need for an lvaue-to-rvalue conversion. I'm not sure, but I may have found one example where the lvalue-to-rvalue conversion occurs for a class type. See the snippet below: class A{}; int main() { A a, b; a = std::move(b); } std::move(b) is an xvalue. In order for this xvalue to be used to update the object `a`, according to §3.10/2 ("Whenever a glvalue appears in a context where a prvalue is expected, the glvalue is converted to a prvalue"), it seems like this xvalue is converted to a prvalue. I would very much appreciate comments on this. Other examples are also welcome. Thanks. |
| "Öö Tiib" <ootiib@hot.ee>: Dec 08 07:08AM -0800 On Monday, 8 December 2014 14:04:26 UTC+2, J.A. Belloc wrote: > No there isn't, as the copy constructor is invoked and again, an > lvalue binds to the constructor's parameter. No need for an > lvaue-to-rvalue conversion. Standard does claim exactly same about that lvalue-to-rvalue conversion of class type: "this conversion effectively copy-constructs a temporary object of type T using the original glvalue as the constructor argument, and that temporary object is returned as a prvalue." So can you please clarify what you mean by "no" and how it differs from behavior described by standard? |
| "J.A. Belloc" <jabelloc@gmail.com>: Dec 08 10:08AM -0800 On Monday, December 8, 2014 1:08:47 PM UTC-2, Öö Tiib wrote: > constructor argument, and that temporary object is returned as a > prvalue." So can you please clarify what you mean by "no" and how it > differs from behavior described by standard? The Standard doesn't say "copy-constructs", but "copy-initializes", which is different from a copy construction. A copy-initialization, as you probably know, initializes an object, possibly using some kind of conversion (standard conversion, user-defined conversion, or a standard conversion sequence) followed by an implicit copy construction of the temporary, when this copy is not elided. These are the exact words in paragraph §4.1/2, second bullet point, of N3797: "- Otherwise, if T has a class type, the conversion copy-initializes a temporary of type T from the glvalue and the result of the conversion is a prvalue for the temporary." But the important point here was that, while trying to write down this answer, I noticed that paragraphs §4.1/1 and §4.1/2 were modified from C++11 (N3337) to C++14 (N3797). When I posted my question I was thinking in terms of C++11 (N3337), which doesn't show the bullet point above. So that, now reading the new version of paragraph §4.1/2, I can see that the Standard explicitly defines a copy initialization of a class type, as an lvalue-to-rvalue conversion. Note that this definition doesn't exist in C++11 (N3337). Therefore, the revised version of §4.1/2 answers my original question. Thanks for your attention. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment