Tuesday, June 16, 2020

Digest for comp.lang.c++@googlegroups.com - 25 updates in 7 topics

rick.c.hodgin@gmail.com: Jun 16 02:15PM -0700

The Bible teaches that in the end-times the entire world will
turn away from God in rebellion, and there is no Biblical
prophesy of end-times revival.
 
This message is spot-on:
 
https://www.youtube.com/watch?v=FQoPmnwI5oY
 
We are seeing the worldwide destruction of our societies in
preparation for the coming tribulation.
 
Come out from the world. Ask Jesus to forgive your sin,
and live in hope and security knowing whose you are, and
where you are going.
 
You are worth being saved. Call upon Jesus and escape the
coming tribulation. Make your future sure. Teach you
family, friends, co-workers, and others in your life.
 
--
Rick C. Hodgin
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 16 12:43PM -0700

On 6/15/2020 9:53 PM, Bonita Montero wrote:
>> If not, then you need to go rouge. Take careful note of the
>> memory_order_acq_rel membar.
 
> I inserted the appropriate fences.
 
Just make double sure to put them in the correct places within the code.
Bonita Montero <Bonita.Montero@gmail.com>: Jun 16 09:53PM +0200

>> I inserted the appropriate fences.
 
> Just make double sure to put them in the correct places within the code.
 
The are in the correct places. I've changed the code a bit because
the fences aren't necessary because the intrinsics have their own
fences. So I have a private fence( mo_t o ) function that selects
per ifdef if we have neither gcc, nor MSVC, i.e. unknown compilers
are assumed to do no fencing on CAS until the code is adpated.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 16 01:23PM -0700

On 6/16/2020 12:53 PM, Bonita Montero wrote:
> fences. So I have a private fence( mo_t o ) function that selects
> per ifdef if we have neither gcc, nor MSVC, i.e. unknown compilers
> are assumed to do no fencing on CAS until the code is adpated.
 
Well, perhaps create a model that can work as if the intrinsic RMW's are
naked, or relaxed if you will. In other words, treating
InterlockedExchangeAdd as if it has no implied memory order. Call it the
working base model for systems with relaxed memory ordering. Akin to
SPARC RMO.
 
It seems like you are always putting the membar after the RMW:
 
example:
_________________________
inline
std::pair<std::uintptr_t, std::uintptr_t>
std::atomic<std::pair<std::uintptr_t, std::uintptr_t>>::exchange( pair_t
desired, mo_t mo )
{
pair_t cmp = m_pair;
while( !cmpxchgPair( m_pair, cmp, desired ) );
atomic_thread_fence( mo );
return cmp;
}
_________________________
 
This is fine for an acquire barrier, but not for release. The release
membar should be _before_ the atomic RMW.
Lynn McGuire <lynnmcguire5@gmail.com>: Jun 16 01:39PM -0500

Hi,
 
Is there a way to have the same method but with a different argument
data type for a single argument ? For instance, the following methods
that I have greatly simplified:
 
class DataItem : public ObjPtr
{
int aAvalueInt;
double aValueDouble;
std::vector <int> aValueIntArray;
std::vector <std::string> aValueStringArray;
}
 
ObjPtr * DataItem::store(int aValue)
{
// do some stuff
aValueInt = aValue;
// do some stuff
return this;
}
 
ObjPtr * DataItem::store (double aValue)
{
// do some stuff
aValueDouble = aValue;
// do some stuff
return this;
}
 
ObjPtr * DataItem::store (std::vector <int> aValue)
{
// do some stuff
aValueIntArray = aValue;
// do some stuff
return this;
}
 
ObjPtr * DataItem::store (std::vector <std::string> aValue)
{
// do some stuff
aValueStringArray = aValue;
// do some stuff
return this;
}
 
Is there some way to combine all of these methods (and the other data
types) into a single method ?
 
Thanks !
 
Lynn
Bonita Montero <Bonita.Montero@gmail.com>: Jun 16 08:50PM +0200

> Is there some way to combine all of these methods
> (and the other data types) into a single method ?
 
Try std::variant<...>.
But that's less performant.
Bonita Montero <Bonita.Montero@gmail.com>: Jun 16 09:02PM +0200

>> (and the other data types) into a single method ?
 
> Try std::variant<...>.
> But that's less performant.
 
How about this:
 
#include <variant>
#include <vector>
#include <string>
 
using namespace std;
 
struct DataItem
{
int aAvalueInt;
double aValueDouble;
vector<int> aValueIntArray;
vector<string> aValueStringArray;
};
 
using var_t = variant<int, double, vector<int>, vector<string>>;
 
void f( var_t &var, DataItem &di )
{
enum
{
INT,
DOUBLE,
VEC_INT,
VEC_STR
};
switch( var.index() )
{
case INT:
di.aAvalueInt = get<INT>( var );
break;
case DOUBLE:
di.aValueDouble = get<DOUBLE>( var );
break;
case VEC_INT:
di.aValueIntArray = get<VEC_INT>( var );
break;
case VEC_STR:
di.aValueStringArray = get<VEC_STR>( var );
break;
}
}
 
Compile it with C++17 enabled.
Bonita Montero <Bonita.Montero@gmail.com>: Jun 16 09:21PM +0200

This more exactly maps to what you want:
 
#include <variant>
#include <vector>
#include <string>
 
using namespace std;
 
struct ObjPtr
{
// ...
};
 
struct DataItem : public ObjPtr
{
enum
{
INT,
DOUBLE,
VEC_INT,
VEC_STR
};
using var_t = variant<int, double, vector<int>, vector<string>>;
ObjPtr *store( var_t &var );
 
int aAvalueInt;
double aValueDouble;
vector<int> aValueIntArray;
vector<string> aValueStringArray;
};
 
 
ObjPtr *DataItem::store( var_t &var )
{
switch( var.index() )
{
case INT:
aAvalueInt = get<INT>( var );
break;
case DOUBLE:
aValueDouble = get<DOUBLE>( var );
break;
case VEC_INT:
aValueIntArray = get<VEC_INT>( var );
break;
case VEC_STR:
aValueStringArray = get<VEC_STR>( var );
break;
}
return this;
}
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 16 10:18PM +0200

On 16.06.2020 20:39, Lynn McGuire wrote:
> }
 
> Is there some way to combine all of these methods (and the other data
> types) into a single method ?
 
When you discriminate only on type, as in the above example code, you
can only have one member of each type.
 
If that restriction is OK with you then just make `store` a function
template:
 
template< class Arg >
auto store( Arg arg ) -> ObjPtr*
 
In the function body there are two main ways to select the member to
assign to, i.e. ways to specify the type -> member association. Maybe
there are other techniques too. But only two popped up in my brain now.
 
One way is to have a function overloaded for each relevant member type:
 
auto DataItem::member( int& ) -> int& { return aValueInt; }
auto DataItem::member( double& ) -> double& { return aValueDouble; }
// etc., then
 
template< class Arg >
auto DataItem::store( Arg arg )
-> ObjPtr*
{
// Do some stuff.
member( arg ) = move( arg );
// Do some more stuff.
return this;
}
 
Another way is to let the data members be base class sub-objects of
DataItem. Then they can be selected by `static_cast` to the relevant
type. Since one cannot derive from `int` or `double` it's necessary to
use some kind of boxing class, e.g.
 
template< class Value >
struct Boxed_
{
Value value;
};
 
class DataItem:
public ObjPtr,
private Boxed_<int>,
private Boxed_<double>,
// etc.
{
template< class Arg >
auto member( int& )
-> Arg&
{ return static_cast<Boxed_<Arg>&>( *this ).value; }
 
// + The `store` function template as before.
};
 
It's possible though that these techniques, while addressing directly
what you're asking for, don't address the Real Issue. Because inheriting
from an `ObjPtr` class, and returning a raw pointer from a `store`
method, indicate a struggling, unnatural design. So likely this is an
X/Y problem where you have a Real Issue X, you imagine that Y could be a
good solution to X, you can't make Y work cleanly, and you ask about Y?
 
- Alf
Bart <bc@freeuk.com>: Jun 16 05:34PM +0100

> portion is fully accessible because the length provides access to it.
> I made the email struct with the lengths up top so it's clearer visu-
> ally.
 
But is your new feature supposed to disentangle all that, or must the
fields be in a certain layout?
 
Your original example used several variable lengths strings in a struct,
different from C's variable struct which only has such an array at the
end, and its size is not automatically linked to an earlier field.
 
You then moved on to arrays with variable-length structs as in-line
elements, although the struct in your example had only one string. It
still made the array elements different sizes.
 
Then, you again had a multiple strings in the struct, but this time in
an apparently random order! Or are the lengths supposed to come before
the strings? Is the Nth length supposed to correspond to the Nth
char-array? Is the correspondence achieved by checking whether a simple
bound of the char-array corresponds to the name of an integer field?
(However, if the length comes after the char-array, that cannot work.)
 
Further, you then introduced a non-char-array element called a 'label'.
 
It does look exactly as though you are just making it up as you go along.
 
How about creating mock-ups of how these structures are supposed to
work, using existing language features, and trying them out on real data
using real programs? (A bit like how I tried to do, using explicit
functions.)
 
Then, you will see how well they function, what code is involved, and
how those handlers you built by hand can be automated by a compiler. I
see that as a necessary step.
 
> header = subject + length_subject + sizeof(length_header)
> body = header + length_header + sizeof(length_body)
> attachments = body + length_body + sizeof(attachmentCount)
 
So, quite a sizable amount of code, probably too much to be done inline,
for each access. A chain of calculations as I suggested.
 
The chain will be fixed for a struct member with named access, but for
an array of variable structs with an index like 'i', will involve a loop.
 
As for efficiency, imagine a sequence of 10,000 packed strings, assuming
a format that exactly matches your int32-plus-non-terminated-string.
 
> The compiler injects functions or inline code to compute the off-
> sets so you navigate each structure member as requested.
 
 
You can use this if you want, but most would see this as too low-level
(eg. a string with a separate length, one that you can override so
making it incorrect, yet the string isn't even zero-terminated making
most operations awkward), compared with more modern string objects.
 
If you want to keep packed binary data in memory, then better to
traverse it once to build auxiliary data, eg. an array of pointers into
the strings, or better, a set of counted-string 'views'into the data.
rick.c.hodgin@gmail.com: Jun 16 09:43AM -0700

On Tuesday, June 16, 2020 at 12:35:04 PM UTC-4, Bart wrote:
> > ally.
 
> But is your new feature supposed to disentangle all that, or must the
> fields be in a certain layout?
 
The only requirement is that the variable portion have a named
member up higher in the struct. It allows the member to have
a presence or not in the struct, and to be from 0..length bytes
long.
 
> Further, you then introduced a non-char-array element called a 'label'.
 
That's a feature of CAlive which allows you to access an offset
outside of referencing a typed member name. It allows you to do
math on the internals.
 
> It does look exactly as though you are just making it up as you go along.
 
You've misunderstood from the beginning. You've had a thought in
your mind about what it was, and have since run with it. If you
go back and read what I posted you'll see consistency all the way
through.
 
 
> Then, you will see how well they function, what code is involved, and
> how those handlers you built by hand can be automated by a compiler. I
> see that as a necessary step.
 
If you understand in concept, you'll see how it works. It's very
straight-forward.
 
> > attachments = body + length_body + sizeof(attachmentCount)
 
> So, quite a sizable amount of code, probably too much to be done inline,
> for each access. A chain of calculations as I suggested.
 
Yes, all hidden from the developer, allowing the developer to use
the feature without worrying about the mechanics.
 
> As for efficiency, imagine a sequence of 10,000 packed strings, assuming
> a format that exactly matches your int32-plus-non-terminated-string.
 
If you have a need for 10,000 things use something else. This is
for the purposes I've outlined. You prepare a message at some
source, transmit to another, and then immediately process it rather
than having to parse it out.
 
 
> If you want to keep packed binary data in memory, then better to
> traverse it once to build auxiliary data, eg. an array of pointers into
> the strings, or better, a set of counted-string 'views'into the data.
 
You are completely missing the point. I wonder sometimes if you
read what I write.
 
--
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 16 06:15PM +0100

> free from the lies, seek the truth. Jesus is truth. Learn of Him
> and He will set you free, and restore you to His eternal Kingdom of
> power and love and peace and joy and beauty and honor.
 
tl;dr.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 16 06:15PM +0100

> evident even to someone who does not believe in God, because it is
> also true of simple life and living (falseness and lies never bring
> about rightness, they always only bring about destruction and death).
 
tl;dr.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
rick.c.hodgin@gmail.com: Jun 16 11:54AM -0700

On Tuesday, June 16, 2020 at 1:15:39 PM UTC-4, Mr Flibble wrote:
> tl;dr.
 
Ironic.
 
The short version of what I wrote is this:
 
Satan deceives people into not looking into the details. He
does this so he can keep the false image he's assembled into
their thinking in tact knowing that a real examination of the
facts and data would undo that stranglehold and set the person
free from his lies, allowing that person to know the truth.
 
You remain deceived by Satan, Leigh, because you are willfully
ignorant. You make the conscious choice not to know.
 
--
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 16 08:16PM +0100

> free from his lies, allowing that person to know the truth.
 
> You remain deceived by Satan, Leigh, because you are willfully
> ignorant. You make the conscious choice not to know.
 
And Satan invented fossils, yes?
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
rick.c.hodgin@gmail.com: Jun 16 12:36PM -0700

On Tuesday, June 16, 2020 at 3:16:14 PM UTC-4, Mr Flibble wrote:
> And Satan invented fossils, yes?
 
No, but he did invent the lie you use today, again in ignorance.
 
You're holding on to lies, Leigh. They keep you bound, and will cont-
inue to do so until you begin to seek the truth.
 
--
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 16 08:47PM +0100


> No, but he did invent the lie you use today, again in ignorance.
 
> You're holding on to lies, Leigh. They keep you bound, and will cont-
> inue to do so until you begin to seek the truth.
 
And Satan invented fossils, yes?
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
Cholo Lennon <chololennon@hotmail.com>: Jun 16 04:16PM -0300

> Wuhan virus and checking temperatures. I'm happy
> to report that I don't have any symptoms at this
> time and hope to keep it that way.
 
"Wuham virus"? :-O the virus has a name. Maybe, using your bias, we
should use "the state where police kill non-white people" instead of
Minnesota, or even better... Killersota... (yes, I have plenty of
biased/stupid "names")
 
 
--
Cholo Lennon
Bs.As.
ARG
Makis <Makis@gkarvounis.eu>: Jun 16 07:05PM +0200

Am 15.06.2020 um 23:44 schrieb Frederick Gotham:
 
> if ( !cond3 ) return;
 
> if ( !cond4 ) return;
 
> Do Something();
 
Very hard if you have to do some cleanup upon leaving
 
 
> Do Something();
 
> Label_At_End:
> ;
 
No comment!
 
 
> if ( !cond4 ) break;
 
> Do Something();
> }
 
This is a misuse of switch statement
 
 
> Do Something();
> } while (false);
 
> Does anyone else use fake switches and fake loops like this just to exploit the 'break' keyword?
 
I use this a lot. Better than nested ifs. You can do a cleanup at the
end. And... it works for C too!
Marcel Mueller <news.5.maazl@spamgourmet.org>: Jun 16 08:08PM +0200

> Does anyone else use fake switches and fake loops like this just to exploit the 'break' keyword?
 
I prefer
 
do
{
...
 
break;
} while(true);
 
It basically defines two labels.
One to repeat the current block: continue,
and one after the current block: break.
 
 
It can also be useful to write
 
do
{
...
 
} while (fasle);
 
This is especially useful to escape from a nested switch statement with
continue.
 
 
But all of them are not always better than goto. It mainly helps to keep
code guidelines that prohibit the use of goto.
 
E.g. in case of CAS loops I prefer goto retry; since it is no loop in
the logical application flow.
 
 
Marcel
Christian Gollwitzer <auriocus@gmx.de>: Jun 16 08:40PM +0200

Am 16.06.20 um 19:05 schrieb Makis:
 
>> if ( !cond4 ) return;
 
>> Do Something();
 
> Very hard if you have to do some cleanup upon leaving
 
On the contrary, very easy. Use RAII and the compiler does the right
cleanup in the right order. In real cases, I allocate resources in
between the different conditions. That means a lot of conditions for the
cleanup sequence, too, (necessary in C without ++) unless you use RAII
consequently, which leaves this to the compiler.
 
Christian
Bo Persson <bo@bo-persson.se>: Jun 16 05:53PM +0200

On 2020-06-16 at 17:29, Paavo Helde wrote:
> trigger implicit object creation."
 
> I gather all this fuss is about allowing type-based alias analysis.
> Reinterpret_cast works directly against this idea.
 
Yes, the idea was to not have to decorate every other pointer with a
'restrict' keyword (like some other language does).
 
 
Bo Persson
Manfred <noname@add.invalid>: Jun 16 05:53PM +0200

On 6/16/2020 5:29 PM, Paavo Helde wrote:
> trigger implicit object creation."
 
> I gather all this fuss is about allowing type-based alias analysis.
> Reinterpret_cast works directly against this idea.
 
That's why I find the proposal going in the direction of causing more
trouble than help.
True, reinterpret_cast breaks type-based alias analysis. However, it has
been part of the standard since day one, and since you can't do type
analysis on a buffer returned by malloc anyway, what's the problem with
that?
 
By the way, I managed to look into Bjarne's book (p. 1260):
"Note that malloc() etc. does not invoke constructors and free() doesn't
invoke destructors. Do not use these functions for types with
constructors and destructors. Aldo, memset() should never be used for
any type with a constructor".
 
That makes perfectly sense.
I wonder why the standard managed to come up with something that denies
/any/ object allocation with malloc (at least according to the first
example in the proposal).
Paavo Helde <eesnimi@osa.pri.ee>: Jun 16 07:34PM +0300

16.06.2020 18:53 Manfred kirjutas:
> been part of the standard since day one, and since you can't do type
> analysis on a buffer returned by malloc anyway, what's the problem with
> that?
 
With malloc there is no conceptual problem because it produces "fresh"
memory where there are no existing objects which might alias something
else. But this is a property of malloc, not a property of any cast. The
proposal attempts to get this bit correct.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 16 05:44PM +0100

On Tue, 16 Jun 2020 17:53:56 +0200
Manfred <noname@add.invalid> wrote:
[snip]
> I wonder why the standard managed to come up with something that denies
> /any/ object allocation with malloc (at least according to the first
> example in the proposal).
 
It doesn't say you cannot construct objects in raw memory provided by
malloc (or by operator new for that matter). It says that to do it you
have to use placement new. (The problem with pointer arithmetic on
non-arrays is a different but also annoying fault.)
 
I think this insistence on using placement new is wrong. If an object
is of trivial type it does not have a constructor or destructor which
does anything. It is a C-like type. For trivial types, I see no
reason why the standard cannot take the dynamic type of the memory to
be the type of the first trivial object placed in it, say by memcpy or
by assignment, which is how the C standard determines the "effective
type" of memory allocated by malloc. A standard which regards
inter-operability with C as important ought to provide for this.
 
In C++ this has now been overlain since C++17 with std::launder. Prior
to C++17 it used to be assumed that the strict aliasing rules regarding
dereferencing pointers were what you needed to comply with. Put
shortly, it used to be that if there really was an object of type T
properly constructed at address n, then you could reinterpret_cast n
to pointer to T and dereference that pointer. That seems fair and
logical. However this no longer applies generally. Even if you are
fully compliant with the strict aliasing rules, unless you fall within
one of the cases described as "pointer-interconvertible" then a
reinterpret_cast of pointers is no longer enough. You also have to use
std::launder. Amongst other things, a pointer to the first element of
an array is not pointer-interconvertible to pointer to array even
though they are mandated by the standard to have the same address
(there is an implicit cast in the reverse direction). You have to use
std::launder as well as a reinterpret_cast. Likewise you have to use
std::launder to access an object allocated in a buffer by placement new
other than through the pointer returned by placement new. What's the
point of this? The strict aliasing rules should be enough.
 
And it seems from P0593 that the standard has problems on other matters
of memory allocation. How on earth, in a serious technical standard,
can you mandate implementers to provided functions such as
std::unitialized_copy which, if implemented according to the
specification, have undefined behaviour?
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)