Wednesday, February 26, 2020

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

cdalten@gmail.com: Feb 26 06:39AM -0800

On Sunday, February 23, 2020 at 6:50:13 AM UTC-8, Bonita Montero wrote:
> > I have posted just a few posts here, don't worry this is my last post in this newsgroup of C++
 
> Go to a doctor.
> You're bipolar and you don't have control over yourself.
 
Hey, I'm bipolar, and I can't control myself when Dan Cross tells me that he is wearing fishnet stockings, but like, I spam every groups all hours of the day. Instead, I just troll comp.lang.c -_-
cdalten@gmail.com: Feb 26 06:53AM -0800


> > Go to a doctor.
> > You're bipolar and you don't have control over yourself.
 
> Hey, I'm bipolar, and I can't control myself when Dan Cross tells me that he is wearing fishnet stockings, but like, I spam every groups all hours of the day. Instead, I just troll comp.lang.c -_-
 
er I DON'T spam. This is because I have this thing known as a job that gets in the way of any attempt at spamming.
queequeg@trust.no1 (Queequeg): Feb 26 09:17AM


> Yes, I would say it is spamming when you swamp a group with hundreds of
> posts that no one is interested in and effectively destroy that group.
 
I guess that every sane poster already has this moron killfiled.
 
--
https://www.youtube.com/watch?v=9lSzL1DqQn0
"Öö Tiib" <ootiib@hot.ee>: Feb 26 01:54AM -0800

On Wednesday, 26 February 2020 11:17:25 UTC+2, Queequeg wrote:
 
> > Yes, I would say it is spamming when you swamp a group with hundreds of
> > posts that no one is interested in and effectively destroy that group.
 
> I guess that every sane poster already has this moron killfiled.
 
Every sane poster should care that people interested in C++ see
walls of non-topical nonsense from Amine Moulay Ramdane
and so go search for some other forum.
cdalten@gmail.com: Feb 26 06:36AM -0800

On Wednesday, February 26, 2020 at 1:17:25 AM UTC-8, Queequeg wrote:
> > posts that no one is interested in and effectively destroy that group.
 
> I guess that every sane poster already has this moron killfiled.
 
> --
 
I didn't add him to my killfile, because for some strange reason, I thought this guy was somehow technically literate. But after I saw him failing to make the distinction between a Vector and a Vector Matrix when talking about a paper that he read on MIT, I came to the conclusion that the guy isn't even that literate.
 
For the non Math people that roam here, in general a vector remains invariant under a transformation whereas the components of the vector components aren't. And as far I understand things, the reason why both a vector and a vector matrix are sometimes uses interchangeably is because both appear to be the same when the basis of the vector spaces are all at 90 degrees?. Ie, orthonormal?
 
I guess I thought Ramine, the guy claims to know all this stuff, and like, reads all these research papers, would have been slightly aware of this subtle but important distinction.
James Kuyper <jameskuyper@alumni.caltech.edu>: Feb 26 09:43AM -0500

On 2/26/20 4:54 AM, Öö Tiib wrote:
...
> Every sane poster should care that people interested in C++ see
> walls of non-topical nonsense from Amine Moulay Ramdane
> and so go search for some other forum.
 
Is there anything that you or any of the rest of us can do to change
this? If so, please do (and let me know too - I'd like to help). If not,
there's not much point in getting upset about it.
cdalten@gmail.com: Feb 26 06:46AM -0800

On Wednesday, February 26, 2020 at 6:43:33 AM UTC-8, James Kuyper wrote:
 
> Is there anything that you or any of the rest of us can do to change
> this? If so, please do (and let me know too - I'd like to help). If not,
> there's not much point in getting upset about it.
 
I don't know if you also have me blocked, but he has had a few of his accounts suspended for "abuse". The problem is that he gives in a rest for like maybe 12 hours. After that, he creates a new account and just starts up again.
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Feb 25 11:08PM -0500

Chris Vine wrote:
> * there is no smaller array object that satisfies these constraints.
 
> The way you create an object in storage associated with another object
> of array type is with placement new.
 
I think we are fully on the same page about using placement new.
 
All I am saying is that I do not see how the Standard allows using
reinterpret_cast (in this case, from the pointer to e or its first element) to
obtain the pointer to that complete object (created by the placement new).
Melzzzzz <Melzzzzz@zzzzz.com>: Feb 26 05:03AM


> All I am saying is that I do not see how the Standard allows using
> reinterpret_cast (in this case, from the pointer to e or its first element) to
> obtain the pointer to that complete object (created by the placement new).
 
Without that you couldn't implement allocator in C++...
 
--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Feb 26 12:54AM -0500

Chris Vine wrote:
> seems to me that you are just plucking this out of the air. Leaving
> aside std::launder, this is very well established code. If it didn't
> work
I am not saying it does not work. I am saying the behavior of this code is not
specified by the Standard. I am not alone at this either. If you can deduce from
the Standard that this code is well defined, I am very eager to know your deduction.
 
> there would be no point in having placement new (you couldn't use
> it in uninitialized memory returned by std::malloc() or operator new()
> either).
Why? You can use it in at least the following ways:
 
1. Placement operator new, as any other, returns a pointer to the object created
(see 7.6.2.7-5) -- you can use the return value.
2. Placement operator new can be used as in the example from the Standard for
launder I cited -- to create an object in a space occupied by an object of a
similar type to which you already hold a pointer. Then you can continue using
that pointer to access the new object, often directly and sometimes you will
have to use it via std::launder (under the conditions well described by the
Standard).
3. Placement operator new can be used to initialize a member (including that of
a union) or an array element of similar type and that member can then be accessed.
 
There may be other well-defined uses, too -- I am not claiming that the above
list is exhaustive.
 
> is concerned with the preconditions to using std::launder (which would
> be met here) and the effects thereof, but not with the circumstances in
> which §6.8/8 of C++17 requires the use of std::launder.
 
I disagree. I apologize, I do not have the 2017 standard, only C++20 draft n4849
so my numeration is different from yours. I completely cited the description I
have in the previous post. There the preconditions are specified in a
(normative) paragraphs 17.6.4-1 and 2 and the explanation on why you might use
it is in (non-normative) Note in 17.6.4-5. The (non-normative) example 17.6.4-6
fully agrees with the text of the Note.
 
I think that I correctly match the requirements you refer to paragraph 8 of
6.7.3 Lifetime in n4849., namely these 4 conditions (8.1 - 8.4) that I think are
well covered by the example from the launder spec I copied to my previous post;
also the example below those conditions seems to confirm my conclusions):
 
8 If, after the lifetime of an object has ended and before the storage which the
object occupied is reused or
released, a new object is created at the storage location which the original
object occupied, a pointer that
pointed to the original object, a reference that referred to the original
object, or the name of the original
object will automatically refer to the new object and, once the lifetime of the
new object has started, can be
used to manipulate the new object, if:
(8.1) — the storage for the new object exactly overlays the storage location
which the original object occupied,
and
(8.2) — the new object is of the same type as the original object (ignoring the
top-level cv-qualifiers), and
(8.3) — the original object is neither a complete object that is const-qualified
nor a subobject of such an object,
and
(8.4) — neither the original object nor the new object is a
potentially-overlapping subobject (6.7.2).
 
[Example:
 
struct C {
int i;
void f();
const C& operator=( const C& );
};
const C& C::operator=( const C& other) {
if ( this != &other ) {
this-> ~ C(); // lifetime of *this ends
new (this) C(other); // new object of type C created
f(); // well-defined
}
return *this;
}
 
C c1;
C c2;
c1 = c2; // well-defined
c1.f(); // well-defined; c1 refers to a new object of type C
 
 
— end example]
 
 
please note that launder is nowhere to be found and the comments say that the
code using new object is well-defined. All I am trying to say that the
conditions for the pointer to the old object to be valid for accessing the new
object are quite broad and the launder was introduced to allow compiler
optimizations in cases when it cannot easily determine that the object may have
been replaced.
 
 
> i. By virtue of the implicit decay of arrays to pointers, is the array
> name, when combined with the pointer arithmetic used in accessing array
> members, a "pointer that pointed to the original object".
I believe so.
 
> ii. If so, does it cease to be so if (as above) the type of the buffer
> element type (std::byte) is different from the type constructed in it
> by placement new (type Y)?
I believe so. After the new object of type Y is created, the old object (e.g an
array of bytes is gone. The pointer to the old object, however, still represents
"the address of the storage location" that the old object occupied -- until the
storage is released and can be used in limited ways as explained in paragraph 6
ibid (e.g. "using the pointer as if the pointer were of type void* is
well-defined").
> for the first time? (On the face of it §6.8/8 is concerned with
> constructing a replacement object in initialized memory after the
> lifetime of the previous object has ended).
 
I think you are correct. The whole purpose of paragraph 8 seems to be to define
when one can use a pointer or reference to or the name of the original object --
and there is no original object if the memory is uninitialized. I think the
paragraph 6 specifies what can be done with / is guaranteed for the pointer to
uninitialized memory.
Juha Nieminen <nospam@thanks.invalid>: Feb 26 08:18AM

> you, or because they think other languages are better in other ways, is
> difficult to say. Probably factors such as garbage collection,
> developer support and type safety are also relevant.
 
In my own professional experience demand for modern C++ expertise has been
raising. This is particularly, and curiously, so especially in embedded
development, of all things.
Maciej Sobczak <see.my.homepage@gmail.com>: Feb 26 12:56AM -0800

> And the relative use of C++ in projects has dropped in the past 20
> years also.
 
The interesting part in this observation is the word "relative".
But do you have any data (I don't) on *absolute* numbers?
Because the fact that other technology niches emerged in the mean time, with their own technologies, does not necessary mean that the demand for C++ diminishes.
It might also be the case that infrastructure development (which is a natural domain of C++) is concentrating in the hands of few big companies. So that C++ becomes a technology for Googles and Facebooks, but not necessarily for the average man-and-his-dog startup. So the social coverage of C++ my be changing, but not necessarily the total numbers.
Of course, it's difficult to get the actual data.
 
> you, or because they think other languages are better in other ways, is
> difficult to say. Probably factors such as garbage collection,
> developer support and type safety are also relevant.
 
My impression is that on a mass scale, such technical issues are not decision factors. People are writing Android apps in Java (or whatever they are writing in this week) not because of their careful and well-informed considerations of UB and GC, but because this is what this whole ecosystem is pushing on them. They didn't choose Java as a language, but they chose Android as a target.
 
I agree with Juha's other comment about the curiously rising presence of C++ in the embedded domain. At least all hardware vendors provide C++-capable development environments to enable such mainstream adoption and with the exploding functionality of embedded devices (everything is IoT, AI, and whatnot) this might be just unavoidable. Which is certainly good for the C++ community.
 
--
Maciej Sobczak * http://www.inspirel.com
Jorgen Grahn <grahn+nntp@snipabacken.se>: Feb 26 09:14AM

On Wed, 2020-02-26, Maciej Sobczak wrote:
...
 
> mainstream adoption and with the exploding functionality of embedded
> devices (everything is IoT, AI, and whatnot) this might be just
> unavoidable. Which is certainly good for the C++ community.
 
Yes. I don't see what's curious about it though: C++ is a drop-in
replacement for C from a runtime perspective.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Öö Tiib" <ootiib@hot.ee>: Feb 26 01:47AM -0800

On Wednesday, 26 February 2020 10:18:27 UTC+2, Juha Nieminen wrote:
 
> In my own professional experience demand for modern C++ expertise has been
> raising. This is particularly, and curiously, so especially in embedded
> development, of all things.
 
I have observed same thing. Hiring C++ programmers has became
hard. Can be that the schools prepare less of them.
Can be that C++ has became too complex to learn on your own.
Can be tendency of equipment manufacturers to make IOT
(or outright web servers) into their embedded equipment while
being resistant to increase bills of materials.
Can be raise in usage of hand-held stuff and battery life of such.
Can be the hipster culture of people wanting to have
special, customized precisely matching their personality.
Can be more effort needed against platform providers artifically
causing issues against usage of C++. Can be that the modern
snow-flake people just are useless as engineers.
Whatever it is, hiring at least half-decent C++ programmers has
became all harder and harder.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Feb 26 12:57PM

On Tue, 25 Feb 2020 23:08:18 -0500
 
> All I am saying is that I do not see how the Standard allows using
> reinterpret_cast (in this case, from the pointer to e or its first element) to
> obtain the pointer to that complete object (created by the placement new).
 
I do not see how you think the standard does not allow using
reinterpret_cast in this case.
 
The standard provides that an object pointer can be converted to an
object pointer of a different type using reinterpret_cast. Leaving
aside lifetime issues involving std::launder, the problem with doing so
is two-fold. First it might result in incorrect alignment. Secondly it
might break C++'s aliasing rules by type punning. Neither occurs here.
alignas is used so alignment is correct. And there is no type punning:
there is an object of type Y (as created by placement new) at the
address in question. There would be type punning if you tried to use
the std::byte array to access the Y object without a reinterpret_cast,
say to examine individual bytes of the object, although as it happens
that is type punning which is blessed by the standard - §6.10/8.8 of
C++17.
 
You seem to have something wrong with your mental picture of this.
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Feb 26 01:07AM -0500

Chris M. Thomasson wrote:
>> 2023 when it really does not matter :-).
 
> Fwiw, what I get from the talk is that its better have a ctor and dtor, or else
> its undefined regardless?
My understanding of it was that the object should be created so constructor
should be called as part of that (the constructor implicitly defined by the
implementation should do, too) before using it (to put it in another way, no
amount of pointer casting and arithmetic will help to make the code using the
resulting pointer well defined if an object to which the pointer is trying to
point is not created)
Tim Rentsch <tr.17687@z991.linuxsc.com>: Feb 25 04:14PM -0800


>> Why not just this? (size_t)-1 /2 +1
 
> Because I didn't think of it before you posted
> it, Tim. :-)
 
Thank you for that Dan. It's good to see you back
in the newsgroups again.
cdalten@gmail.com: Feb 25 06:18PM -0800

Since Dan Cross has me blocked because I called him out for the wife beater that he is, let me try to fill you in on my Cross has been MIA.
 
Background. Dan is a Math guy who used to serve in the USMC. At the time he was dating some Russian woman. They broke up because he got tired of her being the "man" in the relationship. Now let's fast forward. He found some chick from the Gaza Strip that was desperate enough to date him. They've stuck together because she let's him be the man in the relationship. They even have a kid! He also likes the fact that he can beat his gf. Whereas with the Russian woman, well, everytime that he got pissed off, she basically beat his ass. This despite that fact that he was in the USMC!
 
These days he spends a lot of time on arbornet.org and grex.org. He goes under the name of cross on both of these sites. He prefers to hang out there because both systems are dominated by fat, middle aged, balding white men. He talks to the menz on these sites all the time just in case his current girlfriend finds a real man. Why? So he could date one of these guys!!!
 
Dan Cross isn't getting any younger. It's now getting to the point where he will settle down with anything on two legs. This could be male, female, or shemale.
cross@spitfire.i.gajendra.net (Dan Cross): Feb 26 02:22AM

In article <86tv3e9pc4.fsf@linuxsc.com>,
>> it, Tim. :-)
 
>Thank you for that Dan. It's good to see you back
>in the newsgroups again.
 
Thanks, Tim! It's nice to be reading.
 
- Dan C.
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)