Friday, January 20, 2023

Digest for comp.lang.c++@googlegroups.com - 23 updates in 4 topics

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 20 01:52AM -0800

On 1/19/2023 5:02 AM, Sebastian Nibisz wrote:
> Fifteen years have passed ;-).
> The SGCL has a completely new, portable, working implementation with less memory overhead than shared_ptr: https://github.com/pebal/sgcl
 
How does it compare to RCU wrt read mostly, write rarely workloads?
Sebastian Nibisz <snibisz@gmail.com>: Jan 20 03:28AM -0800

piątek, 20 stycznia 2023 o 10:52:34 UTC+1 Chris M. Thomasson napisał(a):
> > Fifteen years have passed ;-).
> > The SGCL has a completely new, portable, working implementation with less memory overhead than shared_ptr: https://github.com/pebal/sgcl
> How does it compare to RCU wrt read mostly, write rarely workloads?
Performance is close to RCU for reads and better for writes. Atomic reads and writes are much faster. Pointer construction is slower, but this time is amortized by other operations.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 20 12:26PM -0800

On 1/20/2023 3:28 AM, Sebastian Nibisz wrote:
>>> The SGCL has a completely new, portable, working implementation with less memory overhead than shared_ptr: https://github.com/pebal/sgcl
>> How does it compare to RCU wrt read mostly, write rarely workloads?
> Performance is close to RCU for reads and better for writes. Atomic reads and writes are much faster. Pointer construction is slower, but this time is amortized by other operations.
 
That's great! Btw, are you familiar with proxy collectors? Afaict, they
were invented by Joe Seigh, a friend of mine from long ago over on
comp.programming.threads. I did one a while back:
 
https://groups.google.com/g/comp.lang.c++/c/FBqOMvqWpR4/m/gfFd4J2GBAAJ
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 20 12:39PM -0800

On 1/20/2023 3:28 AM, Sebastian Nibisz wrote:
>>> The SGCL has a completely new, portable, working implementation with less memory overhead than shared_ptr: https://github.com/pebal/sgcl
>> How does it compare to RCU wrt read mostly, write rarely workloads?
> Performance is close to RCU for reads and better for writes. Atomic reads and writes are much faster. Pointer construction is slower, but this time is amortized by other operations.
 
I am assuming that your work can allow one to create a lock-free stack
without having to worry about the ABA problem. Is that correct?
Muttley@dastardlyhq.com: Jan 20 03:48PM

On Thu, 19 Jan 2023 19:22:12 +0100
>Usenet server mixup somewhere.) So I believe Bonita merely quoted it.
 
>I have no idea if someone intentionally posted it in your name, or if
>that too was part of the server fault.
 
Quoting is done by the client and can easily be modified by the user. I can't
see how a server fault fault would cause it tbh.
Muttley@dastardlyhq.com: Jan 20 03:49PM

On Thu, 19 Jan 2023 20:17:33 -0000 (UTC)
>> paganini.bofh.team I see it as coming from Ilya Shambat. What do you
>> mean "it came as from Muttley" ?
 
>And I see the same using news.aioe.org .
 
You think I'm the only person who uses that server?? Idiot.
Spiros Bousbouras <spibou@gmail.com>: Jan 20 05:21PM

On Fri, 20 Jan 2023 15:49:08 -0000 (UTC)
> >> mean "it came as from Muttley" ?
 
> >And I see the same using news.aioe.org .
 
> You think I'm the only person who uses that server?? Idiot.
 
This is a non sequitur response for several reasons. Either someone is
impersonating you (Muttley@dastardlyhq.com) with the intention of making you
look irrational or you completely misinterpreted my posts you are quoting and
I can't even imagine what interpretation would make your reply make sense.
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Jan 20 11:35AM -0800

Background:
A message was posted to rec.arts.books titled "Change and Choice" with the following headers:
From: Ilya Shambat <ibshambat@gmail.com>
Date: Thu, 19 Jan 2023 01:42:00 -0800 (PST)
 
Bonita Moreno posted a reply to that message to comp.lang.c++ titled "Re: Compute Unique Numbers in a Set" saying:
 
Am 19.01.2023 um 10:31 schrieb Muttley@dastardlyhq.com:
 
followed by a quotation of the entire "Change and Choice" message. Regardless of what time zone Bonita was using, that attribution line can't refer to the same time as the message she was quoting.
 
You said you never wrote such a thing. David Brown responded by suggesting that a Usenet server mixup was responsible for posting something to the wrong newsgroup. But that doesn't explain Bonita's change of the Subject: header, nor her citation of the wrong time and wrong author when quoting that message.
 
> >> Using news2.informatik.uni-stuttgart.de or
> >> paganini.bofh.team I see it as coming from Ilya Shambat. What do you
> >> mean "it came as from Muttley" ?
 
Text written by Spiros was snipped, which confirmed that he saw the same message, with Ilya Shambat as the author, on several different usenet servers, then he listed one more:
 
> >And I see the same using news.aioe.org .
> You think I'm the only person who uses that server?? Idiot.
 
I don't see how your response makes any sense in that context. Bonita and Red Floyd are the only ones who've suggested that you were responsible for that original message. David and Spiros believe it was posted by Ilya Shambat. The fact that it was visible on many different servers, including news.aioe.org, always with Ilya Shambat given as the author, was cited as evidence against a server error being the cause of Bonita's mis-attribution of the quoted text. That fact was not being used to argue that you must have been the author, so the fact that other people use that server is not relevant.
Muttley@dastardlyhq.com: Jan 20 04:19PM

I've found that with the std::byte type of C++ 17 it seems it'll only
be constructed with {<value>} which is not an initialiser list. Eg:
 
fenris$ cat t.cc
#include <cstddef>
 
using namespace std;
 
int main()
{
std::byte b{123};
std::byte c(123);
std::byte d({123});
}
fenris$ c++ -std=c++17 t.cc
t.cc:8:12: error: cannot initialize a variable of type 'std::byte' with an
rvalue of type 'int'
std::byte c(123);
^ ~~~
t.cc:9:12: error: cannot initialize non-class type 'std::byte' with a
parenthesized initializer list
std::byte d({123});
^ ~~~~~
2 errors generated.
 
So if the constructor parameter is not a simple rvalue - templated or not - or
an intialiser list then what the hell is it?
Bo Persson <bo@bo-persson.se>: Jan 20 05:25PM +0100

> 2 errors generated.
 
> So if the constructor parameter is not a simple rvalue - templated or not - or
> an intialiser list then what the hell is it?
 
It is a "list initialization" that specifically works for enumerations,
like enum class byte.
 
https://en.cppreference.com/w/cpp/language/enum#enum_relaxed_init_cpp17
Muttley@dastardlyhq.com: Jan 20 04:44PM

On Fri, 20 Jan 2023 17:25:36 +0100
 
>It is a "list initialization" that specifically works for enumerations,
>like enum class byte.
 
>https://en.cppreference.com/w/cpp/language/enum#enum_relaxed_init_cpp17
 
So its enumerated 0-255? Whats the point when a compiler will warn you if
you try to assign a too large or negative value to a uint8_t anyway?
Another C++17 solution looking for a problem IMO.
 
Thanks anyway.
red floyd <no.spam.here@its.invalid>: Jan 19 03:25PM -0800

On 1/19/2023 1:33 PM, fir wrote:
> child->print();
> return 0;
> }
 
The nullptr response from dynamic cast is correct, because child doesn't
point to a Child, it points to a Parent. dynamic cast realizes this
and returns nullptr.
fir <profesor.fir@gmail.com>: Jan 19 03:35PM -0800

piątek, 20 stycznia 2023 o 00:25:51 UTC+1 red floyd napisał(a):
> The nullptr response from dynamic cast is correct, because child doesn't
> point to a Child, it points to a Parent. dynamic cast realizes this
> and returns nullptr.
 
okay, tnx for answers... overally its emo problem not mine
Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Jan 19 11:38PM

On 19/01/2023 21:33, fir wrote:
> child->print();
> return 0;
> }
 
parent points to a Parent object, which is NOT a Child object: there is NO CHILD COMPONENT of the
object is your code. The dynamic_cast<Child*> is attempting to obtain the corresponding Child*
pointer for the object, but as the object is NOT a Child, the cast returns null. You should check
the value after the dynamic_cast before using it!
 
The NULL value is returned in both scenarios, i.e. regardless of whether print() is virtual.
 
In the scenario where print has been declared virtual, child->print() will call the /virtual/
function print() for the object, which is accessed through the virtual function table at the
beginning of the object. Since child is null, this will result in an access violation.
 
If print is not virtual, then child->print() will call the print() function appropriate for a Child
object, which is the Parent::print() method it inherits from the Parent base class. The compiler
knows where that is in memory, so it just calls that method. In your example when that method gets
called, its 'this' pointer will be null, WHICH IS INVALID!! However, it 'works' because nothing in
the method uses the 'this' pointer , i.e. nothing accesses any Parent member variables. If you
changed Parent::print() to access some member variable then we would get some kind of access
violation again.
 
So the problem is you're trying to access Child objects, but nowhere have you actually created any
Child object in your program! And you're ignoring the dynamic_cast return value which obscures the
problem.
 
Possibly what you wanted to do was create a Parent* pointer to a Child object, then cast that to get
a Child* pointer:
 
Parent* parent = new Child(); // note, we create a Child, not a Parent
Child * child = dynamic_cast<Child*>(parent); // ..so now this cast works regardless of whether
child->print(); // print() is virtual
 
If print() is declared virtual, child->print() will call the print method appropriate for the Child
class - but that is the inherited Parent::print() method! So perhaps Emo does not understand the
purpose of the virtual keyword... To reveal the difference, we need to make an example where both
the Parent and Child classes have their own version of the print() method, and look at how
parent->print() and child->print() behave:
 
class Parent
{
public:
Parent(){}
virtual void print(){ std::cout << "parent " << "\n"; }
virtual void pt(){ }
};
 
class Child : public Parent
{
public:
Child(){}
virtual void print(){ std::cout << "child " << "\n"; }
};
 
int main(int argc, char const *argv[])
{
// Child* old_child = parent; // how to do this??
 
Parent* parent = new Child();
Child * child = dynamic_cast<Child*>(parent);
 
parent->print();
child->print();
return 0;
}
 
Since the methods above are virtual, the parent->print() and child->parent() calls both call the
Child::print() method, because the object involved is created as a Child object.
 
If we removed the virtual keywords, the parent->print() would call the Parent::print() method, and
child->parent() method would call the Child::print() method. (i.e. based on the types of *parent
and *child.)
 
Regards,
Mike.
fir <profesor.fir@gmail.com>: Jan 19 03:39PM -0800

piątek, 20 stycznia 2023 o 00:25:51 UTC+1 red floyd napisał(a):
> The nullptr response from dynamic cast is correct, because child doesn't
> point to a Child, it points to a Parent. dynamic cast realizes this
> and returns nullptr.
 
emo answered:
 
<Emo>
00:34 ale to sie nie odnosi dlaczego ten keyword virtual powoduje crash
 
but it doesn't address why this keyword virtual is cousing crash
 
(without virtual the cast is also logically invalid but there is no crash)
fir <profesor.fir@gmail.com>: Jan 19 04:00PM -0800

piątek, 20 stycznia 2023 o 00:38:25 UTC+1 Mike Terry napisał(a):
> On 19/01/2023 21:33, fir wrote:
> > i do not touch c++ (which i name kuc++) so i dont know the answer
 
> knows where that is in memory, so it just calls that method. In your example when that method gets
 
 
does nor ut yeild to conclusion that dynamic cast where virtuial is used return null but when is not used dont return null but passes the pointer? if so why is that?
fir <profesor.fir@gmail.com>: Jan 19 04:10PM -0800

piątek, 20 stycznia 2023 o 00:38:25 UTC+1 Mike Terry napisał(a):
> If print() is declared virtual, child->print() will call the print method appropriate for the Child
> class - but that is the inherited Parent::print() method! So perhaps Emo does not understand the
 
overally i think emo overlooked that you cant cast base to derived.. i also ovverlooked this as im tired and this is not my problem.. this explaind why its
bad, though she also would like to understand the details
 
(for me personally its not much importand as i find all thet inheritance bad.. i use c normally and c is 'physical' language..if i want to do such things i use
separate arrays for each typenot put things in one bag... in turn when someone would do that abstract way they should do it fully abstract. like say int and float has some common anstract denominator but iut cant be expressed in a form of c++ ingeritance.. c++ uses a bit of physical attempt mixed with a bit of abstract and it is not good solution imo - but it is side topic here)
Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Jan 20 12:19AM

On 20/01/2023 00:00, fir wrote:
>>> i do not touch c++ (which i name kuc++) so i dont know the answer
 
>> knows where that is in memory, so it just calls that method. In your example when that method gets
 
> does nor ut yeild to conclusion that dynamic cast where virtuial is used return null but when is not used dont return null but passes the pointer? if so why is that?
 
No - in both cases dynamic_cast returns null, because its argument (parent) does not point to a
Child object. The different behaviour between virtual/not virtual keyword is because virtual causes
the null value to be dereferenced, in order to look up the objects virtual function table to find
the right print() function to call. Dereferencing null gives the access violation. If virtual is
not specified, the compiler does not use the object's virtual function table, because it already
knows which print() function to call and the address of that print function. So the null value is
never dereferenced in this case and there is no access violation, although the code is still incorrect.
 
To see this you could just step through the code in a debugger and verify that child is null in both
scenarios. Or add something to print the value of child after the cast...
 
Mike.
Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Jan 20 12:24AM

On 20/01/2023 00:10, fir wrote:
>> class - but that is the inherited Parent::print() method! So perhaps Emo does not understand the
 
> overally i think emo overlooked that you cant cast base to derived.. i also ovverlooked this as im tired and this is not my problem.. this explaind why its
> bad, though she also would like to understand the details
 
It is ok to cast from the base class to a derived class - BUT IT ONLY WORKS IF THE BASE CLASS
POINTER ACTUALLY POINTS TO AN INSTANCE OF THE DERIVED CLASS. In your code, parent does not point to
an instance of Child, so null is returned.
 
I hope she would be able to follow the explanation I originally gave. If not she could ask more
questions here. :)
 
 
Mike.
fir <profesor.fir@gmail.com>: Jan 19 04:34PM -0800

piątek, 20 stycznia 2023 o 01:19:40 UTC+1 Mike Terry napisał(a):
> never dereferenced in this case and there is no access violation, although the code is still incorrect.
 
> To see this you could just step through the code in a debugger and verify that child is null in both
> scenarios. Or add something to print the value of child after the cast...
 
buy yjere is such line in this code
 
child->print();
 
toy say it call print methid even if child is NULL ? if so its quite new to me
Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Jan 20 01:36AM

On 20/01/2023 00:34, fir wrote:
 
> buy yjere is such line in this code
 
> child->print();
 
> toy say it call print methid even if child is NULL ? if so its quite new to me
 
Yes, when the print() method is not virtual, the compiler knows which method to call just based on
the types used in the expression. In this case child is declared as type Child*, so 'child->' tells
the compiler that the print method is for the Child class - or its base class if Child does not have
its own print method. So here it will generate code to call Parent::print. The child-> term also
tells the compiler to set the 'this' pointer within the method to the value of child, which is null,
but if the 'this' pointer is not used (i.e. no object members accessed) you might get away with it.
Or you might not, it depends on the compiler generated code.
 
If Parent were like this:
 
class Parent
{
public:
Parent(){}
virtual void print(){ std::cout << "parent" << num << "\n"; }
virtual void pt(){ }
 
int num = 7;
};
 
then the printing of member variable 'num' would try to dereference the null 'this' pointer and
generate an access violation of some kind.
 
Anyway, it's Wrong to call child->print(); if child is null. Even if it apparently works correctly
with a given compiler...
 
Mike.
fir <profesor.fir@gmail.com>: Jan 20 12:53AM -0800

piątek, 20 stycznia 2023 o 02:37:09 UTC+1 Mike Terry napisał(a):
 
> Anyway, it's Wrong to call child->print(); if child is null. Even if it apparently works correctly
> with a given compiler...
 
> Mike.
shocking...ok emo praised this group, .. maybe we will get back in some future..tnx (i stick to c but emo uses qt and unreal engine)
Paavo Helde <eesnimi@osa.pri.ee>: Jan 20 01:24PM +0200

20.01.2023 01:39 fir kirjutas:
> 00:34 ale to sie nie odnosi dlaczego ten keyword virtual powoduje crash
 
> but it doesn't address why this keyword virtual is cousing crash
 
> (without virtual the cast is also logically invalid but there is no crash)
 
Undefined behavior is undefined and can do anything. If it was
guaranteed crash, it would be a defined behavior.
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)