Friday, March 31, 2023

Digest for comp.lang.c++@googlegroups.com - 2 updates in 1 topic

scott@slp53.sl.home (Scott Lurndal): Mar 31 08:03PM

>Parliament seats. Now they don't have a single one. It's not as simple
>as you are saying. And it's hard to characterise the current governing
>party as racist when it chose an Indian as Prime Minister.
 
David was responding to Muttley's characterization of the current
Scottish Prime Minister, based soley on his religion.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Mar 31 01:03PM -0700

> On Friday, 31 March 2023 at 14:36:52 UTC+1, David Brown wrote:
>> It is one thing to comment on the depressing but very real fact that
>> British politics
[...]
 
> Under the Labour government the British National Party (a far right
[...]
 
Please stop.
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
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.

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

Anssi Saari <as@sci.fi>: Mar 31 11:18AM +0300

> key. I do not find it makes any noticeable difference. Of course it
> takes time to change habits and muscle memory - but once you are used
> to it, one position is as good as another.
 
I don't agree. I want fast and easy access for the common punctuation
used in HDLs and software languages. Other less commonly used stuff can
go behind AltGr or just the right Alt on a US keyboard.
 
I've long thought the ¤ meant the asshole who designed the
Finnish/Swedish keyboard layout and have for a long time used the US
layout, no matter what's printed on the keys. Got familiar with xmodmap
in the 1990s when Sun workstations all came with US keyboards, even here
in Finland. xmodmap still does the job 30 years later. Other tools work
in other environments.
 
> when you want to type something other than plain ASCII. I can write
> I²C, µF, πr², 25°C, café, naïve, 2½, «Hello», and lots of other
> symbols directly from the keyboard
 
Interesting. Maybe the Norwegian layout is more flexible than
Finnish/Swedish? I know I can get the common accents (´`¨~) from the
dead keys and § and ½ directly since they have a dedicated key but for
the rest... I guess I learned something.
Muttley@dastardlyhq.com: Mar 31 09:16AM

On Thu, 30 Mar 2023 17:53:38 GMT
>>ow immediate access to their preferred variant to be defective.
 
>Muttley appears to be British, and many brits still believe the sun doesn't
>set on the empire. That's no longer the case.
 
Before being a sarcastic jackass you might want to check whether the UK
keyboard is pure ascii too. It isn't. However, the standard ascii punctuation
characters aside from dollar are used all over the world and should be clearly
visible on any keyboard, not hidden.
Muttley@dastardlyhq.com: Mar 31 09:17AM

On Thu, 30 Mar 2023 20:21:52 +0100
>imperial attitude is not common among those young enough to know what an
>emoji is! I thought Muttley was from the USA as ASCII-nationalism has,
>historically, been more common in the US than in the UK.
 
Oh do fuck off you patronising arsewipe.
 
I was under the impression people who read this group were developers and
developers require the full set of ascii punctuation characters along with
anyone who does more online than write comments on tik-tok.
Muttley@dastardlyhq.com: Mar 31 09:18AM

On Thu, 30 Mar 2023 19:07:08 +0200
>>> symbols
 
>> Whatever those are they come out as gibberish in my terminal.
 
>Are you unable to view UTF-8 ? What newsreader are you using?
 
Its running in Mac Terminal.
David Brown <david.brown@hesbynett.no>: Mar 31 12:40PM +0200

On 30/03/2023 21:14, Ben Bacarisse wrote:
> type those characters with ease. The OS and it's input methods have
> more to do with it than what I would call the "layout", but maybe I'm
> missing something from what you mean by the term.
 
There are several aspects to keyboard layout. The most obvious one is
physical - when you buy an off-the-shelf keyboard in the UK, and one in
Norway, there are different symbols on the keys. When you look at your
"7" key, you'll see an "&" symbol accessible by "shift-7". I see "/"
above the 7, so "shift-7" on a Norwegian keyboard layout should give "/"
- I type "shift-6" for "&". My "7" key also has a "{" symbol to the
side - thus I use "AltGr-7" to get "{".
 
It is, of course, the OS and/or GUI and/or any configurable input
methods that determines how the low-level keycodes are interpreted. But
at a minimum, to be able to say you are using the standard UK or
Norwegian keyboard layouts, your system must support those physically
marked keys and symbols.
 
On the software side, keyboard layouts can support more. The standard
layouts on Windows support little more than the basics - for standard
English (not "international", "extended" or "deadkey" versions), you
have very little extra. With standard Norwegian layout, there are dead
keys for a few common diacriticals, usable on vowels (é è ë ê ẽ). It is
still very limited compared to Linux, but at least a step beyond the
standard UK or US English keyboard layout on Windows.
 
However, I have had very little use of standard English (UK or US)
keyboard layouts in Linux for a very long time - perhaps it supports
more than I thought. It is, of course, always possible to choose
international English varieties, enable AltGr, dead keys, a compose key,
and so on - but that's going beyond /standard/ layout. But are you
getting easy access to characters like Å ,ß, ¼ without having enabled
anything special?
 
 
> clan who see facilitating typing (or, God forbid, posting) non-ASCII
> characters as the thin end of some subversive socialist wedge. First
> they let you type an acute accent, but then they come for your guns!
 
If anyone thinks they need non-ASCII letters, you should explain LOUDLY
and S L O W L Y why the Queen's English is good enough for them!
Muttley@dastardlyhq.com: Mar 31 10:58AM

On Fri, 31 Mar 2023 12:40:47 +0200
>> they let you type an acute accent, but then they come for your guns!
 
>If anyone thinks they need non-ASCII letters, you should explain LOUDLY
>and S L O W L Y why the Queen's English is good enough for them!
 
I see the straw men are busy today.
 
Are you capable of comprehending the difference between
 
"need all ascii characters"
 
and
 
"not needing non ascii characters".
 
Given you claim to be a developer the simple boolean logic difference should
be evident.
David Brown <david.brown@hesbynett.no>: Mar 31 01:00PM +0200

On 31/03/2023 10:18, Anssi Saari wrote:
 
> I don't agree. I want fast and easy access for the common punctuation
> used in HDLs and software languages. Other less commonly used stuff can
> go behind AltGr or just the right Alt on a US keyboard.
 
I don't know what you are disagreeing about - I /have/ fast and easy
access to the symbols used in common programming languages. (APL does
not count :-) ). I am at a loss as to why some people think it is hard
to type "AltGr-7" to get "{", and feel that "shift-[" is so much simpler
on /their/ layout. It is not as though I need to press "compose", "("
and "-" to get it.
 
> in the 1990s when Sun workstations all came with US keyboards, even here
> in Finland. xmodmap still does the job 30 years later. Other tools work
> in other environments.
 
There certainly was a time when multiple competing variants of ASCII
character sets were a problem. You'd try to print out your C code, and
the braces and brackets were replaced with Å or æ, or hash was replaced
by a pound sign. But that was a character set issue, not a keyboard
layout issue. I have never had an issue using Norwegian keyboards and
Norwegian keyboard layouts when typing C code. (But I only used Sun
workstations before I moved to Norway.)
 
> Finnish/Swedish? I know I can get the common accents (´`¨~) from the
> dead keys and § and ½ directly since they have a dedicated key but for
> the rest... I guess I learned something.
 
I should really have been more careful about the OS in question. I get
lots of extra symbols on the standard Norwegian layout on Linux - the
standard Norwegian layout on Windows has more possibilities than the
standard UK/US English layout on Windows, but not nearly as much as
Linux. I would assume the Finnish layout is very similar to the
Norwegian layout on both systems.
 
Or are you using a Finnish layout on Linux (or other X system) but don't
have ², π, Ω and other symbols accessible directly with AltGr ?
David Brown <david.brown@hesbynett.no>: Mar 31 01:05PM +0200

On 30/03/2023 21:21, Ben Bacarisse wrote:
 
> I am sad for my country's recent dive into xenophobic politics, but that
> imperial attitude is not common among those young enough to know what an
> emoji is!
 
Unfortunately, it is the old xenophobes that make most of the policy.
The vote on Brexit should have had an upper age limit of perhaps 50 -
such important decisions about the future should be made by the people
who will live in that future, not those who are leaving.
 
(As a Scot, I am not xenophobic - merely anglophobic!)
David Brown <david.brown@hesbynett.no>: Mar 31 01:08PM +0200

> keyboard is pure ascii too. It isn't. However, the standard ascii punctuation
> characters aside from dollar are used all over the world and should be clearly
> visible on any keyboard, not hidden.
 
You mean like they are on my Norwegian keyboard? Clearly visible and
easy to type, as I have described?
 
I wonder if it is not just non-ASCII characters you have trouble reading.
Muttley@dastardlyhq.com: Mar 31 11:27AM

On Fri, 31 Mar 2023 13:05:59 +0200
>The vote on Brexit should have had an upper age limit of perhaps 50 -
>such important decisions about the future should be made by the people
>who will live in that future, not those who are leaving.
 
People aged 50 could live for another 50 years.
 
 
>(As a Scot, I am not xenophobic - merely anglophobic!)
 
Same thing. But now with Humza Useless as FM you can look forward to
Scotlandistan becoming a thing. Only SNP supporters could be thick enough
to believe a devout muslim would be more liberal than a christian.
Muttley@dastardlyhq.com: Mar 31 11:28AM

On Fri, 31 Mar 2023 13:08:00 +0200
>> visible on any keyboard, not hidden.
 
>You mean like they are on my Norwegian keyboard? Clearly visible and
>easy to type, as I have described?
 
So what are you arguing about then? I'm simply saying all ascii characters
should be available on a keyboard.
 
>I wonder if it is not just non-ASCII characters you have trouble reading.
 
You wonder a lot and never seem to have any answers.
David Brown <david.brown@hesbynett.no>: Mar 31 03:36PM +0200

> Same thing. But now with Humza Useless as FM you can look forward to
> Scotlandistan becoming a thing. Only SNP supporters could be thick enough
> to believe a devout muslim would be more liberal than a christian.
 
Are you seriously posting blatant racism and religious prejudice here?
 
It is one thing to comment on the depressing but very real fact that
British politics has more xenophobic and insular in recent times. You
can agree or disagree with the politics - that's the freedom of a
democracy. But undisguised hate speech and bigotry - judging the SNP
leadership candidates purely on unjustified claims of stereotypical
group behaviours due to one aspect of their characters - that has no
place here or anywhere else.
 
My apologies to the rest of this group for my part in a thread which led
to such a post.
Muttley@dastardlyhq.com: Mar 31 03:00PM

On Fri, 31 Mar 2023 15:36:36 +0200
>> Scotlandistan becoming a thing. Only SNP supporters could be thick enough
>> to believe a devout muslim would be more liberal than a christian.
 
>Are you seriously posting blatant racism and religious prejudice here?
 
My god, the irony meter just went off the scale!
 
>leadership candidates purely on unjustified claims of stereotypical
>group behaviours due to one aspect of their characters - that has no
>place here or anywhere else.
 
Oh diddums, has ickle snowflake been triggered? Go to your safe space poppet
and hug the therapy teddy.
 
Fact: Strict Islam doesn't tolerate a number of liberal shibboleths.
 
Don't believe me? Visit saudi or iran and hold your boyfriends hand in the
street and see how long it is before you're carted away in a van.
 
>My apologies to the rest of this group for my part in a thread which led
>to such a post.
 
Yes, you should apologise for your clear xenophobia.
Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Mar 31 12:37PM -0700

On Friday, 31 March 2023 at 14:36:52 UTC+1, David Brown wrote:
> leadership candidates purely on unjustified claims of stereotypical
> group behaviours due to one aspect of their characters - that has no
> place here or anywhere else.
 
Under the Labour government the British National Party (a far right
Britihs political party) had several council seats and two European
Parliament seats. Now they don't have a single one. It's not as simple
as you are saying. And it's hard to characterise the current governing
party as racist when it chose an Indian as Prime Minister.
Muttley@dastardlyhq.com: Mar 31 09:25AM

I'm currently writing software that requires a deque that will reach a
max size and stay there so for example at the limit when I push something
on one end it automatically pops it off the other. Obviously this is simple
to accomplish with some boiler plate size check code, but does anyone know if
this sort of functionality has been mooted for upcoming STL versions?
Sam <sam@email-scan.com>: Mar 31 07:39AM -0400

> on one end it automatically pops it off the other. Obviously this is simple
> to accomplish with some boiler plate size check code, but does anyone know if
> this sort of functionality has been mooted for upcoming STL versions?
 
STL hasn't existed for decades. There's nothing of that sort in the current
version of the C++ library, and I haven't heard anything about anything of
that sort. I think it's unlikely.
"Öö Tiib" <ootiib@hot.ee>: Mar 31 04:44AM -0700

> on one end it automatically pops it off the other. Obviously this is simple
> to accomplish with some boiler plate size check code, but does anyone know if
> this sort of functionality has been mooted for upcoming STL versions?
 
You mean C++ standard library? No. That seems quite unusual behaviour for
deque. It is unclear why you just do not wrap std::deque to adapter that
checks the size and does what you want?
Or maybe what you really need is circular buffer? There is circular_buffer class
in boost.
Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Mar 31 05:26AM -0700

> on one end it automatically pops it off the other. Obviously this is simple
> to accomplish with some boiler plate size check code, but does anyone know if
> this sort of functionality has been mooted for upcoming STL versions?
 
A deque can throw. On most systems with a bug free and reasonable program,
this is so unlikely that the possibility can be ignored.
If a dequeu has a maximum size, then data has to be discarded when the maximum
is reached. Whilst you can think of circumstances in which this is appropriate,
for example if you are injecting a stream of badddies into a video game, it's
too unusual and special purpose to be attractive for standardisation.
Paavo Helde <eesnimi@osa.pri.ee>: Mar 31 03:50PM +0300

> on one end it automatically pops it off the other. Obviously this is simple
> to accomplish with some boiler plate size check code, but does anyone know if
> this sort of functionality has been mooted for upcoming STL versions?
 
Silently discarding data is not a behavior which should be present in a
standard container IMO.
 
There are also multiple variations about what and how such a thing could
behave, which are in my mind no worse, or less often needed:
 
- discarding not the first entry, but some other(s), depending on
condition
- throwing an exception
- waiting until another thread makes room in the queue
- yielding to a coroutine for making room in the queue
- ...
Muttley@dastardlyhq.com: Mar 31 03:02PM

On Fri, 31 Mar 2023 07:39:59 -0400
>> to accomplish with some boiler plate size check code, but does anyone know if
 
>> this sort of functionality has been mooted for upcoming STL versions?
 
>STL hasn't existed for decades.
 
I see pendant mode has been turned to 11 again today.
 
STL is shorthand for the containers in the standard library amongst a lot of
us.
Muttley@dastardlyhq.com: Mar 31 03:04PM

On Fri, 31 Mar 2023 04:44:47 -0700 (PDT)
 
>You mean C++ standard library? No. That seems quite unusual behaviour for
>deque. It is unclear why you just do not wrap std::deque to adapter that
>checks the size and does what you want?
 
For the same reason I use C++ and not C and writing my own implementation of
a queue.
 
>Or maybe what you really need is circular buffer? There is circular_buffer
>class
>in boost.
 
Boost? Ugh. That abomination should crawl away and die in a corner, its time
has passed.
Muttley@dastardlyhq.com: Mar 31 03:07PM

On Fri, 31 Mar 2023 15:50:49 +0300
 
>> this sort of functionality has been mooted for upcoming STL versions?
 
>Silently discarding data is not a behavior which should be present in a
>standard container IMO.
 
Depends on the type of container.
 
> - waiting until another thread makes room in the queue
> - yielding to a coroutine for making room in the queue
> - ...
 
Or in my case, a message queue in which messages cease to be valid after X
messages have followed them so if they haven't been read by then they can be
binned.
Christian Gollwitzer <auriocus@gmx.de>: Mar 31 07:20PM +0200

>> in boost.
 
> Boost? Ugh. That abomination should crawl away and die in a corner, its time
> has passed.
 
Regardless of Boost, I think what you describe is a circular buffer
(also called ring buffer). It can be implemented efficiently with a
fixed-size array and two pointers. You can certainly find other
implementations besides Boost.
 
Christian
Bonita Montero <Bonita.Montero@gmail.com>: Mar 31 08:00PM +0200

> on one end it automatically pops it off the other. Obviously this is simple
> to accomplish with some boiler plate size check code, but does anyone know
> if this sort of functionality has been mooted for upcoming STL versions?
 
A size-limited deque<> doens't make sense.
"Öö Tiib" <ootiib@hot.ee>: Mar 31 03:39AM -0700

On Monday, 27 March 2023 at 23:11:53 UTC+3, Pawel Por wrote:
> Hello,
 
> Assume there is a struct with a single member object. When creating the object of a struct I want the member object sometimes be copied and sometimes moved. Is the following approach correct ? Assume I don't want to use generic programing.
 
Note that destructor of Item is missing. In your example (that does nothing)
it does not matter, but in real class it should be always present when you
define any of assignment, move or copy construction. It is called "Rule of
zero, three or five".
 
Your Container lacks all of 5 (that is OK) but has implicit copy and move
conversion constructors from other class. That can cause confusion.
 
Perhaps do not use examples that do nothing. You may fail when you
attempt to write programs that do something.
 
Yes, your main() compiles but most compilers optimise all the code out of
it as it does nothing externally observable. IOW copying or moving has
only any point when there is something to copy or to move and that is used
for something meaningful. Note that also such code compiles (and does also
nothing, and so is as meaningless):
 
Item a;
Container cont = a;
Container cont2 = std::move(a);
cont = cont2;
cont = std::move(cont2);
cont2 = a;
cont2 = std::move(a);
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.

Thursday, March 30, 2023

Digest for comp.lang.c++@googlegroups.com - 15 updates in 1 topic

jak <nospam@please.ty>: Mar 30 04:00AM +0200

> A pity richie/kernigan decided to use ^ for xor. I guess they wanted to keep
> the bitwise operators as a single char but $ or @ would have been preferable.
 
For US keyboard users, this is, probably, a good idea.
Muttley@dastardlyhq.com: Mar 30 08:24AM

On Thu, 30 Mar 2023 04:00:33 +0200
>> A pity richie/kernigan decided to use ^ for xor. I guess they wanted to keep
>> the bitwise operators as a single char but $ or @ would have been preferable.
 
>For US keyboard users, this is, probably, a good idea.
 
AFAIK those 2 characters are universal on PC keyboards regardless of
language.
Paavo Helde <eesnimi@osa.pri.ee>: Mar 30 03:20PM +0300


>> For US keyboard users, this is, probably, a good idea.
 
> AFAIK those 2 characters are universal on PC keyboards regardless of
> language.
 
At Soviet times, Russians did not want to see a dollar sign on their
keyboards, so it was replaced by a general currency sign ¤
("https://en.wikipedia.org/wiki/Currency_sign_(typography)"). It still
generated ASCII 36 though IIRC.
 
In standard Estonian keyboard layout, both @ and $ are accessible with
AltGr combinations, which are pretty inconvenient to type. Ditto for
brackets and braces []{}. That's why I'm myself using US keyboards only,
I need []{} much more than õäöü.
David Brown <david.brown@hesbynett.no>: Mar 30 04:34PM +0200

On 30/03/2023 14:20, Paavo Helde wrote:
> AltGr combinations, which are pretty inconvenient to type. Ditto for
> brackets and braces []{}. That's why I'm myself using US keyboards only,
> I need []{} much more than õäöü.
 
The AltGr combinations for these symbols never bothered me on Norwegian
layout keyboards. When I moved from the UK to Norway many eons ago, it
took me a couple of weeks to get used to the changed layout, and I never
looked back. ~ is a little awkward, as it needs AltGr and it's a dead
key (thus needing a space after pressing it). But I don't see AltGr as
any harder to press than shift. I find the standard UK or US layout
restrictive and limited.
Muttley@dastardlyhq.com: Mar 30 03:19PM

On Thu, 30 Mar 2023 16:34:25 +0200
>key (thus needing a space after pressing it). But I don't see AltGr as
>any harder to press than shift. I find the standard UK or US layout
>restrictive and limited.
 
Being able to access standard ascii characters used in C/C++ is restrictive
but requiring a load of AltGr nonsense isn't?
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Mar 30 08:48AM -0700


> >For US keyboard users, this is, probably, a good idea.
> AFAIK those 2 characters are universal on PC keyboards regardless of
> language.
 
Well, AFAYK doesn't extend far enough. The variants compared in the table at
<https://en.m.wikipedia.org/wiki/ISO/IEC_646#Variant_comparison_chart>
were not created just for the fun of causing confusion. Each of those variants
was created because a fairly large group of people wanted to use keyboards
labeled with those variant characters, which could easily be used to type them,
along with monitors that would display them and printers that would print them.
Of the 60 variants compared in that chart, 21 have no '$' and 38 have no '@'.
David Brown <david.brown@hesbynett.no>: Mar 30 05:55PM +0200

>> restrictive and limited.
 
> Being able to access standard ascii characters used in C/C++ is restrictive
> but requiring a load of AltGr nonsense isn't?
 
No - and I can't see how you interpreted my post so backwards.
 
I have no problem typing ASCII symbols such as $, @, #, {} and [] - I
just use the AltGr in some cases where others might use the shift key.
I do not find it makes any noticeable difference. Of course it takes
time to change habits and muscle memory - but once you are used to it,
one position is as good as another.
 
The restrictive nature of UK and US standard layouts comes into play
when you want to type something other than plain ASCII. I can write
I²C, µF, πr², 25°C, café, naïve, 2½, «Hello», and lots of other symbols
directly from the keyboard - no need for "character applets" or other
inconveniences when typing. (And obviously I can also type the
Norwegian letters å, ø and æ easily.) I like being able to write things
correctly - spelling peoples' names with the correct accents, and using
appropriate symbols instead of being limited to a character set
marginally beyond that of a typewriter.
Muttley@dastardlyhq.com: Mar 30 04:15PM

On Thu, 30 Mar 2023 08:48:42 -0700 (PDT)
>hem.
>Of the 60 variants compared in that chart, 21 have no '$' and 38 have no '@=
>'.
 
Any modern computer keyboard that doesn't allow immediate access to the basic
7 bit ascii character set is defective.
Muttley@dastardlyhq.com: Mar 30 04:17PM

On Thu, 30 Mar 2023 17:55:46 +0200
>when you want to type something other than plain ASCII. I can write
>I²C, µF, πr², 25°C, café, naïve, 2½, «Hello», and lots of other
>symbols
 
Whatever those are they come out as gibberish in my terminal.
 
>correctly - spelling peoples' names with the correct accents, and using
>appropriate symbols instead of being limited to a character set
>marginally beyond that of a typewriter.
 
I'm sure your norwegian keyboard would be really useful for typing french
or german.
 
7 bit ASCII is the default base for any PC (or Mac). A keyboard should make
all the ascii character easily accessable.
David Brown <david.brown@hesbynett.no>: Mar 30 07:07PM +0200

>> I²C, µF, πr², 25°C, café, naïve, 2½, «Hello», and lots of other
>> symbols
 
> Whatever those are they come out as gibberish in my terminal.
 
Are you unable to view UTF-8 ? What newsreader are you using?
 
>> marginally beyond that of a typewriter.
 
> I'm sure your norwegian keyboard would be really useful for typing french
> or german.
 
It would be fine for small texts - it is perfectly able to handle the
required accented letters such as ß, ç, ü, è, etc. I don't know if
French or German typists prefer a different layout or dedicated keys for
some of the accents or accented letters that they use more often. The
same goes for any other language written using Latin characters - I can
easily type the additional Iceland or Polish letters, but someone
writing in those languages might want dedicated keys (where I have keys
for the Norwegian letters) rather than AltGr + d, t, or l.
 
Once you get to different alphabets, for languages like Bulgarian or
Greek, it's a different matter - then you'd want a different keyboard
layout entirely.
 
 
> 7 bit ASCII is the default base for any PC (or Mac). A keyboard should make
> all the ascii character easily accessable.
 
My keyboard layout handles that fine. But it does more than that - I
live in the modern international world, not insular 1970's America, and
7-bit ASCII is not sufficient.
 
I believe it is quite practical to have UK or US layouts with dead keys
too, and get easy access to a range of additional characters while
keeping braces and brackets in the position you like.
Paavo Helde <eesnimi@osa.pri.ee>: Mar 30 08:23PM +0300

30.03.2023 20:07 David Brown kirjutas:
 
> I believe it is quite practical to have UK or US layouts with dead keys
> too, and get easy access to a range of additional characters while
> keeping braces and brackets in the position you like.
 
Yes, that's the setup I'm using. Quote characters and tilde come via
dead keys this way, but I'm used to that.
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Mar 30 10:39AM -0700

> On Thu, 30 Mar 2023 08:48:42 -0700 (PDT)
> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> wrote:
...
> >'.
 
> Any modern computer keyboard that doesn't allow immediate access to the basic
> 7 bit ascii character set is defective.
 
I'm sure that's true for you. However, those variants exist precisely because there are other people who would consider any keyboard which doesn't allow immediate access to their preferred variant to be defective.
scott@slp53.sl.home (Scott Lurndal): Mar 30 05:53PM


>I'm sure that's true for you. However, those variants exist precisely becau=
>se there are other people who would consider any keyboard which doesn't all=
>ow immediate access to their preferred variant to be defective.
 
Muttley appears to be British, and many brits still believe the sun doesn't
set on the empire. That's no longer the case.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Mar 30 08:14PM +0100

> names with the correct accents, and using appropriate symbols instead of
> being limited to a character set marginally beyond that of a
> typewriter.
 
I think you are bundling more that is warranted into the phrase "UK and
US standard layouts". I have an entirely standard UK layout, but I can
type those characters with ease. The OS and it's input methods have
more to do with it than what I would call the "layout", but maybe I'm
missing something from what you mean by the term.
 
I don't think you will convince Muttley. There's a particular Internet
clan who see facilitating typing (or, God forbid, posting) non-ASCII
characters as the thin end of some subversive socialist wedge. First
they let you type an acute accent, but then they come for your guns!
 
--
Ben.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Mar 30 08:21PM +0100

>>ow immediate access to their preferred variant to be defective.
 
> Muttley appears to be British, and many brits still believe the sun doesn't
> set on the empire. That's no longer the case.
 
I am sad for my country's recent dive into xenophobic politics, but that
imperial attitude is not common among those young enough to know what an
emoji is! I thought Muttley was from the USA as ASCII-nationalism has,
historically, been more common in the US than in the UK.
 
--
Ben.
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.

Wednesday, March 29, 2023

Digest for comp.lang.c++@googlegroups.com - 18 updates in 3 topics

"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Mar 29 01:42PM +0200

On 2023-03-27 7:59 PM, Jason Vas Dias wrote:
> 8707 2203 (1 1) ∃ 'THERE EXISTS'
> 8708 2204 (1 1) ∄ 'THERE DOES NOT EXIST'
 
> Why can't I use these characters in identifiers ?
 
Unless changed in the most recent versions, g++ directly only allows
ASCII in identifiers, though it does support Unicode escapes (formally
universal character names) that denote non-ASCII characters.
 
The g++ behavior is -- or was -- essentially the rules of C, instead
of the rules of C++.
 
I'm being careful talking about versions because others have posted
commentary indicating that the g++ compiler they use, supports non-ASCII
characters in identifiers. I'm pretty sure they're wrong about that. But
there is the possibility of such support having been added recently.
 
 
> Would there be any support for submitting an RFC to the standards groups
> to allow implementations to have some sort of local UTF-8 character
> white-list policy ?
 
That discussion is now on mailing-lists. Originally it was in the now
defunct Usenet group comp.std.c++; then it was moved to Google groups;
then to mailing lists. Modulo possible changes (like, moved again) you
can find those lists at <url: http://isocpp.org>, somewhere.
 
 
> ie. I'd like to develop extensions for GCC and Clang that will allow them
> to load a UTF-8 character White-List file , then these characters would be
> allowed regardless of what the standards say about valid identifier characters.
 
Well the one I sorely miss is the up-arrow, ↑, to denote exponentiation.
 
But then, even if it was allowed, the usual technique of `%OP%` for
pseudo-operator yields precedence like % (remainder) which is not ideal.
 
Instead C++ should get support for exponentiation operator, possibly
`**` like Python.
 
 
> Next step is getting a complete dump of what GCC and Clang consider to
> be valid UTF-8 identifier characters, which is not as straightforward as it
> should be.
 
g++ is presumably dead easy; see above. :(
 
 
> I'd most appreciate any helpful advice / informative comments.
 
 
- Alf
David Brown <david.brown@hesbynett.no>: Mar 29 02:23PM +0200

On 29/03/2023 13:42, Alf P. Steinbach wrote:
 
> Unless changed in the most recent versions, g++ directly only allows
> ASCII in identifiers, though it does support Unicode escapes (formally
> universal character names) that denote non-ASCII characters.
 
It changed with gcc 10, which is about 3 years old. (I don't know if
you consider that "recent" or not.)
 
> The g++ behavior is  --  or was -- essentially the rules of C, instead
> of the rules of C++.
 
C and C++ are, AFAIK, basically aligned on this - C has supported
"universal character names" since C99, and C++ had it in C++98.
Different compilers have had different levels of support, with clang
being relatively early in having full UTF-8 input support while gcc only
supported escape sequences (for C and C++) until gcc 10.
 
> commentary indicating that the g++ compiler they use, supports non-ASCII
> characters in identifiers. I'm pretty sure they're wrong about that. But
> there is the possibility of such support having been added recently.
 
Version 10 is the magic number.
 
> pseudo-operator yields precedence like % (remainder) which is not ideal.
 
> Instead C++ should get support for exponentiation operator, possibly
> `**` like Python.
 
That's a feature many have called for, in C and C++, spanning decades.
 
>> straightforward as it
>>   should be.
 
> g++ is presumably dead easy; see above. :(
 
It's not particularly easy. GCC adds $ to the ASCII characters it
accepts as letters in identifiers (for most targets - there are some
targets for which $ is critically significant for the generated
assembly). Other than that, it follows the standard, with letters
defined in the XID_Start and XID_Continue classes in Unicode:
 
<https://www.unicode.org/reports/tr31/#Table_Lexical_Classes_for_Identifiers>
 
 
 
Muttley@dastardlyhq.com: Mar 29 01:38PM

On Wed, 29 Mar 2023 13:42:15 +0200
>Instead C++ should get support for exponentiation operator, possibly
>`**` like Python.
 
A pity richie/kernigan decided to use ^ for xor. I guess they wanted to keep
the bitwise operators as a single char but $ or @ would have been preferable.
Muttley@dastardlyhq.com: Mar 29 01:41PM

On Wed, 29 Mar 2023 14:23:25 +0200
>> Instead C++ should get support for exponentiation operator, possibly
>> `**` like Python.
 
>That's a feature many have called for, in C and C++, spanning decades.
 
Given how long it took to (officially) include 0b for binary literals I won't
be holding my breath. The amount of time that it could have personally saved
me in the past by not having to convert binary into hex and back would be
significant.
"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Mar 29 07:03PM +0200

On 2023-03-29 2:23 PM, David Brown wrote:
>> universal character names) that denote non-ASCII characters.
 
> It changed with gcc 10, which is about 3 years old.  (I don't know if
> you consider that "recent" or not.)
 
Oh. Thanks.
 
"
[C:\root\temp]
> g++ --version
g++ (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
[C:\root\temp]
> bash
alf@Alf-Windows-PC:/mnt/c/root/temp$ g++ --version
g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
"
 
So how does that go for Ubuntu, like "sudo apt update something something"?
 
 
> Different compilers have had different levels of support, with clang
> being relatively early in having full UTF-8 input support while gcc only
> supported escape sequences (for C and C++) until gcc 10.
 
I meant the rules for identifiers.
 
 
[snip]
> assembly).  Other than that, it follows the standard, with letters
> defined in the XID_Start and XID_Continue classes in Unicode:
 
> <https://www.unicode.org/reports/tr31/#Table_Lexical_Classes_for_Identifiers>
 
Most if not all extant compilers support `$`. Which I know because Herb
Sutter, the C++ standardization committee chair, once tried /using/ it
for some library stuff, and unlike my earlier efforts he got a lot of
people to try it and give feedback on it. The main problem wasn't
compilers but that some companies used `$` in their own preprocessing.
 
Probably the reason $ is not there in the C++ basic character set is the
destructively silly political argumentation that resulted in an
"international" version of ASCII with the not-used-ever-since-by-anybody
"international currency symbol" ¤ instead; <url:
https://en.wikipedia.org/wiki/Currency_sign_(typography)#History>.
 
The same kind of sensitivity-oriented people that now are removing scary
wording from Roald Dahl's novels and are on their way to ban "1984".
 
Mumble, mumble...
 
Anyway thanks!
 
I'll at least update the Windows MinGW version of g++, probably as easy
as downloading the Nuwen distro (maintained by STL over at Microsoft).
 
- Alf
David Brown <david.brown@hesbynett.no>: Mar 29 08:25PM +0200

On 29/03/2023 19:03, Alf P. Steinbach wrote:
 
>> It changed with gcc 10, which is about 3 years old.  (I don't know if
>> you consider that "recent" or not.)
 
> Oh. Thanks.
 
No problem. Some of us have an unhealthily detailed knowledge of these
things - it's nice when that knowledge helps someone!
 
You can always test on <https://godbolt.og>.
 
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> "
 
> So how does that go for Ubuntu, like "sudo apt update something something"?
 
I believe gcc 10 is in the Ubuntu 20.04 packages:
 
apt update
apt install gcc-10
 
You'll still have standard gcc 9.x by default, and run gcc 10 as g++-10.
 
>> being relatively early in having full UTF-8 input support while gcc
>> only supported escape sequences (for C and C++) until gcc 10.
 
> I meant the rules for identifiers.
 
So did I - that's what I was talking about (not run-time character set
support).
 
> for some library stuff, and unlike my earlier efforts he got a lot of
> people to try it and give feedback on it. The main problem wasn't
> compilers but that some companies used `$` in their own preprocessing.
 
There are dozens of C++ compilers (and hundreds of C compilers) in use,
most of which neither you nor Sutter will have ever used, because they
are for embedded systems. Some support $, others do not. gcc supports
it, but some targets might not like it in their assembler. In
particular, many assemblers use $ to indicate hex literals, others use
it for register names. You might find that "a$" is fine, but "$0" is not.
 
Of course most code doesn't need to be fully portable, and $ in
identifiers will work fine for any toolchain most programmers are likely
to meet.
 
> "international" version of ASCII with the not-used-ever-since-by-anybody
> "international currency symbol" ¤ instead; <url:
> https://en.wikipedia.org/wiki/Currency_sign_(typography)#History>.
 
No, it is about compatibility with assemblers - when the C basic
character set was determined, $ was in heavy but inconsistent use in
many assemblers of the time. Allowing it as a letter in identifiers
would have made things a lot more complicated.
 
"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Mar 29 09:07PM +0200

On 2023-03-29 8:25 PM, David Brown wrote:
> character set was determined, $ was in heavy but inconsistent use in
> many assemblers of the time.  Allowing it as a letter in identifiers
> would have made things a lot more complicated.
 
Oh. I remember '@' for PDP-11 assembly and '$' for HP-3000 system
functions, but nothing about '$' for assembly. Learned something. :)
 
- Alf
Sam <sam@email-scan.com>: Mar 29 03:22PM -0400

Alf P. Steinbach writes:
 
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> "
 
> So how does that go for Ubuntu, like "sudo apt update something something"?
 
I don't have an Ubuntu box, at this moment, but it should be "sudo apt
install g++-10". Ubuntu packages multiple versions of gcc, you would use
g++-10 to compile, etc…
scott@slp53.sl.home (Scott Lurndal): Mar 29 07:32PM

>> would have made things a lot more complicated.
 
>Oh. I remember '@' for PDP-11 assembly and '$' for HP-3000 system
>functions, but nothing about '$' for assembly. Learned something. :)
 
VMS heavily used $ in system call names at source level (e.g. C/Pascal SYS$QIOW)
and in MACRO-32 identifiers ($QIOW).
"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Mar 29 11:16PM +0200

On 2023-03-29 9:22 PM, Sam wrote:
 
> I don't have an Ubuntu box, at this moment, but it should be "sudo apt
> install g++-10". Ubuntu packages multiple versions of gcc, you would use
> g++-10 to compile, etc…
 
Ah. Better. I should really have fixed the prompt and got an X-server
running in WSL (I know it's possible), and so on, but.
 
 
alf@Alf-Windows-PC:/mnt/c/root/temp$ (g++ --version; g++-10 --version) |
grep "++"
g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
g++-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0
 
 
- Alf
Charlie R <charlier33@wp.pl>: Mar 29 10:05AM

From the derived class, I want to access my base class - the actual
*object* of the base-class part of this.
 
One thing that DOES work is to static_cast the (this) pointer into the
base class type, but that seems very sketchy (is this even always
correct?).
 
Example - how to fix the 2 "fail" lines?
 
#include <iostream>
 
class base {
public:
operator int() const { return 123; }
};
 
class child : public base {
public:
void show() {
std::cout << this->base::operator int() <<
"\n"; // works
std::cout << this->base << "\n"; // fails - I
want to refer to my parent object
base & parentobj = this->base; // fails too
base & parentobj2 = *
static_cast<base*>(this); // works... ugly?
}
};
 
int main() {
child obj;
obj.show();
}
Ralf Fassel <ralfixx@gmx.de>: Mar 29 12:13PM +0200

* Charlie R <charlier33@wp.pl>
| From the derived class, I want to access my base class - the actual
| *object* of the base-class part of this.
 
| One thing that DOES work is to static_cast the (this) pointer into the
| base class type, but that seems very sketchy (is this even always
| correct?).
 
| Example - how to fix the 2 "fail" lines?
--<snip-snip>--
| std::cout << this->base << "\n"; // fails - I want to refer to my parent object
 
std::cout << this->operator int() << "\n";
std::cout << operator int() << "\n";
 
| base & parentobj = this->base; // fails too
 
base & parentobj = *this;
std::cout << parentobj.operator int() << "\n";
 
HTH
R'
Charlie R <charlier33@wp.pl>: Mar 29 10:21AM

Wed, 29 Mar 2023 12:13:14 +0200, Ralf Fassel:
 
> parent object
 
> std::cout << this->operator int() << "\n";
> std::cout << operator int()
 
thanks.
Though, what when we have 2 base classes and both have int() conversion
operator?
 
Is there no direct way of saying "take my base object X" in an expression?
Is using the static_cast<type_of_base_class*>(this) the valid way?
 
Sam <sam@email-scan.com>: Mar 29 06:51AM -0400

Charlie R writes:
 
 
> thanks.
> Though, what when we have 2 base classes and both have int() conversion
> operator?
 
base1 &obj = *this;
 
or
 
base2 &obj = *this;
 
Then obj.operator int().
 
> Is there no direct way of saying "take my base object X" in an expression?
> Is using the static_cast<type_of_base_class*>(this) the valid way?
 
A cast is the only way to convert X to Y, in an expression.
"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Mar 29 01:46PM +0200

On 2023-03-29 12:21 PM, Charlie R wrote:
> operator?
 
> Is there no direct way of saying "take my base object X" in an expression?
> Is using the static_cast<type_of_base_class*>(this) the valid way?
 
You can and should then do
 
Base::operator int()
 
... or in external code
 
obj.Base::operator int()
 
- Alf
Charlie R <charlier33@wp.pl>: Mar 29 10:13AM

Thu, 16 Mar 2023 11:38:20 +0100, Bo Persson:
 
 
>> It would only be a small gain in efficiency but might be useful.
 
> There is already a proposal for this:
 
> https://wg21.link/p2169
 
std::lock_guard _(mutex1);
...
std::lock_guard _(mutex2);
...
auto [x, y, _] = f();
auto [a, b, _] = g();
 
I wonder how debugger should show me this 4 placeholders at end when I
look at local variables. Probably some weird internal names like with
lambdas. Would that even be a problem or what to do there...?
Muttley@dastardlyhq.com: Mar 29 10:25AM

On Wed, 29 Mar 2023 10:13:39 -0000 (UTC)
 
>I wonder how debugger should show me this 4 placeholders at end when I
>look at local variables. Probably some weird internal names like with
>lambdas. Would that even be a problem or what to do there...?
 
Perhaps the same way it deals with temporaries now? Whatever that is, I don't
actually know how any of the debuggers represent them.
Bo Persson <bo@bo-persson.se>: Mar 29 01:23PM +0200

On 2023-03-29 at 12:13, Charlie R wrote:
 
> I wonder how debugger should show me this 4 placeholders at end when I
> look at local variables. Probably some weird internal names like with
> lambdas. Would that even be a problem or what to do there...?
 
If you want them to have nice names, you are free to insert those names.
Using _ as a name means that you don't care about those objects.
 
 
So why care about things we don't care about? :-)
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.

Tuesday, March 28, 2023

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

Paavo Helde <eesnimi@osa.pri.ee>: Mar 28 03:40PM +0300

27.03.2023 23:11 Pawel Por kirjutas:
 
 
> Container(const Item& item) : item(item) {} // copying
> Container(Item&& item) : item(std::move(item)) {} // moving
> };
 
Yes, that's about how it goes.
 
If anything, naming both the member and the constructor parameter with
the same name does not help readability (but works as intended, in the
member initialization list).
David Brown <david.brown@hesbynett.no>: Mar 28 09:10AM +0200

On 27/03/2023 21:08, Scott Lurndal wrote:
 
> Actually, there's something to be said for sticking to the
> portable character set for identifiers, such that the current locale
> and or character set settings don't matter when compiling the source.
 
I think if you are writing modern code, then it is pretty safe to assume
that UTF-8 is fine as a source character set. But you might have to
jump through some option flag hoops to make it work on some Windows tools.
 
There are two real disadvantages to using non-ASCII characters in
identifiers. One is that they can be hard to distinguish in some cases
- which of these is "complement" and which is "capital c"? "∁" "C"
 
The other is a matter of how you type the letters. If you speak Greek
and have a Greek keyboard layout, typing Greek letters for identifiers
is fine - if you have a Norwegian keyboard layout like mine, it's a
pain. I don't know of any layouts with ∀ and ∃ in them - if you use
them a lot, you'll want your own custom compose key combinations. But
even if the code author can get the symbols, people using or maintaining
the code might have trouble.
 
 
Still, we miss out on some fun opportunities when C and C++ only allow
letters, not symbols, in identifiers. It's entirely possible in C++ to
make your own pseudo-operators - identifiers that can be used prefix,
infix or postfix rather than as function calls. So you can make a
vector class and write "a crossproduct b" or "a dotproduct b", but you
are not allowed to write "#define × crossproduct" and "#define ·
dotproduct" to make it nicer in the source code.
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.

Monday, March 27, 2023

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

Pawel Por <porparek@gmail.com>: Mar 27 01:11PM -0700

Hello,
 
Assume there is a struct with a single member object. When creating the object of a struct I want the member object sometimes be copied and sometimes moved. Is the following approach correct ? Assume I don't want to use generic programing.
 
#include <utility>
 
struct Item
{
Item() {}
Item(const Item&) {}
Item(Item&&) {}
 
Item& operator=(const Item&) { return *this; }
Item& operator=(Item &&) { return *this; }
};
 
struct Container
{
Item item;
 
Container(const Item& item) : item(item) {} // copying
Container(Item&& item) : item(std::move(item)) {} // moving
};
 
 
int main(int argc, char **argv)
{
Item a;
 
Container cont(a); // copying
Container cont2(std::move(a)); // moving
 
return 0;
}
Jason Vas Dias <jason.vas.dias@ptt.ie>: Mar 27 10:59AM -0700

Good day -
 
I'd really like to be able to define functions with names like :
∀() (\U{FOR_ALL}), or ⭮() , or ⭯() , or :
8704 2200 (1 1) ∀ 'FOR ALL'
8705 2201 (1 1) ∁ 'COMPLEMENT'
8707 2203 (1 1) ∃ 'THERE EXISTS'
8708 2204 (1 1) ∄ 'THERE DOES NOT EXIST'

Why can't I use these characters in identifiers ?
 
Would there be any support for submitting an RFC to the standards groups
to allow implementations to have some sort of local UTF-8 character
white-list policy ?
 
ie. I'd like to develop extensions for GCC and Clang that will allow them
to load a UTF-8 character White-List file , then these characters would be
allowed regardless of what the standards say about valid identifier characters.
 
Next step is getting a complete dump of what GCC and Clang consider to
be valid UTF-8 identifier characters, which is not as straightforward as it
should be.
 
I'd most appreciate any helpful advice / informative comments.
 
Thanks & Best Regards,
Jason
Richard Damon <Richard@Damon-Family.org>: Mar 27 03:02PM -0400

On 3/27/23 1:59 PM, Jason Vas Dias wrote:
 
> I'd most appreciate any helpful advice / informative comments.
 
> Thanks & Best Regards,
> Jason
 
My understanding is that C++ basically just took the set of characters
for identifiers from the recommendation of the Unicode Standard for
"Identifiers" (XID_Start, XID_Continue). All the characters you
mentioned are defined (I beleive) as operators.
 
My one thought is that the Standard Committee wants to reserve the
operators from being identifies in case at some point a method is
defined to add new operators.
 
My guess is that GCC and Clang just implement the set defined by the
standard, which means going to the UNICODE standard that is applicable
for that compiler and looking at its definition of those classes. I
wouldn't be surprised if the build process just has as an input, the
Unicode class definition file, and a program that parses it to build the
needed code for the various things that need that information.
 
Of course, there is nothing to prevent an implementation from accepting
additional characters (possibly with a warning or an option) beyond the
defined set.
scott@slp53.sl.home (Scott Lurndal): Mar 27 07:08PM


>My one thought is that the Standard Committee wants to reserve the
>operators from being identifies in case at some point a method is
>defined to add new operators.
 
Actually, there's something to be said for sticking to the
portable character set for identifiers, such that the current locale
and or character set settings don't matter when compiling the source.
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.