Wednesday, September 16, 2015

Digest for comp.lang.c++@googlegroups.com - 8 updates in 5 topics

ram@zedat.fu-berlin.de (Stefan Ram): Sep 16 11:10PM

>and that it's a 'courtesy thing' to do it anyway? I'd not mind
>defining one at all, but I'm puzzled if it is required and, if
>yes, why;-)
 
It is true that 5.2.1 says,
 
»The expression E1[E2] is identical (by definition) to
*((E1)+(E2))«,
 
but this does /not/ seem to intend to express that for classes
the behavior of E1[E2] will silently be deduced from operator+
and operator*. Otherwise, why do we have 13.5.5?
 
If one is inheriting from an (abstract) base class, it is
possible that this base class contains a definition for
operator[] in terms of the (abstract) operator+ and the
(abstract) operator*.
ram@zedat.fu-berlin.de (Stefan Ram): Sep 16 11:19PM

>but this does /not/ seem to intend to express that for classes
>the behavior of E1[E2] will silently be deduced from operator+
>and operator*. Otherwise, why do we have 13.5.5?
 
It does /not/ mean that it is /always/ deduced in the case
of a general class. It might be deduced in some contexts
with special preparations for the case that + and * is
defined, but not [].
jt@toerring.de (Jens Thoms Toerring): Sep 16 09:33PM

Hi,
 
I've been playing around a bit wist custom random-acccess
iterators (just for my own education and the fun of it) and
read that such an iterator must have an offset dereference
operator ([]). Does that imply that I have to define such an
operator method in the iterator? Looking at what happens when
I have e.g.
 
Custom_Container cc;
Custom_Container< int >::iterator ccit = cc.begin();
 
and later, once the container has acquired some elements, doing
e.g.
 
std::cout << ccit[ 1 ] << std::endl;
 
I found that an overloaded '[]' operator in the iterator
neither seemed to be necessary nor was it called if defined.
Since 'x[n]' is just syntactic sugar for '*(x+n)' I'm tempted
to assume that having the required '+' and the dereferencing
operator is all that's actually needed. Looking at several
examples of implementations of custom iterators by others (of
which I can't assess their quality) I find that some define a
'[]' operator and others don't, leaving me a bit puzzled what
is required. If it's defined it usually boils down to either
 
T & operator [ ] ( int n ) { return m_ptr[ n ]; }
or
T & operator [ ] ( int n ) { return *( m_ptr + n ); }
 
which looks a bit superfluous. Or was having such an overload
somthing required in pre-C++11 days but is now not needed any-
more?
Thanks and best regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
legalize+jeeves@mail.xmission.com (Richard): Sep 16 09:41PM

[Please do not mail me a copy of your followup]
 
jt@toerring.de (Jens Thoms Toerring) spake the secret code
 
>which looks a bit superfluous. Or was having such an overload
>somthing required in pre-C++11 days but is now not needed any-
>more?
 
IMO, it's nice to explicitly declare operator[] in the header so that
the header more clearly reveals it's intention that this is a random
access iterator.
 
At least until we get Concepts where you can explicitly declare
yourself as an instance of the RandomAccessIterator concept.
--
"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>
jt@toerring.de (Jens Thoms Toerring): Sep 16 10:38PM


> IMO, it's nice to explicitly declare operator[] in the header so that
> the header more clearly reveals it's intention that this is a random
> access iterator.
 
May I conclude that it's not required to define a '[]' operator
and that it's a 'courtesy thing' to do it anyway? I'd not mind
defining one at all, but I'm puzzled if it is required and, if
yes, why;-)
Thanks and best regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 16 10:14PM

On Fri, 2015-08-21, Stefan Ram wrote:
...
 
> the Usenet, where I was told:
 
> »It's unspecified whether stack unwinding happens when
> there is no handler for an exception.«
 
I don't quite see how you go from that to "RAII won't work without a
global try-catch". Without one, you'll have an unknown number of code
paths where destructors aren't run before a crash, but you'll have
that anyway for assert() and std::exit() calls, and for pure crashes.
 
And RAII still works for all other code paths.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 16 06:40PM

On Mon, 2015-08-17, Scott Lurndal wrote:
 
> And of course, counter-examples abound. snprintf could have been
> used in place of strcat (and would have avoided the buffer overflow).
 
> Even proper use of strncat would have sufficed.
 
"Proper" often means detecting that truncation has happened, and
somehow correcting it. That can easily become a lot of code ...
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 16 06:53AM

On Tue, 2015-09-15, Martin Shobe wrote:
 
>> The original description is sloppy. It's not strictly an array of S1*,
>> but rather an array of void* which point to S1.
 
> Then the cast above is ok, and what I would recommend.
 
Ah, now I see the different interpretations, too. Yes, "array of
void* which point to S1" was how I read the original posting.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)