On Thu, Jan 7, 2010 at 8:00 PM, Michael Nordman wrote:
> Where as It looks like GURL::EmptyGURL() may be a tad less costly than
> GURL().
>
Not if you ever need to initialize another GURL with it (since the compiler
can't collapse the copy). Which is true much of the time that EmptyGURL()
can b
On Thu, Jan 7, 2010 at 4:02 PM, Darin Fisher wrote:
> On Thu, Jan 7, 2010 at 3:45 PM, Aaron Boodman wrote:
>
>> On Thu, Jan 7, 2010 at 1:28 PM, Peter Kasting
>> wrote:
>> > If you have ever used any of the EmptyXXX() functions, or ever will,
>> please
>> > read on.
>> > These functions (in stri
On Fri, Jan 8, 2010 at 1:51 AM, Albert J. Wong (王重傑) wrote:
> On Thu, Jan 7, 2010 at 2:46 PM, Darin Fisher wrote:
>
>>
>> On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow wrote:
>>
>>> (As discussed during lunch...) Why not just do this in this case and
>>> remove EmptyString() altogether?
>>>
>>>
On Fri, Jan 8, 2010 at 2:10 AM, Albert J. Wong (王重傑) wrote:
>
> According to wikipedia,
> http://en.wikipedia.org/wiki/Return_value_optimization, msvc, g++, and
> icc, all support it...or am I missing something about this situation that
> makes RVO inapplicable?
>
> Yes. Starting from version 3.1:
On Thu, Jan 7, 2010 at 3:45 PM, Aaron Boodman wrote:
> On Thu, Jan 7, 2010 at 1:28 PM, Peter Kasting wrote:
> > If you have ever used any of the EmptyXXX() functions, or ever will,
> please
> > read on.
> > These functions (in string_util.h and gurl.h) are meant for a single,
> > specific use ca
On Thu, Jan 7, 2010 at 3:45 PM, Aaron Boodman wrote:
> Out of curiosity, what is wrong with using EmptyString() in those
> cases? Is there a correctness problem? Unnecessary inclusion of
> string_util.h?
There are a couple reasons. Code clarity and consistency is a primary one;
using EmptyStri
On Thu, Jan 7, 2010 at 1:28 PM, Peter Kasting wrote:
> If you have ever used any of the EmptyXXX() functions, or ever will, please
> read on.
> These functions (in string_util.h and gurl.h) are meant for a single,
> specific use case:
> const std::string& MyClass::foo() const {
> return (everyth
[ resending from correct e-mail ]
> If you are saying that everywhere in the code can return by value instead
> of by const ref and the compiler will optimize it equivalently, you are
> wrong; I was under the same misapprehension until yesterday. We've verified
> that even in the best case
>
Th
On Thu, Jan 7, 2010 at 2:50 PM, Albert Wong (王重傑) wrote:
> Is there something wrong with returning by copy, and relying on the
> compiler to execute a return value optimization?
>
I'm not totally sure what your comment is saying.
If you are saying that everywhere in the code can return by value
On Thu, Jan 7, 2010 at 2:53 PM, Victor Khimenko wrote:
>
> On Fri, Jan 8, 2010 at 1:51 AM, Albert J. Wong (王重傑)
> wrote:
>
>> On Thu, Jan 7, 2010 at 2:46 PM, Darin Fisher wrote:
>>
>>>
>>> On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow wrote:
>>>
(As discussed during lunch...) Why not just
On Thu, Jan 7, 2010 at 2:46 PM, Darin Fisher wrote:
>
>
> On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow wrote:
>
>> (As discussed during lunch...) Why not just do this in this case and
>> remove EmptyString() altogether?
>>
>> const std::string& MyClass::foo() const {
>> static std::string emp
On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow wrote:
> (As discussed during lunch...) Why not just do this in this case and
> remove EmptyString() altogether?
>
> const std::string& MyClass::foo() const {
> static std::string empty = EmptyString();
> return (everything == OK) ? member_string
On Thu, Jan 7, 2010 at 1:50 PM, Jeremy Orlow wrote:
> What about renaming the function? EmptyStringHACK() or something?
It's not a hack. It's a perfectly legitimate thing to use, and not
something we're going to get rid of, unlike ToWStringHack().
Darin suggested we could make these return c
What about renaming the function? EmptyStringHACK() or something?
On Thu, Jan 7, 2010 at 1:49 PM, Peter Kasting wrote:
> On Thu, Jan 7, 2010 at 1:43 PM, Jeremy Orlow wrote:
>
>> You ignored the second half of my suggestion.
>>
>
> The second half of your suggestion leaks memory. When we have
On Thu, Jan 7, 2010 at 1:43 PM, Jeremy Orlow wrote:
> You ignored the second half of my suggestion.
>
The second half of your suggestion leaks memory. When we have easy and
elegant ways to avoid memory leaks, it behooves us to use them.
It also seems like a poor idea to me to suggest that, pot
On Thu, Jan 7, 2010 at 1:38 PM, Peter Kasting wrote:
> On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow wrote:
>
>> (As discussed during lunch...) Why not just do this in this case and
>> remove EmptyString() altogether?
>>
>> const std::string& MyClass::foo() const {
>> static std::string empty
On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow wrote:
> (As discussed during lunch...) Why not just do this in this case and
> remove EmptyString() altogether?
>
> const std::string& MyClass::foo() const {
> static std::string empty = EmptyString();
> return (everything == OK) ? member_string
(As discussed during lunch...) Why not just do this in this case and remove
EmptyString() altogether?
const std::string& MyClass::foo() const {
static std::string empty = EmptyString();
return (everything == OK) ? member_string : empty;
}
I forget if this runs the constructor on first use or
If you have ever used any of the EmptyXXX() functions, or ever will, please
read on.
These functions (in string_util.h and gurl.h) are meant for a single,
specific use case:
const std::string& MyClass::foo() const {
return (everything == OK) ? member_string : EmptyString();
}
Here you cannot r
19 matches
Mail list logo
