Dear moderators,

below is a list of three articles posted between December 21 and 22
UTC that seem completely disappeared. Could you please check if they
are still in the queue? I'm sorry that I didn't receive any
notification for them, so I don't have any track number.

==== For comp.std.c++ (1 post) ====
Subject: Re: Questions about vector's interface

On Thu, 21 Dec 2006 20:48:51 GMT, Howard Hinnant wrote:

>> Scott Meyers wrote:
>> > I recently noticed a couple of things about vector's interface I

>> > don't understand.
>> >
>>
>> > 2.  vector::resize has this signature:
>> >
>> >       void resize(size_type, T = T());
>> >
>> >     Why is the second argument passed by value instead of by
>> >     ref-to-const?  The analogous constructor uses ref-to-const:
>> >
>> >       explicit vector(size_type, const T& = T(), [...] );
>> >
>> > Thanks for any clarification of these design decisions.
>> >
>>
>> vector<int> v;
>> // populate v;
>>
>> v.resize(v[0]);
>>
>> If resize takes its argument by reference, the reference to v[0]
>> becomes invalid during the resize. Passing the argument by values
>> means that resize is always dealing with a copy, so there's no
>> validity problem.
>
>This was the reason, but it is in error.

That's a typo for v.resize( s, v[ 0 ] ), isn't it?

>Taking t by value is a plain
>and simple performance bug in the standard.
>
>There are 3 cases to consider:
>
>1.  Size is shrinking.
>2.  Size is growing, but to less than or equal to capacity().
>3.  Size is growing beyond capacity().
>
>In case 1, t is never referenced.  So the fact that the call may
>invalidate it is irrelevant.
>
>In case 2, t can not be invalidated.
>
>In case 3, t can be invalidated (as the old buffer is destroyed),
but
>it is trivial to delay deleting the old buffer until the new buffer
>is fully populated, including the new copies of t.

In addition to what you point out, the choice is quite against the
don't pay for what you don't use principle: if one wants to pass a
value from v itself then why not writing

  T t( v[ i ] );
  v.resize( v, t );

Or am I missing something? Is there any chance to fix this in the
standard?

==== For comp.lang.c++.moderated (2 posts) ====

[1] - Subject: Re: namespace name must be unique -- gcc

On 21 Dec 2006 09:39:16 -0500, Greg Herlihy wrote:

>Gennaro Prota wrote:
>> >class x{};
>> >namespace x{}
>> >
>> >int main(int argc, char** argv)
>> >{ return 0; }
>>
>> I'm 97% sure that the intent is for this to be illegal :-) The
fact
>> is, though, that the definition of "entity", given in clause 3,
does
>> not include classes.
>
>But a class is a "type" and a type is an entity

Aaaargh... I completely missed "type" from the list! Odd that I
wasn't alone, though; perhaps because it's such a short word among so
many long(er) ones... :-)

---------------------------------------------------------------------

[2] - Subject: Re: speed performance: reference vs. pointer

On 21 Dec 2006 12:52:08 -0500, James Kanze wrote:

>Gennaro Prota wrote:
>> On 19 Dec 2006 13:02:28 -0500, James Kanze wrote:
>
>      [...]
>> >Even when it does use a pointer, the reference version could be
>> >faster, because the compiler knows that it won't change.  In
>> >general, the more information the compiler has to work with, the
>> >better it can optimize
>>
>> Can or could. Unfortunately real compilers may surprise you on
this.
>
>It's gotten to the point where almost nothing a real compiler
>does will surprise me anymore. (Except, maybe, output readable
>error messages.  That would surprise me.)

Well, template-related rebuses apart, EDG frontends rock. For
templates I don't know what can possibly be done... it looks like
many people are happy with STLFilt, but I don't have experience with
it (well, I enjoy rebuses anyway, so my subconscious could have
refrained me from giving it a try :-)).

>> A recent case I came upon with gcc and my SHA class templates was
>> something along the lines of:
>
>>   const int sz( 8 );
>>   template< typename ... >
>>   void f( byte_type( &a )[ sz ] )
>>   {
>>     ...
>>     return f_impl( a );
>>
>>   }
>
>>   template< typename ...>
>>   void f_impl( byte_type( & a )[ sz ] )
>>   {
>>     ...
>>   }
>
>> It is hard to believe but changing f_impl's parameter to type
>> byte_type * had a tremendous performance impact on the generated
code.
>
>Interesting.  I would have expected as a first approximation
>that the implementation treat it exactly as if you'd passed a
>byte_type*, once the template parameters were deduced.
>According to the standard, it could add bounds checking (since
>the information is present, which it isn't with a pointer), but
>somehow, I'd be rather surprised if this were the case.
>
>Did you look at the generated code, to see what the difference
>was.

No, I didn't, as I was in the middle of other changes and just
discovered the fact "by chance". The overall structure of the code
however hasn't substantially changed since then, so I could try
reproducing the issue after the release.

>> [...]
>
>> And because of
>> these not so infrequent facts I'm unwillingly convincing myself
>> that benchmarks should be part of the regression tests.
>
>A program has to be "fast enough".  And regression tests should
>verify that.  Even if, in practice, it's rarely a problem.  A
>modification might slow the program down 10%, but in the
>meantime, the machines it's running on have speeded up 50%.

Yes, that's one of the reasons why in effect I'm reluctant. And
differently from regression tests, performance tests would require
you to store the speed results somewhere, for every supported
platform, in order to compare them with the new ones. I don't know
what a solid solution could be. Of course, I'd just like to detect
sudden substantial performance losses, that could otherwise get
unnoticed.

---------------------------------------------------------------------

Genny.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Gennaro Prota wrote:
> Dear moderators,
>
> below is a list of three articles posted between December 21 and 22
> UTC that seem completely disappeared. Could you please check if they
> are still in the queue? I'm sorry that I didn't receive any
> notification for them, so I don't have any track number.
>
> ==== For comp.std.c++ (1 post) ====
> Subject: Re: Questions about vector's interface
>
> ==== For comp.lang.c++.moderated (2 posts) ====
>
> [1] - Subject: Re: namespace name must be unique -- gcc
> [2] - Subject: Re: speed performance: reference vs. pointer

There is currently no articles waiting for moderation in the queue of
comp.lang.c++.moderated. If you didn't receive any notification, they
might have been lost and you may want to try reposting. Sorry for the
inconvenience.

--
Seungbeom Kim

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]