Thursday, November 21, 2019

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

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 16 09:02PM

Hi!
 
The "neoGFX" UI description language (based on Relaxed JSON) will allow
you to embed code in any programming language; by default it will use
braces {} to delineate the code from the surrounding purely declarative UI
description elements. neoGFX will leverage "neos", my universal compiler,
to achieve this feat. If the embedded language is C++ then the host C++
compiler will compile the code. #coding #neoGFX #cpp #qt
 
/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," Bryne 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."
Bonita Montero <Bonita.Montero@gmail.com>: Nov 16 05:31PM +0100

Am 16.11.2019 um 17:23 schrieb Wisdom90:
> Here is how to use my Delphi projects with C++Builder:
> Mixing Delphi and C++
> https://community.idera.com/developer-tools/b/blog/posts/mixing-delphi-and-c
 
No one has the weird idea to mix Delphi and C++. And often there is code
with generic classes which can't be mixed. Accept it or not: Delphi is
and will never be relevant in the world of sw-development. At the time
when Delphi hit the market, the train for Pascal-derivatives had already
come to an end.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 18 06:24PM -0800

On 11/18/2019 5:25 AM, James Kuyper wrote:
 
>> My point is that hammering a single mutex should not crash the system.
 
> But, Scott already said that a crashing was not expected, so why the "me
> too" post?
 
Habit? Sorry.
James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 18 08:25AM -0500

On 11/17/19 11:59 PM, Chris M. Thomasson wrote:
>>> It should not crash, slowing to a crawl is expected.
 
>> You just said the same thing, with slightly different wording. Your point?
 
> My point is that hammering a single mutex should not crash the system.
 
But, Scott already said that a crashing was not expected, so why the "me
too" post?
Ian Collins <ian-news@hotmail.com>: Nov 18 08:26PM +1300

On 18/11/2019 20:23, Öö Tiib wrote:
 
 
> You think that you can change what standard says by erasing attributions
> and context in Usenet post? :D
 
What else did you expect?
 
--
Ian.
scott@slp53.sl.home (Scott Lurndal): Nov 16 06:07PM


>Well, I remember abusing unaligned atomics such that a word straddles a
>L2 cache line! Well, on x86 this should trigger a system wide bus lock
>for legacy reasons.
 
Yes, that's the "very time consuming" part.
 
We (3Leaf Systems) designed a chip in the mid 2000s that connected
to the processor via Hypertransport (Opteron) or QPI (Intel) and
extended the processor coherency domain over Infiniband[*] to another
instance of our chip (allowing creation of large shared memory
systems consisting of commodity 1u or 2u rack mount SMP boxes).
 
One of the national labs was benchmarking the system by pounding on
a spinlock from all 128 cores (across 16 2-socket nodes).
 
A little known characteristic of AMD and Intel
processors is that if a processor isn't making progress on acquiring
a highly contended cache-line, it will at some point decide to obtain the
system bus lock.
 
Needless to say, performance was shit (although the test was designed
to show this behavior and was not representative of the labs normal
workloads on the system).
 
[*] The chip had 2MByte of DRAM caching remote lines, a miss cost about
800 ns round trip (using DDR IB) on the HT systems, and 500ns on QPI (using QDR IB).
Manfred <noname@invalid.add>: Nov 17 04:46PM +0100

On 11/17/19 12:51 AM, Alf P. Steinbach wrote:
> {
>     foo( "Baluba!" );
> }
 
Bansky coding?
David Brown <david.brown@hesbynett.no>: Nov 19 08:26AM +0100

On 19/11/2019 00:21, Sam wrote:
 
> But I will not refrain from enjoying a cost-free source of cheap
> entertainment just because someone else gets upset. It just makes no
> logical sense for me to do so.
 
I appreciate your right to post the way you want here, and I fully
appreciate your motive of cheap entertainment. But there comes a point
in which such threads become more akin to Calvin and Hobbes "You're a
potty mouth! No, /you're/ a potty mouth!". Surely that can no longer
be entertaining?
 
Bonita does not seem to be going anywhere - you'll get plenty of new
chances in the future, and perhaps an opportunity for new and more
varied insults.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 18 05:41PM +0100

> I never claimed to be a professional member of any such organization in
> this thread. You demanded that I must be one, in order to diagnose your
> case of projection, and I did not dispute that I never claimed to be one.
 
In Germany we call diagnoses like yours as "kitchen psychology" which
could be translated ad layman's psychology. And those diagnoses are
not even inprecise, but usually nonsense.
You're simply a stupid person.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 21 06:02AM +0100

On 20.11.2019 18:46, Manfred wrote:
> Bjarne's book on SFINAE
 
Uh, which book?
 
I remember introducing Bjarne to the term in a mail exchange, but it's
apparently not in my GMail so it must be have been before July 2006.
 
- Alf
Melzzzzz <Melzzzzz@zzzzz.com>: Nov 19 03:53AM

> auto is_in( const initializer_list<Value>& list, const Value v )
> -> bool
> { return false; }
 
why not just auto? What's the point of both auto and return type?
 
 
 
--
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
Vir Campestris <vir.campestris@invalid.invalid>: Nov 18 09:54PM

On 18/11/2019 17:49, Alf P. Steinbach wrote:
> As the title says, substitution failure can be an error:
 
Most interesting post for weeks - and I don't understand it :(
 
It would help if I had a modern compiler to hand of course - but playing
with an online one does give me an error.
 
Are you sure it isn't a compiler bug? The error from clang is nothing
like the one from GCC.
 
Andy
James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 20 03:48PM -0800

On Wednesday, November 20, 2019 at 1:55:45 PM UTC-5, Soviet_Mario wrote:
> I would not want to include many QT features for now
> so, what is the STANDARD C++ way to get
> unsigned 8 bits integer type ?
 
You should use uint8_t, a typedef declared in <cstdint>. The meaning of
this type is specified in the C standard, and incorporated into the C++
standard only by reference. The type is optional, you can check whether
or not UINT8_MAX is #defined to determine whether or not the type is
supported. As a practical matter, an implementation will fail to
support uint8_t only when compiling code to run on a platform that where
an 8-bit data type cannot be implemented, at least not efficiently.
 
You can also check CHAR_BIT, a macro #defined in <climits>. If
CHAR_BIT==8, then unsigned char can also be used, and uint8_t will
almost certainly be a typedef for unsigned char. As with uint8_t, if
CHAR_BIT!=8, then you an safely assume that the target platform is one
where an 8-bit type cannot be efficiently supported.
 
> I fear that unsigned char is system dependent (and even if
> there are "wider" explicitely supported types, no plain char
> type seems to warranty to be 8 bits wide).
 
Correct.
 
> struct {unsigned Pixel : 8} Mask;
> gives me a warning like : 3 byte PADDING used to align the
> struct Mask.
 
That approach will not work. The size of that struct is guaranteed to
be a positive integer number of bytes. On any platform where unsigned
char is NOT an 8-bit type, that struct is guaranteed to have a size
bigger than 8 bits. Even on a platform where CHAR_BIT==8, that struct
might be larger than 8 bits.
 
...
> long ago CHAR was 8 bit wide, but now it seems to be
> platform dependent, and more often "a word" wide.
 
There is no CHAR type in C. There is a char type - C++ is a case-
sensitive language, so that distinction is important. The number of bits
in a char object has always been platform dependent.
Soviet_Mario <SovietMario@CCCP.MIR>: Nov 21 12:54AM +0100

Il 20/11/19 20:34, Jorgen Grahn ha scritto:
>> so, what is the STANDARD C++ way to get
>> unsigned 8 bits integer type ?
 
> uint8_t, just like in C. Or, I guess it's really std::uint8_t.
 
I opened the headers, i.g. sys/types.h and stdint.h
and they finally stem from a typedef that turns out to be a
"delusional" unsigned char.
I write delusional as I still do not have found a strict
warranty that a char is really 8 bit wide
 
>> platform dependent, and more often "a word" wide.
 
> No; a char is rarely more than 8 bits nowadays. You may be thinking
> of wchar_t, but that's something different.
 
ok, note taken. But is it a warranty or a very common guess ?
 
 
>> QT has its explicitely sized integers (even if no 8-bit sized)
 
> Qt has its own versions of most things ... are you sure you need it?
 
Yes it has many types redecorated its own way.
 
But as I wrote I'm not much confident on them on one side
(not on themselves, on my skills obv.) and I often cannot
even guess what they could be like from "outside".
With gambas I just got to work with integral types, even
"strings" are still very difficult to me
So I'd feel better the less "wrappers" around types are put.
 
Now I'm exploring the solution with a struct containing only
a 8 bit field, and the #pragma pack
 
 
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
Soviet_Mario <SovietMario@CCCP.MIR>: Nov 21 01:00AM +0100

Il 20/11/19 22:03, David Brown ha scritto:
>> so, what is the STANDARD C++ way to get
>> unsigned 8 bits integer type ?
 
> uint8_t from <stdint.h>, or std::uint8_t from <cstdint>.
 
i inquired, and they expand to a typedef related to unsigned
char
 
> exactly what you ask for.  (If the platform doesn't support
> 8-bit char, the type won't exist and the code won't
> compile.  But very little code needs to be /that/ portable.)
 
uhm ... maybe. But I am trying to mirror a byte-wise mask of
opacity/transparency from images, so I have to get two
different pieces of programs (a front end in gambas and this
would-be static library to speak the same language and have
the same data layout).
 
To be very very tight fisted, I could even have devoted a
SINGLE BIT to the transparency mask, but addressing would
have become far slower. So I waste 7 bits ! but no more.
 
The pictures themselves are also made of bit fields, but are
four fields 8 bit each, so exactly 32 bit / pixel and the
packing was not necessary there (and also align issue did
not show up).
 
the gambas frontend has a native type BYTE (0-255 range)
for the transparency mask so I have to replicate it in the
library
 
 
 
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
"Öö Tiib" <ootiib@hot.ee>: Nov 20 04:27PM -0800

On Thursday, 21 November 2019 01:54:39 UTC+2, Soviet_Mario wrote:
 
> > No; a char is rarely more than 8 bits nowadays. You may be thinking
> > of wchar_t, but that's something different.
 
> ok, note taken. But is it a warranty or a very common guess ?
 
Use std::uint8_t from <cstdint> or uint8_t from <stdint.h> anyway
just to document what you do. Both must be only present when the
platform supports 8 bit unsigned integers. I don't know existence
of any platforms with conforming C++ compilers that do not support
those or where those are not unsigned char but so what?
 
 
> Now I'm exploring the solution with a struct containing only
> a 8 bit field, and the #pragma pack
 
An uint8_t directly or wrapped into struct feels better.
Your unsigned bitfield in anonymous union in packed struct
is possibly not very well tested / profiled in all situations on
all compilers and so may have odd differences of performance
or the like.
Manfred <invalid@add.invalid>: Nov 21 01:48AM +0100

On 11/21/19 12:54 AM, Soviet_Mario wrote:
> unsigned char.
> I write delusional as I still do not have found a strict warranty that a
> char is really 8 bit wide
 
It's not delusional, it's how it works.
You opened some standard header of your implementation, and since in
your implementation a byte is an unsigned char, this is the correct typedef.
If you happen to port the code to an implementation (if any) where a
byte has a different representation, then the standard header of that
implementation would have the corresponding definition.
 
This way of working is most evident with stuff like uint32_t and
uint64_t (as many have said, most of the time uint8_t is an unsigned char).
 
If porting to an implementation where no byte is available, then uint8_t
would not be defined (also said by others).
 
Gist of the story is, yes, uint8_t is guaranteed to be an 8-bit unsigned
integer, as its name suggests.
James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 20 05:44PM -0800

On Wednesday, November 20, 2019 at 6:54:39 PM UTC-5, Soviet_Mario wrote:
> Il 20/11/19 20:34, Jorgen Grahn ha scritto:
> > On Wed, 2019-11-20, Soviet_Mario wrote:
...
> "delusional" unsigned char.
> I write delusional as I still do not have found a strict
> warranty that a char is really 8 bit wide
 
You won't find it, because there is no such warranty in general. The
minimum value for CHAR_BIT is quite explicitly 8, but there is no
maximum, and it's certainly not required to be 8. Values other than 8
are rare, but not unheard of.
 
However, any conforming implementation of C++ for which <cstdint>
contains a typedef of uint8_t as unsigned char IS guaranteed to be one
for which unsigned char is an 8 bit type. That's not because of anything
the standard says directly about unsigned char; it's because it's not
permitted to for uint8_t to be a typedef for a type that isn't exactly 8
bits. The relevant guarantee is in the C standard, and incorporated into
the C++ standard by reference, but it is still a guarantee.
 
If CHAR_BIT != 8, or #ifndef UINT8_MAX, then there will be no way to
declare an 8-bit type for that implementation (except for bit-fields,
and you can't make arrays of bit-fields).
 
The key question the OP needs to ask himself is "What do I want my
program to do when compiled on a platform where there is no way to
declare an 8-bit type?". There's many options: failing to compile with
an explicit error message is one possibility. Depending upon what he
actually needs to do, uint_least8_t might be an acceptable alternative,
though I doubt it.
 
...
 
> > No; a char is rarely more than 8 bits nowadays. You may be thinking
> > of wchar_t, but that's something different.
 
> ok, note taken. But is it a warranty or a very common guess ?
 
It's very common, not guaranteed, and there's no need to guess about it.
Just check the value of CHAR_BIT.
 
...
> Now I'm exploring the solution with a struct containing only
> a 8 bit field, and the #pragma pack.
 
On a platform where CHAR_BIT==8, unsigned char will work. On a platform
where CHAR_BIT != 8, that approach won't work, nor will any other.
Reinhardt Behm <rbehm@hushmail.com>: Nov 21 10:33AM +0800

On 11/21/19 2:55 AM, Soviet_Mario wrote:
 
> long ago CHAR was 8 bit wide, but now it seems to be platform dependent,
> and more often "a word" wide.
 
> QT has its explicitely sized integers (even if no 8-bit sized)
 
Of course it has: Q_UINT8
 
The standard way would be (u)int8_t, if it is defined in your compiler.
Soviet_Mario <SovietMario@CCCP.MIR>: Nov 21 04:09AM +0100

Il 21/11/19 01:48, Manfred ha scritto:
> then uint8_t would not be defined (also said by others).
 
> Gist of the story is, yes, uint8_t is guaranteed to be an
> 8-bit unsigned integer, as its name suggests.
 
 
mmm, all changes then, as it was the warranty I was looking
for !
 
 
 
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
Soviet_Mario <SovietMario@CCCP.MIR>: Nov 21 04:14AM +0100

Il 21/11/19 02:44, James Kuyper ha scritto:
> permitted to for uint8_t to be a typedef for a type that isn't exactly 8
> bits. The relevant guarantee is in the C standard, and incorporated into
> the C++ standard by reference, but it is still a guarantee.
 
very clear (and very good for me!)
tnx
 
 
> If CHAR_BIT != 8, or #ifndef UINT8_MAX, then there will be no way to
> declare an 8-bit type for that implementation (except for bit-fields,
> and you can't make arrays of bit-fields).
 
actually I made an array of the enclosing struct of the bit
field (which was the only member but this may not be relevant).
I noticed that the "padding warning disappeared" with the
#pragma pack(1)
which might be a proof that the system is capable of
addressing single bytes regardless of their alignment in memory
 
but all this now is unnecessary, after what you all have stated
 
 
> The key question the OP needs to ask himself is "What do I want my
> program to do when compiled on a platform where there is no way to
> declare an 8-bit type?".
 
none, I won't possibly port it anywhere, just run here locally
 
>> a 8 bit field, and the #pragma pack.
 
> On a platform where CHAR_BIT==8, unsigned char will work. On a platform
> where CHAR_BIT != 8, that approach won't work, nor will any other.
 
understood. So the workaround worked only because the system
was just able to address single bytes
 
 
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
Keith Thompson <kst-u@mib.org>: Nov 20 10:32PM -0800

> I would not want to include many QT features for now
> so, what is the STANDARD C++ way to get
> unsigned 8 bits integer type ?
 
If uint8_t exists, then both it and unsigned char are unsigned 8-bit
integer types (and very likely uint8_t is an alias for unsigned char).
Using uint8_t makes it more explicit that you want an unsigned 8-bit
integer type.
 
If uint8_t doesn't exist, then CHAR_BIT > 8 and there is no 8-bit
integer type. You're unlikely to encounter such an implementation
(I've only heard of very old systems and DSPs) -- and I'd be
astonished if such a system were able to support Qt.
 
(There's probably some wiggle room there. An implementation with
CHAR_BIT==8 with signed char using a representation other than
2's-complement won't define int8_t and, IIRC, therefore shouldn't define
uint8_t -- but such implementations are, I think, even rarer.)
 
> I fear that unsigned char is system dependent (and even if
> there are "wider" explicitely supported types, no plain char
> type seems to warranty to be 8 bits wide).
 
Correct. The three char types are CHAR_BIT bits, or 1 byte.
 
Your best bet is probably to use uint8_t, which guarantees that your
code won't compile if the implementation doesn't meet its requirements.
 
[...]
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
Keith Thompson <kst-u@mib.org>: Nov 20 10:33PM -0800

> Il 20/11/19 19:55, Soviet_Mario ha scritto:
> Uhm, from some search, it seems that a "pragma pack" exist.
> I still have to read it, though
 
pragma pack is a common extension, but it's non-standard. If you're
worried enough about portability that you're unwilling to assume
CHAR_BIT==8, you probably don't want to depend on extensions.
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
Keith Thompson <kst-u@mib.org>: Nov 20 10:43PM -0800

> integer type. You're unlikely to encounter such an implementation
> (I've only heard of very old systems and DSPs) -- and I'd be
> astonished if such a system were able to support Qt.
[...]
 
I'm curious about something. Do you have a realistic expectation that
your code might need to work under an implementation with CHAR_BIT > 8?
Do you have such a target system in mind?
 
C++ with the assumption that CHAR_BIT==8 is realistically at least 99%
as portable as C++ without that assumption -- and far more portable than
C++ with the assumption that Qt is available.
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 20 03:28PM -0800

On Wednesday, November 20, 2019 at 9:16:00 AM UTC-5, Scott Lurndal wrote:
 
> A NULL pointer need not have the value zero; I recall an
> architecture where NULL pointers were indicated by the
> sentinal value EEEEEE (yes, 6 4-bit digits).
 
NULL is a C++ standard macro. "null" is an adjective that applies in
several C++ contexts, one of the most important being the phrase "null
pointer". C++ is a case sensitive language, so I don't think it counts
as pedantry to point out that these are different things.
 
Before nullptr was invented, NULL was not only allowed, but required to
expand into a null pointer constant: an integer literal with a value of
0. What you're actually talking about is a null pointer. The value of a
pointer is the location where it points at. What you're talking about is
not the value of the pointer, but it's representation. There is indeed
no requirement that a null pointer have all bits 0, and there are real-
world implementations where this is not the case.
 
Note also that even if "E" is an expression with an integer type and a
value of 0, (T*)E is not guaranteed to produce a null pointer value
That guarantee requires an integer literal.
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)