Thursday, July 6, 2017

Digest for comp.lang.c++@googlegroups.com - 9 updates in 2 topics

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 06 02:17AM +0200


> Is this what you mean by using auto:
 
> ::std::unique_ptr<auto> { new T}
 
> ?
 
I didn't think of that. Maybe the author(s) propose that. I was thinking
 
auto p = unique_ptr{ new T };
 
I'm sorry to have responded in an ungood way for the second time now.
 
If we ever should meet you are free to laugh derisively at me for a
period of your choosing, not exceeding 13 minutes.
 
 
 
> :std::unique_ptr request{new cmw_request(recbuf)};
 
> . Professor Spertus saw my code and didn't say, "Hey,
> you need to add auto ..."
 
Yeah. See above. (－‸ლ)
 
 
Cheers!,
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: Jul 06 03:16PM -0700

On Tuesday, 4 July 2017 19:40:22 UTC+3, Dombo wrote:
 
> I rarely use 'new' in C++ code and I cannot remember that last time I
> used malloc() in C++ code, so I wonder why someone would ask how to use
> malloc() in a C++ newsgroup?
 
 
The differences of malloc compared to new[] (used for allocating raw
uninitialized buffer of bytes) are that it does not throw,
and that with malloc the buffer may be further resized using realloc.
These differences may give some benefit or not, it is always situational.
"Öö Tiib" <ootiib@hot.ee>: Jul 06 03:55PM -0700


> auto request=::std::make_unique<cmw_request>(recbuf);
 
> in C++ 2017. Support for this isn't widely available
> yet, though, from what I can tell.
 
I don't know if we need multiple different ways to express exactly
same thing.
Manfred <noname@invalid.add>: Jul 06 04:30PM +0200

On 7/5/2017 8:23 AM, Christiano wrote:
 
> The stroustrup code works.
It works in many (most, all?) implementations that are available today,
but still IMHO there is a flaw of robustness with respect to formal
requirements of the standard:
The problem is before the test (this == nullptr); in:
T* p = nullptr;
f->foo();
 
here -> is /formally/ dereferencing the pointer, even if implementations
may not access the referenced memory location until there is a /data/
access (as opposed to member function call).
I think it is a pity that the standard is not more explicit about the
formal specification of pointer dereference for member function calls.
This may lead to problems like the one that Peter Koch has reported
about clang.
 
It may be interesting to note that the technique is quite common at
least in one implementation - notably MFC: here the test if(this ==
NULL) is very common (e.g. GetSafeHwnd()), /but/ here it is essential
that MFC is delivered together with VC++, so Microsoft is in full
control of the compiler as well, i.e. /how/ this code is compiled.
 
 
The Link is defined as:
 
[...]
> Link* insert(Link* n) ; // insert n before this object
 
> It is not a POD.
 
> In C programming, it is common the following code:
 
The reference to C is interesting in another sense:
A C translation of the insert() method above would be:
 
struct Link* insert(struct Link* thisLink, struct Link* n);
 
Here thisLink (which would play the role of the this pointer above) is
/explicitly/ an argument to insert(), so the C standard would give full
guarantee of how and when it would be dereferenced, and:
 
struct Link* p = NULL;
p = insert(p, n); // n is a struct Link*
 
would be perfectly legal.
This is the main difference the C and C++ implementation with respect to
a null this pointer.
By the way, recalling the above about MFC, the VC++ documentation
describes the 'this' pointer as a 'hidden argument' to nonstatic member
functions.
I think that it is such a description of 'this' as a hidden argument
that Bjarne had in mind when he wrote the OP code, but, the way I
understand it, the standard uses different wording.
 
> p = (*p).insert(new Link{"Athena"});
> The same thing: when compiler is generating code, this line actually
> doesn't need to generate code that access *p at all. [...]
This is not clearly guaranteed by the standard (I would love to be
proven wrong), and the fact that an implementation does not /need/ to
access *p does not mean that an implementation is /forbidden/ to access *p.
 
> Therefore comparing "this" with "nullptr" should be recognized as a
> technique.
Not with the current standard, I think.
Manfred <noname@invalid.add>: Jul 06 05:01PM +0200

On 7/6/2017 4:30 PM, Manfred wrote:
> I think that it is such a description of 'this' as a hidden argument
> that Bjarne had in mind when he wrote the OP code, but, the way I
> understand it, the standard uses different wording.
 
In fact the standard says (n4618 9.2.2.1): "the keyword this is a
prvalue expression whose value is the address of the object for which
the function is called"
Which would imply that an object /is/ present at 'this' address, which
in turn rules out nullptr.
peter koch <peter.koch.larsen@gmail.com>: Jul 06 08:28AM -0700

Den torsdag den 6. juli 2017 kl. 16.31.00 UTC+2 skrev Manfred:
> The problem is before the test (this == nullptr); in:
> T* p = nullptr;
> f->foo();
 
It does not "work" in many implementations today. Actually, I do not see it working on any. Just try it out on godbolt.org - remember to compile with optimisations on.
> formal specification of pointer dereference for member function calls.
> This may lead to problems like the one that Peter Koch has reported
> about clang.
 
It is not a problem, and I did not intend it to be reported as such. Invoking a member function without a valid object is UB. A compiler has ´the right to assume that UB will never happen and thus ignore code that would provoke it.
 
> NULL) is very common (e.g. GetSafeHwnd()), /but/ here it is essential
> that MFC is delivered together with VC++, so Microsoft is in full
> control of the compiler as well, i.e. /how/ this code is compiled.
 
Yes. Microsoft has the right to do whatever it sees fit in case of UB, including given it the meaning some might assume is the natural one. I for one would expect the code to be ignored and a warning printed - just as clang does.
Manfred <noname@invalid.add>: Jul 06 06:52PM +0200

On 7/6/2017 5:28 PM, peter koch wrote:
> Den torsdag den 6. juli 2017 kl. 16.31.00 UTC+2 skrev Manfred:
[...]
>> This may lead to problems like the one that Peter Koch has reported
>> about clang.
 
> It is not a problem, and I did not intend it to be reported as such. Invoking a member function without a valid object is UB. A compiler has ´the right to assume that UB will never happen and thus ignore code that would provoke it.
 
Apologies if I misrepresented your remark (which I think was fully
valid). What I meant with 'problems' was not a problem with clang, but a
problem with the code, that, although from an authoritative source,
would not deliver the expected result on a conformant implementation.
peter koch <peter.koch.larsen@gmail.com>: Jul 06 11:31AM -0700

Den torsdag den 6. juli 2017 kl. 18.52.57 UTC+2 skrev Manfred:
> valid). What I meant with 'problems' was not a problem with clang, but a
> problem with the code, that, although from an authoritative source,
> would not deliver the expected result on a conformant implementation.
 
No need to apologise. I did not believe that you misunderstood me, but just wanted to clarify. Comparing this to null is an abomination, so there should be no confusion here. ;-)
 
 
/Peter
Daniel <danielaparker@gmail.com>: Jul 06 01:18PM -0700

On Tuesday, July 4, 2017 at 10:34:08 PM UTC-4, Richard Damon wrote:
 
> ... this was dropped
 
An unfortunate choice of pronoun!
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)