comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* pointer to a vector - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/b17f744707f37fdb?hl=en
* beginner - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/764088b8acc86a74?hl=en
* Can't think of a good subject - 12 messages, 6 authors
http://groups.google.com/group/comp.lang.c++/t/ff410bf5e81204c2?hl=en
* Return by reference - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/f6dd94c3223a1dbf?hl=en
* Boost - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
* Address one past the end of array - is this syntax a valid C++? - 3 messages,
2 authors
http://groups.google.com/group/comp.lang.c++/t/3660f2b84a4f1cb3?hl=en
==============================================================================
TOPIC: pointer to a vector
http://groups.google.com/group/comp.lang.c++/t/b17f744707f37fdb?hl=en
==============================================================================
== 1 of 5 ==
Date: Wed, Feb 12 2014 12:32 pm
From: "A"
"Jorgen Grahn" <grahn+nntp@snipabacken.se> wrote in message
news:slrnlfnle0.81f.grahn+nntp@frailea.sa.invalid...
> No, and yes. You haven't done 'new', so you're not responsible for
> doing 'delete'. BTW, both of those are rarely needed in modern code
> -- if you use them a lot you're probably doing something wrong.
No, I don't use normally new or delete. I use boost smart pointers and
vectors.
Good thing to know this rule of a thumb - using new = delete, not using it,
then it is just a pointer.
> No cleanup required. But I don't really understand what you're trying
> to say ...
What I though is that if it is pointer to a vector then it is somehow
different but obviously it is just a same pointer like any other. So yes,
then no cleanup is required, it is just a pointer variable.
>> b) what's the heap or stack or difference or advantage of them in
>> relation
>> to the above?
> I don't understand that question. Please rephrase.
A guy here was mentioning heap so I though it was related. Seems it is not:
http://facepunch.com/showthread.php?t=780439
== 2 of 5 ==
Date: Wed, Feb 12 2014 12:34 pm
From: "A"
"Paavo Helde" <myfirstname@osa.pri.ee> wrote in message
news:XnsA2D2E1C8E2580myfirstnameosapriee@216.196.109.131...
> No, as a rule of thumb, if your code does not contain 'new' then there is
> no need for 'delete' either (and this is a good thing). Any dynamically
> allocated memory is maintained and released by the std::vector objects
> internally.
That's a good rule to remember. So it is just a plain pointer. Thanks!
> std::vector automatically stores the stuff in the right place, you do not
> need to worry about this. Just avoid raw arrays and 'new' (as you have
> done so far) and you should be fine.
Yes, haven't been using new/delete in years since I discovered smart
pointers and vectors.
== 3 of 5 ==
Date: Wed, Feb 12 2014 12:43 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)
"A" <a@a.a> writes:
>There are 2 vectors each one having a structure
>std::vector<MyStruct> v1;
>std::vector<MyStruct> v2;
IIRC, the default constructor constructs an /empty/ vector.
This means that /neither/ vector so far has a structure.
== 4 of 5 ==
Date: Wed, Feb 12 2014 1:01 pm
From: Jorgen Grahn
On Wed, 2014-02-12, A wrote:
> "Jorgen Grahn" <grahn+nntp@snipabacken.se> wrote in message
> news:slrnlfnle0.81f.grahn+nntp@frailea.sa.invalid...
[...]
>>> b) what's the heap or stack or difference or advantage of them in
>>> relation
>>> to the above?
>> I don't understand that question. Please rephrase.
>
> A guy here was mentioning heap so I though it was related. Seems it is not:
> http://facepunch.com/showthread.php?t=780439
I don't know which of them, but several of them seem rather confused.
You'll get better answers here, with the right questions.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 5 of 5 ==
Date: Thurs, Feb 13 2014 5:23 am
From: "A"
"Stefan Ram" <ram@zedat.fu-berlin.de> wrote in message
news:vector-20140212214210@ram.dialup.fu-berlin.de...
> IIRC, the default constructor constructs an /empty/ vector.
> This means that /neither/ vector so far has a structure.
Of course, I know that - that was just a dumb example. Thanks for pointing
this out though. Much appreciate the effort.
==============================================================================
TOPIC: beginner
http://groups.google.com/group/comp.lang.c++/t/764088b8acc86a74?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Feb 12 2014 1:16 pm
From: woodbrian77@gmail.com
On Wednesday, February 12, 2014 1:27:31 PM UTC-6, Jorgen Grahn wrote:
> On Wed, 2014-02-12, Stefan Ram wrote:
>
> > frank cubi <frankcubi7@gmail.com> writes:
>
> >>Which is the most appropriate website for a person who is learning c++ ?
>
> >
>
> > I know some good books:
>
> >
>
> > You can read (in this order and doing the exercise):
>
> > Programming -- Principles and Practice Using C++ (only if
>
> > you have not programmed before) or Accelerated C++ (if you
>
> > have programmed before), The C++ Programming Language,
>
> > Effective C++, Exceptional C++ (Parts 1 and 2), Modern
>
> > C++ programming, and ISO/IEC 14882:2011.
>
> >
>
> > There also might be websites with similar contents, but
>
> > I am not aware of them.
>
>
>
> Me neither. https://www.sgi.com/tech/stl/ is the only one I use. And
> /The C++ Programming Language/ is the only book I've read and liked.
> However, this mostly means I learned C++ slowly, and started a long
> time ago ...
>
> Apart from that I recommend:
> - writing lots of code
> - reading lots of code
I have an archive here:
http://webEbenezer.net/build_integration.html
That you're welcome to download and read.
The code uses some of the newer features
of the language.
Brian
Ebenezer Enterprises
http://webEbenezer.net
== 2 of 2 ==
Date: Wed, Feb 12 2014 1:44 pm
From: "K. Frank"
Hello Frank!
On Wednesday, February 12, 2014 1:01:15 PM UTC-5, frank cubi wrote:
> Which is the most appropriate website for a person who is learning c++ ?
As Paavo mentioned,
http://www.parashift.com/c++-faq/
is a good place to start.
(Some minor caveats: It can be a little overly prescriptive;
it's philosophy is a bit too narrowly object oriented; and
it's showing its age a little. One pet peeve of mind is that
the web site's format became overly fragmented a few years ago.)
For features added in the most recent standard (already a few
years ago) Stroustrup's C++11 FAQ is very good:
http://www.stroustrup.com/C++11FAQ.html
Two good (not perfect) reference sites are:
http://en.cppreference.com/w/
and
http://www.cplusplus.com/reference/
(or if you prefer, http://www.cplusplus.com/).
Stefan's book suggestions are very good.
Also, although not technically a web site, this usenet group
(or its moderated companion, comp.lang.c++.moderated) is a
good place to post specific, single-topic questions when you
come across something you don't understand or don't see how
to do. (If you're learning, you'll get better answers if
you do your homework first.)
Happy Hacking!
K. Frank
==============================================================================
TOPIC: Can't think of a good subject
http://groups.google.com/group/comp.lang.c++/t/ff410bf5e81204c2?hl=en
==============================================================================
== 1 of 12 ==
Date: Wed, Feb 12 2014 7:45 pm
From: woodbrian77@gmail.com
I'm not sure why the behavior of the following
two functions differs here. The only difference
in these functions is in the body of the loop.
template <class R>
void Receive (::cmw::ReceiveBuffer<R>& buf
,empty_container<cmw::File>& az1)
{
int32_t count[1];
count[0]=buf.template Give<uint32_t>();
for(;count[0]>0;--count[0]){
cmw::File inst(buf); // named
}
}
template <class R>
void Receive (::cmw::ReceiveBuffer<R>& buf
,empty_container<cmw::File>& az1)
{
int32_t count[1];
count[0]=buf.template Give<uint32_t>();
for(;count[0]>0;--count[0]){
cmw::File (buf);
}
}
The first (named) version works the way I want
it to, and the second version, built with either
gcc or clang doesn't. Both compilers are
producing smaller text segments for the second
version. And the results for that version
(both compilers) are like nothing is being done
in the loop.
Can someone explain this? In another file I
have some code similar to the second version
and it works fine:
while(fgets(lineBuf,300,Fl.FlHndl)){
token=strtok(lineBuf," ");
if(strcmp("Header",token)) break;
cmw::File (strtok(nullptr,"\n ")).Marshal(buf);
}
I've simplified that loop a little, but don't
think I've removed anything important. There
are different constructors being used in these
two cases.
http://webEbenezer.net/misc/File.hh
Thanks.
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
== 2 of 12 ==
Date: Thurs, Feb 13 2014 9:00 am
From: Bo Persson
woodbrian77@gmail.com skrev 2014-02-13 04:45:
>
> I'm not sure why the behavior of the following
> two functions differs here. The only difference
> in these functions is in the body of the loop.
>
> template <class R>
> void Receive (::cmw::ReceiveBuffer<R>& buf
> ,empty_container<cmw::File>& az1)
> {
> int32_t count[1];
> count[0]=buf.template Give<uint32_t>();
> for(;count[0]>0;--count[0]){
> cmw::File inst(buf); // named
> }
> }
>
>
> template <class R>
> void Receive (::cmw::ReceiveBuffer<R>& buf
> ,empty_container<cmw::File>& az1)
> {
> int32_t count[1];
> count[0]=buf.template Give<uint32_t>();
> for(;count[0]>0;--count[0]){
> cmw::File (buf);
> }
> }
>
>
> The first (named) version works the way I want
> it to, and the second version, built with either
> gcc or clang doesn't. Both compilers are
> producing smaller text segments for the second
> version. And the results for that version
> (both compilers) are like nothing is being done
> in the loop.
The second version also declares a named variable, buf. Parenthesis are
optional when declaring variables.
Bo Persson
== 3 of 12 ==
Date: Thurs, Feb 13 2014 10:53 am
From: woodbrian77@gmail.com
On Thursday, February 13, 2014 11:00:01 AM UTC-6, Bo Persson wrote:
> woodbrian77@gmail.com skrev 2014-02-13 04:45:
>
>
> > The first (named) version works the way I want
> > it to, and the second version, built with either
> > gcc or clang doesn't. Both compilers are
> > producing smaller text segments for the second
> > version. And the results for that version
> > (both compilers) are like nothing is being done
> > in the loop.
>
> The second version also declares a named variable, buf. Parenthesis are
> optional when declaring variables.
>
OK, I see what you mean. Is there a way to
tell the compiler I want an anonymous File
object to be constructed using the buf object?
== 4 of 12 ==
Date: Thurs, Feb 13 2014 10:59 am
From: Alain Ketterlin
Bo Persson <bop@gmb.dk> writes:
> woodbrian77@gmail.com skrev 2014-02-13 04:45:
>> template <class R>
>> void Receive (::cmw::ReceiveBuffer<R>& buf
>> ,empty_container<cmw::File>& az1)
>> {
>> int32_t count[1];
>> count[0]=buf.template Give<uint32_t>();
>> for(;count[0]>0;--count[0]){
>> cmw::File inst(buf); // named
>> }
>> }
>>
>> template <class R>
>> void Receive (::cmw::ReceiveBuffer<R>& buf
>> ,empty_container<cmw::File>& az1)
>> {
>> int32_t count[1];
>> count[0]=buf.template Give<uint32_t>();
>> for(;count[0]>0;--count[0]){
>> cmw::File (buf);
>> }
>> }
>>
>> The first (named) version works the way I want
>> it to, and the second version, built with either
>> gcc or clang doesn't.
What way do you want it to "work"?
>> Both compilers are producing smaller text segments for the second
>> version. And the results for that version (both compilers) are like
>> nothing is being done in the loop.
>
> The second version also declares a named variable, buf. Parenthesis
> are optional when declaring variables.
Hmm, I think the second version creates a temporary (with buf as a
parameter to the constructor), which is not used and therefore
eliminated by the compiler. What part of the standard this behavior is
based on I don't know.
-- Alain.
== 5 of 12 ==
Date: Thurs, Feb 13 2014 11:27 am
From: red floyd
On 2/13/2014 10:53 AM, woodbrian77@gmail.com wrote:
> On Thursday, February 13, 2014 11:00:01 AM UTC-6, Bo Persson wrote:
>> woodbrian77@gmail.com skrev 2014-02-13 04:45:
>>
>>
>>> The first (named) version works the way I want
>>> it to, and the second version, built with either
>>> gcc or clang doesn't. Both compilers are
>>> producing smaller text segments for the second
>>> version. And the results for that version
>>> (both compilers) are like nothing is being done
>>> in the loop.
>>
>> The second version also declares a named variable, buf. Parenthesis are
>> optional when declaring variables.
>>
>
> OK, I see what you mean. Is there a way to
> tell the compiler I want an anonymous File
> object to be constructed using the buf object?
>
Accidentally hit "reply" instead of "followup".
I think you need to put double parens around "buf".
It's very similar to the "most vexing parse" situation.
== 6 of 12 ==
Date: Thurs, Feb 13 2014 2:10 pm
From: woodbrian77@gmail.com
On Thursday, February 13, 2014 1:27:30 PM UTC-6, red floyd wrote:
> On 2/13/2014 10:53 AM, woodbrian77@gmail.com wrote:
>
> > On Thursday, February 13, 2014 11:00:01 AM UTC-6, Bo Persson wrote:
>
> >> The second version also declares a named variable, buf. Parenthesis are
> >> optional when declaring variables.
>
> >>
>
> > OK, I see what you mean. Is there a way to
> > tell the compiler I want an anonymous File
> > object to be constructed using the buf object?
> >
>
> Accidentally hit "reply" instead of "followup".
>
I'm not aware of a followup option. I just hit reply.
> I think you need to put double parens around "buf".
I didn't mention it in my original post, but I did
try that and just tried it again. Both compilers
produce the same output, according to the cmp command,
for
cmw::File (buf);
and
cmw::File ((buf));
I wasn't really sure why I thought of trying that,
but probably had read somewhere where that had
helped someone.
> It's very similar to the "most vexing parse" situation.
I was afraid of that also, but decided to post
because I wasn't figuring it out here.
Brian
Ebenezer Enterprises
http://webEbenezer.net
== 7 of 12 ==
Date: Thurs, Feb 13 2014 2:29 pm
From: woodbrian77@gmail.com
On Thursday, February 13, 2014 12:59:42 PM UTC-6, Alain Ketterlin wrote:
> Bo Persson <bop@gmb.dk> writes:
>
>
>
> > woodbrian77@gmail.com skrev 2014-02-13 04:45:
>
> >>
> >> The first (named) version works the way I want
> >> it to, and the second version, built with either
> >> gcc or clang doesn't.
>
> What way do you want it to "work"?
>
I'm looking for something analogous to this:
while(fgets(lineBuf,300,Fl.FlHndl)){
token=strtok(lineBuf," ");
if(strcmp("Header",token)) break;
cmw::File (strtok(nullptr,"\n ")).Marshal(buf);
}
That creates an anonymous File object.
> >> Both compilers are producing smaller text segments for the second
> >> version. And the results for that version (both compilers) are like
> >> nothing is being done in the loop.
> >
>
> > The second version also declares a named variable, buf. Parenthesis
> > are optional when declaring variables.
>
> Hmm, I think the second version creates a temporary (with buf as a
> parameter to the constructor), which is not used and therefore
> eliminated by the compiler.
>
That's what I was thinking might be happening originally,
but I think what Bo wrote is correct. At least according
to the cmp command, there's no difference between:
cmw::File buf;
and
cmw::File (buf);
for either compiler.
Brian
Ebenezer Enterprises
http://webEbenezer.net
== 8 of 12 ==
Date: Thurs, Feb 13 2014 2:46 pm
From: woodbrian77@gmail.com
Just to clarify, both compilers produce the same
output, according to the cmp command, for these
three forms:
cmw::File buf;
cmw::File (buf);
cmw::File ((buf));
== 9 of 12 ==
Date: Thurs, Feb 13 2014 4:05 pm
From: woodbrian77@gmail.com
On Thursday, February 13, 2014 4:29:13 PM UTC-6, woodb...@gmail.com wrote:
> On Thursday, February 13, 2014 12:59:42 PM UTC-6, Alain Ketterlin wrote:
>
> > Hmm, I think the second version creates a temporary (with buf as a
> > parameter to the constructor), which is not used and therefore
> > eliminated by the compiler.
> >
>
> That's what I was thinking might be happening originally,
> but I think what Bo wrote is correct. At least according
> to the cmp command, there's no difference between:
>
> cmw::File buf;
>
> and
>
> cmw::File (buf);
>
> for either compiler.
>
I turned on -Wshadow and that also makes me think
it's doing what Bo suggested.
/zz.middle_messages_back.hh: In member function 'void middle_messages_back::Receive(cmw::ReceiveBuffer<R>&, empty_container<cmw::File>&)':
./zz.middle_messages_back.hh:38:19: warning: declaration of 'cmw::File buf' shadows a parameter [-Wshadow]
cmw::File (buf);
Brian
Ebenezer Enterprises
http://webEbenezer.net
== 10 of 12 ==
Date: Thurs, Feb 13 2014 5:09 pm
From: Richard Damon
On 2/13/14, 5:29 PM, woodbrian77@gmail.com wrote:
>
> I'm looking for something analogous to this:
>
> while(fgets(lineBuf,300,Fl.FlHndl)){
> token=strtok(lineBuf," ");
> if(strcmp("Header",token)) break;
> cmw::File (strtok(nullptr,"\n ")).Marshal(buf);
> }
>
> That creates an anonymous File object.
>
perhaps
0, cmw:File(buf);
might work. The key is you need to make it so it can not be parsed as a
decleration.
== 11 of 12 ==
Date: Thurs, Feb 13 2014 7:28 pm
From: "K. Frank"
Hello Brian!
On Thursday, February 13, 2014 1:53:58 PM UTC-5, woo...@woo...com wrote:
> On Thursday, February 13, 2014 11:00:01 AM UTC-6, Bo Persson wrote:
> > woo...@woo...com skrev 2014-02-13 04:45:
> >
> > > The first (named) version works the way I want
> > > it to, and the second version, built with either
> > > gcc or clang doesn't. Both compilers are
> > > producing smaller text segments for the second
> > > version. And the results for that version
> > > (both compilers) are like nothing is being done
> > > in the loop.
> >
> > The second version also declares a named variable, buf. Parenthesis are
> > optional when declaring variables.
>
> OK, I see what you mean. Is there a way to
> tell the compiler I want an anonymous File
> object to be constructed using the buf object?
If you're willing to use C++11, you can use its
so-called uniform initialization:
cmw::File{buf};
(Note the curly braces instead of parentheses.)
The curly-brace initializer list is not compatible
with the expression being interpreted as declaring
buf a variable, and so avoids the most-vexing-parse
issue.
Good luck.
K. Frank
== 12 of 12 ==
Date: Thurs, Feb 13 2014 8:16 pm
From: woodbrian77@gmail.com
On Thursday, February 13, 2014 9:28:39 PM UTC-6, K. Frank wrote:
> Hello Brian!
>
> If you're willing to use C++11, you can use its
> so-called uniform initialization:
>
> cmw::File{buf};
>
> (Note the curly braces instead of parentheses.)
>
> The curly-brace initializer list is not compatible
> with the expression being interpreted as declaring
> buf a variable, and so avoids the most-vexing-parse
> issue.
>
I've heard of that a little, but didn't think of it
here. Have tested it and it's working.
I'm using some of the newer C++ features so using
another one isn't a problem. Thank you.
==============================================================================
TOPIC: Return by reference
http://groups.google.com/group/comp.lang.c++/t/f6dd94c3223a1dbf?hl=en
==============================================================================
== 1 of 2 ==
Date: Fri, Feb 14 2014 1:34 am
From: James Kanze
On Sunday, 9 February 2014 12:04:19 UTC, Marcel Müller wrote:
> On 09.02.14 12.50, Giuliano Bertoletti wrote:
> > which is the difference of calling?
> > ==================
> > MyClass c;
> > SubObject &sub = c.GetSubObject();
> > SubObject sub = c.GetSubObject();
> > ==================
> The second line creates a copy of SubObject. It is in fact another
> syntax for the following constructor call:
> SubObject sub(GetSubObject());
> This /might/ be expensive if copying SubObject is expensive. Furthermore
> changes to sub do not apply to c.GetSubObject().
Whether the changes should apply or not is the key. Reference
semantics and value semantics are two different things.
> In general you should prefer references for non-trivial data types
> unless you have good reasons not to do so.
Not for return values. References lock you in; once you return
a reference, you can never return a synthesized value. The
general rule is to return by value unless the intent is to
furnish access to an element of the object (e.g. things like the
operator[] of vector).
--
James
== 2 of 2 ==
Date: Fri, Feb 14 2014 1:38 am
From: James Kanze
On Sunday, 9 February 2014 12:21:40 UTC, Luca Risolia wrote:
> Giuliano Bertoletti wrote:
> > SubObject &sub = c.GetSubObject();
> Don't return references to sub objects.
That depends on the role of the class. Things like
std::vector<>::operator[] should certainly return a reference.
> To safely share (sub)objects in memory use smart pointers.
I can't really think of a situation where I'd want to "share" an
object. An object will normally either be independant (an
entity object, owned by no one), or part of another object.
--
James
==============================================================================
TOPIC: Boost
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
==============================================================================
== 1 of 2 ==
Date: Fri, Feb 14 2014 7:03 am
From: James Kanze
On Saturday, 18 January 2014 00:09:45 UTC, Ian Collins wrote:
> woodbrian77@gmail.com wrote:
> > On Friday, January 17, 2014 9:37:16 AM UTC-6, Alf P. Steinbach wrote:
> >> You can use the header-only sub-libraries without building Boost.
> >> However, the most useful of them are now part of the standard, e.g.
> >> shared_ptr.
> > I think std::array would be a better example. I still
> > don't find much need for shared_ptr.
> Maybe you don't but others certainly do!
I don't know. The way it's implemented often creates more
problems than it's worth.
Reference counted pointers seem irrelevant for a lot of
applications: some won't use any dynamic memory, except within
the standard containers, and many others will only use it for
entity objects, which have deterministic lifetimes for which
shared_ptr is totally irrelevant. And even in the few cases
where intensive use of reference counted pointers is relevant,
you probably want some sort of invasive counting, to avoid
errors. We experimented with `std::shared_ptr` when we moved to
C++11, but found that it didn't work for us, and went back to
our home written one.
--
James
== 2 of 2 ==
Date: Fri, Feb 14 2014 7:07 am
From: James Kanze
On Saturday, 18 January 2014 08:30:57 UTC, Nick Baumbach wrote:
> Ian Collins oratorically vehemently insists
> > On a more up to date machine with gcc:
> > time ./b2 -j 32
> > <stuff>
> > The Boost C++ Libraries were successfully built!
> > real 1m2.319s user 27m57.961s sys 1m49.214s
> Wow, -j 32 !! Say no more. Where did you find that 32 since at most I only
> can find 16, as 2 threads per core. Actually thread core, not real core.
> An i7 is still a 4 core, not sure how that threaded core is embedded into
> the hardware.
Maybe he's not using an Intel. Where I used to work (four and
a half years ago), I "inherited" a 32 core Sparc because it
wasn't fast enough for production (where 128 cores was the
minimum). And that was some time ago.
--
James
==============================================================================
TOPIC: Address one past the end of array - is this syntax a valid C++?
http://groups.google.com/group/comp.lang.c++/t/3660f2b84a4f1cb3?hl=en
==============================================================================
== 1 of 3 ==
Date: Fri, Feb 14 2014 7:30 am
From: James Kanze
On Saturday, 1 February 2014 17:23:39 UTC, Peter wrote:
> Assume we have an array:
> int arr[5];
> It's legal to refer to address arr + 5, but, of course,
> illegal to refer to element arr[5] as it's not part of the
> array. However, arr + n is equivalent to &arr[n].
No it's not. They're only equivalent if the expression "arr[n]"
is a valid expression.
> My question
> is: does this equivalence also hold for an edge case of
> n = 5 (or, generally, n equal to number of elements of array)?
> While there's nothing wrong with arr + 5, &arr[5] looks highly
> suspicious: it looks like in the first step arr[5] is
> evaluated (which introduces an undefined behaviour) which
> would mean the expression as a whole is undefined.
Exactly.
> Does the
> equivalence still hold in this special case?
No. "arr + 5" is legal, and corresponds to a pointer one beyond
the end of the array. "&arr[5]" is undefined behavior.
C has a special rule to allow "&arr[5]". Back before C++03 (and
even before C++98, I think), there was some discussion about
allowing this in C++, but in the end, the special case was not
adopted. (I think part of the motivation for not adopting it is
that you couldn't make it work with user defined containers,
like std::vector. Something like:
std::vector<int> v(5);
int* p = &v[5];
will crash, at least in debug mode, in all of the
implementations I use.)
--
James
== 2 of 3 ==
Date: Fri, Feb 14 2014 7:35 am
From: James Kanze
On Saturday, 1 February 2014 22:36:06 UTC, Victor Bazarov wrote:
[...]
> I would not be surprised at the validity of this after I've learned that
> initializing a reference by dereferencing a null pointer is now legal.
> *nullptr creates a special kind of reference, and the only useful
> operation you can do with it is to take its address, which in turn
> should give you null, as I understand it.
Just curious, but where did you get this information from?
I can't find it in the standard (looking in the obvious places,
which isn't always enough).
--
James
== 3 of 3 ==
Date: Fri, Feb 14 2014 8:12 am
From: Victor Bazarov
On 2/14/2014 10:35 AM, James Kanze wrote:
> On Saturday, 1 February 2014 22:36:06 UTC, Victor Bazarov wrote:
> [...]
>> I would not be surprised at the validity of this after I've learned that
>> initializing a reference by dereferencing a null pointer is now legal.
>> *nullptr creates a special kind of reference, and the only useful
>> operation you can do with it is to take its address, which in turn
>> should give you null, as I understand it.
>
> Just curious, but where did you get this information from?
> I can't find it in the standard (looking in the obvious places,
> which isn't always enough).
I can't give you the exact source, unfortunately, and I am sorry. All I
can remember is that it was mentioned here, discussed in some thread,
and at the time my claim of undefined behavior of initializing a
reference by dereferencing a null pointer was contradicted, and upon
investigating I found that the lvalue to rvalue conversion that used to
be necessary and was the cause of the UB in such a case was not any
longer a requirement (or it was that I incorrectly remembered that
conversion was needed). And in a blink of an eye, so to speak, UB was
not there anymore.
I'm likely too gullible when C++ is concerned. Next you're going to
tell me that atoi is not a standard function, and I'll believe it. :-)
V
--
I do not respond to top-posted replies, please don't ask
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en
To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment