Friday, February 24, 2017

Digest for comp.lang.c++@googlegroups.com - 14 updates in 10 topics

"Öö Tiib" <ootiib@hot.ee>: Feb 24 02:59PM -0800

On Friday, 24 February 2017 21:52:16 UTC+2, Paul wrote:
> Because I did well enough on the other questions, I have now been
> invited back for a second interview, and I think they may test
> how much I've learned in the meantime.
 
If you just need an implementation then I trust the CString of microsoft
ATL / MFC is copy-on-write.
 
If you need idea about its usefulness then it seems that CoW is not too
good in multi-threaded program and can cause major hidden performance
hit there. Most programs written nowadays are multi-threaded and so CoW
is not too good idea most of the time.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 25 12:28AM +0100

On 24.02.2017 23:59, Öö Tiib wrote:
> Most programs written nowadays are multi-threaded and so CoW
> is not too good idea most of the time.
 
Uhm, thread safety is an orthogonal issue. Adding illusory thread safety
to a string class is going to cost, no matter the internal implementation.
 
I write "illusory" because if one shares a mutable string object between
threads, it would be impractical to lock down the object any time its
`operator[]` returns a reference that possibly could be stored by the
thread and used to modify the string at arbitrary times.
 
The standard library's approach of most classes being thread-agnostic is
fine, I think. It's the responsibility of the code that uses those
classes, to ensure thread safe operation. E.g. by simply not sharing
mutable objects between threads.
 
 
Cheers!,
 
- Alf (opinionated, for the occasion)
Paul <pepstein5@gmail.com>: Feb 24 03:24PM -0800

Does anyone know a good reference for C++ idioms such as copy-on-write, copy-and-swap, RAII, CRTP, PIMPL etc. etc.
 
I noticed this: https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms
 
However, it seems to be exhaustive, without stressing the more common and standard patterns.
 
Thanks,
 
Paul
helpseeker <vijaybhaskar@gmail.com>: Feb 24 02:57PM -0800

On Friday, February 24, 2017 at 3:32:51 AM UTC-8, Paavo Helde wrote:
> if it is a member-declaration."
 
> 9.2/8: "A virt-specifier-seq shall appear only in the declaration of a
> virtual member function."
 
Yes that is what I meant. I am curious why the C++ 14 standard decided to forbid it. I find it useful to easily identify methods that are overridden prompts me to then look into the header file for more details or the base class if needed.
"Öö Tiib" <ootiib@hot.ee>: Feb 24 02:13PM -0800

On Thursday, 23 February 2017 22:10:23 UTC+2, ruben safir wrote:
> > instead of "ptr1 == ptr2"?
 
> that is a good suggestion, but I fixed this a week ago and forgot how I
> fixed it already
 
And also you already deleted the file and so you can't look into it to
figure out how you fixed it.
Paul <pepstein5@gmail.com>: Feb 24 12:49PM -0800

Here is some basic pimpl code below:
I don't understand why this is legal. It seems that class widget{..}
defines widget as a base class.
And then class widget is then redefined as a class privately inheriting
from impl.
Why isn't widget being illegally defined twice?
Also, can someone explain pimpl to me or direct me to a good explanation?
 
Thanks
 
Paul
 
class widget {
public:
widget();
~widget();
private:
class impl;
unique_ptr<impl> pimpl;
};

// in implementation file
class widget::impl {
// :::
};

widget::widget() : pimpl{ new impl{ /*...*/ } } { }
widget::~widget() { }
Ian Collins <ian-news@hotmail.com>: Feb 25 10:48AM +1300

On 02/25/17 09:49 AM, Paul wrote:
> Here is some basic pimpl code below:
> I don't understand why this is legal. It seems that class widget{..}
> defines widget as a base class.
 
Where?
 
> And then class widget is then redefined as a class privately inheriting
> from impl.
 
Where?
 
> Why isn't widget being illegally defined twice?
> Also, can someone explain pimpl to me or direct me to a good explanation?
 
I think you need to explain where your conclusions (above) came from,
the code does not support them.
 
> class widget {
 
No base class...
 
> private:
> class impl;
> unique_ptr<impl> pimpl;
 
Contains a nested impl class, no inheritance.
 
--
Ian
Paul <pepstein5@gmail.com>: Feb 24 02:03PM -0800

On Friday, February 24, 2017 at 9:48:55 PM UTC, Ian Collins wrote:
 
> Contains a nested impl class, no inheritance.
 
> --
> Ian
 
Ok. I get it now. Thanks.
I read it as class widget : private impl {//};
I'm nervous about an upcoming job interview, and
it's affecting my thinking.
 
Paul
Tim Rentsch <txr@alumni.caltech.edu>: Feb 24 01:39PM -0800

> really pointing to the same object, i.e. aliased pointers. The
> standard doesn't call it strict aliasing so I'm not sure how to
> search for it, and I always forget where it is. [...]
 
Like Chris Vine said these rules are in section 3.10 p10. The
rules do not interfere with access through union members, as I
explain below, but let me go on to the individual items.
 
> * The list is not really exhaustive, it has at least one one-way
> reinterpretation.
 
I assume you're talking about the asymmetric rule involving
aggregate or union types. That rule has its origins in the
original C standard. I agree it looks suspicious. Despite that
I believe there are sensible reasons for the asymmetry. In any
case that clause isn't relevant here because the accesses I'm
talking about are through the union's members, never through the
union as a whole.
 
 
> * The reinterpretations supported is where some common part of the
> bitpattern really means the same in the two interpretations,
> e.g. signed versus unsigned interpretation for non-negative integers.
 
That is true for arbitrary accesses, independent of unions. For
example it's okay to access an (unsigned int) using an (int *).
But this sort of thing is not what's happening when accesses
are done through union members. See next.
 
 
> * The reinterpretations of interest via type punning in e.g. a union,
> are generally those not in the strict aliasing rule bullet list.
 
That statement is true, but actually not important. To see why,
consider this picture:
 
+--------+--------+--------+--------+--------+--------+--------+--------+
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
+--------+--------+--------+--------+--------+--------+--------+--------+
<---- u.small ---->
<------------- u.large ------------->
<----------------------------------- u --------------------------------->
 
The region shown as 'u' is a union of 8 bytes. The union type
has two members, 'small' of type uint16_t, and 'large' of type
uint32_t. Suppose we store into u.large and read u.small:
 
u.large = 23;
std::cout << u.small;
 
The type of the lvalue is uint16_t. The dynamic type of the
object being read is the type of the u.small object, which is
also uint16_t. This access is allowed under the first bullet
item of 3.10 p10.
 
To be sure what I just said about dynamic type is true, I read
through the definition of dynamic type, and some other terms like
"object", so as not to be misled. (I hope others will do this
also, to give me a double check.) Because of what region is
accessed and how the access is done, the only candidate object is
u.small, whose dynamic type is uint16_t. That matches the lvalue
type of the access, so we are good to go.
 
I do have a "however" to add to this, please see below.
 
 
> What you quoted seems to be about any reinterpretation at all not
> being permitted in a constant expression.
 
Yes, it definitely is, but that doesn't affect the reasoning. If
reading one member to access a different member-last-written were
undefined behavior under other circumstances there is no reason
to make it undefined behavior under these circumstances. The
dynamic type rules of 3.10 p10 do not interfere with these cases
of union member access, as I have explained above.
 
 
And now for the big "having said that....".
 
I have gone through the various parts of the C++ standard
checking and double checking the reasoning given above. I am
pretty sure the reasoning is sound.
 
However.... Different passages in the C++ standard look a bit
schizophrenic about unions. In some places it looks like unions
"hold" only one object at a time. In other places it looks like
unions always have all their objects - with the understanding that
only one member may be the "active" member, but the other members
are still identified with "regions of memory", which is what an
object is. It's easy to see how different people might reach
different conclusions about what the semantics are in these
cases.
 
In C, the wording regarding unions is more straightforward, and
it's fairly clear what is meant to happen. Moreover, if that
weren't enough, the C standard includes a prominent footnote
which says explicitly that union access through another member
will reinterpret the bits of the member last written. For
whatever reason the C++ standard has chosen to muddy the waters
about how unions are supposed to behave. So I think the best
we can say for sure is that the issue is open to debate, and
the C++ standard deserves a big Defect Report as long as that
is true.
 
I hope you have enjoyed this long explanation and probably
pointless exercise. :)
"Öö Tiib" <ootiib@hot.ee>: Feb 24 12:50PM -0800


> I didn't come up with the idea of backporting:
 
> https://en.wikipedia.org/wiki/Backporting
 
> I don't suggest backporting all of the features, just one or two.
 
C++ specification is not made like those softwares with versions
1.14.3 and 2.3.7 in parallel maintenance and extension AFAIK.
 
There was C++ 2011 standardized and there won't be 2011.0.1 bugfix
release nor 2011.1 extended feature releases of it. It is done.
Defects of 2011 were attempted to address in version 2014. That is
also final. Version 2017 is under development.
"Adam C. Emerson" <azure@fox.blue>: Feb 24 08:13PM

> s->exec();
> }
> };
[snip]
 
This design looks very strange to me. Why do you both inherit from
Stmt and include a pointer to Stmt?
Cholo Lennon <chololennon@hotmail.com>: Feb 24 05:41PM -0300

On 24/02/17 17:13, Adam C. Emerson wrote:
> [snip]
 
> This design looks very strange to me. Why do you both inherit from
> Stmt and include a pointer to Stmt?
 
Because, at 1st glance, it seems like the OP is using the decorator pattern.
 
--
Cholo Lennon
Bs.As.
ARG
Tim Rentsch <txr@alumni.caltech.edu>: Feb 24 12:19PM -0800

>> understanding is that this case is pretty clearcut.
 
> [...] I'm afraid it's increasingly difficult to make money as a
> book author. [...]
 
That's part of the reason I think a "Fair use" exception would be
allowed. The single page made available is unlikely to cause
someone who wants to buy the book not to buy it, but it might
very well convince some people to buy the book who would not have
otherwise. From the author's point of view, the page being
posted is pretty much all free advertsing, with negligible
downside.
"Öö Tiib" <ootiib@hot.ee>: Feb 23 04:40PM -0800

On Monday, 20 February 2017 10:22:36 UTC+2, Andrey Karpov wrote:
> > intrigued when I see the phrase "C/C++ programmers."
 
> I have noticed that there is always some "know-all" who doesn't like C/C++.
 
> C/C++ programmers should be read as C programmers or C++ programmers. I guess nobody gets confused when it is written Java/C# or Java/JavaScript (example: Xx is seeking a Java/JavaScript Engineer for a direct hire position). By analogy, to make the story shorter, a lot of authors, me included, write C/C++, meaning that it is C or C++ language.
 
Java/C# have quite same roots but Java/Javascript? Nonsense connection.
Somewhat worse than C/C++ that have lot more roots in common than
Java/Javascript.
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)