Thursday, August 25, 2022

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

"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Aug 25 07:34AM +0200

On 24 Aug 2022 22:48, Ben Bacarisse wrote:
 
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf
 
> I didn't know that, but I am not surprised because of the new course C
> is taking. I hope it does not run aground...
 
It's apparently the same as with C++: not very practical academics in
charge, expressing their academic ideals. Idealism is a kind of advanced
sabotage. Usually.
 
- Alf
David Brown <david.brown@hesbynett.no>: Aug 25 09:21AM +0200

On 24/08/2022 22:48, Ben Bacarisse wrote:
 
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf
 
> I didn't know that, but I am not surprised because of the new course C
> is taking. I hope it does not run aground...
 
Some of the C23 changes are obvious and practical, such as "volatile
semantics for lvalues" (embedded developers have been relying on this
for decades, so it's nice to see it standardised), and the
standardisation of "#warning" (again, something that people have used
for decades).
 
But there has definitely been a change in the principles. C23 makes
"bool" the type and keyword, with "_Bool" as the "alternative spelling".
Similarly we now have "static_assert", "alignas", etc. "void foo();"
now means "void foo(void);". There are many things like this that
arguably make C a slightly better and neater language, and will not harm
anyone who has been writing decent C99 code over the past couple of
decades. But C has a history older than that - and backwards
compatibility is a prime reason the language is still alive and kicking.
 
I suppose that we can rely on gcc to follow the fine tradition of
supporting old, outdated and dangerous constructs when invoked without
specific standards or warning flags - I expect it to still work with
code that has "typedef int bool;" for a long time to come.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Aug 25 11:29AM +0100

>> is taking. I hope it does not run aground...
 
> It's apparently the same as with C++: not very practical academics in
> charge,
 
Who, in particular, do you mean?
 
> expressing their academic ideals.
 
In what way is making bool a type keyword expressing an academic ideal?
My thoughts were the reverse: the "purist" route -- of only using
already reserved identifiers -- has been ditched.
 
--
Ben.
Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Aug 25 04:14AM -0700

On Thursday, 25 August 2022 at 11:29:26 UTC+1, Ben Bacarisse wrote:
 
> In what way is making bool a type keyword expressing an academic ideal?
> My thoughts were the reverse: the "purist" route -- of only using
> already reserved identifiers -- has been ditched.
 
Low level, practical programmers tend to think of programming in terms
of manipulating bits in memory.
Academic computer science people tend to think of programming in terms
of manipulating symbols.
So a practical programmer will tend to say "set that bit to indicate the light is
on", a computer scientist will say "bind that variable to true/false to indicate
the status of the light".
Ben Bacarisse <ben.usenet@bsb.me.uk>: Aug 25 12:36PM +0100

>> already reserved identifiers -- has been ditched.
 
> Low level, practical programmers tend to think of programming in terms
> of manipulating bits in memory.
 
Are you equating the two or just ignoring high-level practical
programmers?
 
Anyway, as always, I am curious about how you know this.
 
> Academic computer science people tend to think of programming in terms
> of manipulating symbols.
 
I suspect this is simply self-defining. Any academic CS person who,
say, designs a RISK architecture or a low-level network protocol, will
be excused and be deemed to be practical, yes?
 
> So a practical programmer will tend to say "set that bit to indicate
> the light is on", a computer scientist will say "bind that variable to
> true/false to indicate the status of the light".
 
I think you are making this us. CS people who set bits to indicate
things just like everyone else.
 
Does any of this have anything to do with the C standards apparent
change of direct to incorporate C++ features at the expense of old code?
 
--
Ben.
Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Aug 25 05:16AM -0700

On Thursday, 25 August 2022 at 12:37:11 UTC+1, Ben Bacarisse wrote:
> Are you equating the two or just ignoring high-level practical
> programmers?
 
> Anyway, as always, I am curious about how you know this.
 
I used to be a games programmer. I gave it up to do a degree which led to a PhD.
Whilst I didn't do computer science, and the PhD was in protein folding, it did
involve quite a bit of interaction with computer scientists. So I'm reasonably
familiar with both worlds.
> I suspect this is simply self-defining. Any academic CS person who,
> say, designs a RISK architecture or a low-level network protocol, will
> be excused and be deemed to be practical, yes?
 
There's an overlap between computer science, practical programming, and
electronic engineering. But they're not the same.
 
> Does any of this have anything to do with the C standards apparent
> change of direct to incorporate C++ features at the expense of old code?
 
Computer science people would tend to think that it's important to have
a boolean type, because a lot of logic works on values which are inherently
true or false. Practical programmers would tend to say that it's not, because
most hardware won't support it. You will of course find exceptions.
scott@slp53.sl.home (Scott Lurndal): Aug 25 12:58PM

>supporting old, outdated and dangerous constructs when invoked without
>specific standards or warning flags - I expect it to still work with
>code that has "typedef int bool;" for a long time to come.
 
gcc 4.9 will be around forever. (an example, but really, the older
C compilers will not go away just because C23 shows up).
Ben Bacarisse <ben.usenet@bsb.me.uk>: Aug 25 05:16PM +0100

> to a PhD. Whilst I didn't do computer science, and the PhD was in
> protein folding, it did involve quite a bit of interaction with
> computer scientists. So I'm reasonably familiar with both worlds.
 
OK. So it's your based on your experience. My experience is different.
 
>> be excused and be deemed to be practical, yes?
 
> There's an overlap between computer science, practical programming, and
> electronic engineering. But they're not the same.
 
Sure. In fact, any academic who may /think/ they are a computer
scientist will be excluded from your definition if they lean towards
something you think is practical. You can't really be wrong, can you?
 
 
> Computer science people would tend to think that it's important to have
> a boolean type, because a lot of logic works on values which are inherently
> true or false.
 
C already has a Boolean type. The question was whether renaming it bool
is the result of fanatical academic interference in the standard.
That's what I was asking about.
 
--
Ben.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Aug 25 10:06AM -0700

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> a boolean type, because a lot of logic works on values which are inherently
> true or false. Practical programmers would tend to say that it's not, because
> most hardware won't support it. You will of course find exceptions.
 
Many practical programmers would tend to say it's important to have a
boolean type because it makes it easier to write clear code. (Some
probably prefer to use zero and non-zero rather than explicit bool,
false, and true.)
 
Why would a "practical programmer" care whether there's direct hardware
support for bool? If the compiler handles it correctly, it just works.
In a very real sense, all hardware supports booleans, with more or less
work required by the compiler.
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Aug 25 10:23AM -0700

> On 24/08/2022 22:48, Ben Bacarisse wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> supporting old, outdated and dangerous constructs when invoked without
> specific standards or warning flags - I expect it to still work with
> code that has "typedef int bool;" for a long time to come.
 
Remember that C99 removed implicit int, which in principle broke a lot
of existing code. Most compilers continued to accept implicit it in
some mode, perhaps with a non-fatal warning.
 
Code that uses bool, false, and true as identifiers is going to be a
little trickier to handle in lexical analysis and parsing.
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Aug 25 10:32AM -0700

On Thursday, 25 August 2022 at 18:06:45 UTC+1, Keith Thompson wrote:
> boolean type because it makes it easier to write clear code. (Some
> probably prefer to use zero and non-zero rather than explicit bool,
> false, and true.)
 
It does document that a value is logically bi-valued. So we can enable or disable
a button, but we can't have it in a half-enabled state. However the problem is
that when you look at C++ code which uses booleans, it's not clear what is
being passed
e.g. if you see
Button mybutton("OK", &rect, true);
Obviously this is creating a button. Obviously it's got the display text "OK". Obviously
rect is some sort of rectangle containing the position. But what is "true"?
If we make enabled / disabled an enum, then it's more clear what the code is doing.
> support for bool? If the compiler handles it correctly, it just works.
> In a very real sense, all hardware supports booleans, with more or less
> work required by the compiler.
 
Well one issue is whether if (flag == true) works as expected. If the hardware supports
1 bit types, then it must work, because flag cannot have any bit pattern other than
bit clear / bit set. If bool is something provided by software, and the underlying type
is an integer, then it might hold unexpected values.
A theoretical person doesn't really have to worry about this, because in his world, all
bools are initialised to 1 or 0 and all operations on them yield 1 or 0. In the practical
programmer's world, things can get more messy, because some of the code might
be written in another language, for example.
David Brown <david.brown@hesbynett.no>: Aug 25 08:35PM +0200

On 25/08/2022 18:16, Ben Bacarisse wrote:
 
>>>>>> It's apparently the same as with C++: not very practical academics in
>>>>>> charge,
>>>>> Who, in particular, do you mean?
 
A large proportion of the new features in C23 seem to have originated
with or been promoted by one person - Jens Gustedt. I don't know if he
should be considered an "academic", or a "practical programmer", or
both, or neither. But while most of the C standards committee tend to
be quite anonymous and avoid making changes to the standard (they all
have day jobs, after all), he seems to be working hard to change C and
bring it forward. People can have different opinions on whether that's
a good idea or not, and about the particular changes he has proposed,
but I think he is due a large share of the credit for C23.
 
>> Computer science people would tend to think that it's important to have
>> a boolean type, because a lot of logic works on values which are inherently
>> true or false.
 
When I did theoretical computer science at university, we used whatever
type was convenient and appropriate for the task at hand (and more often
than not it was "alpha" or "A", rather than any specific type). And
that was for "there's no need to test the code, because we prove it is
correct on the blackboard" programming, which is as academic as it comes.
 
In my job as a practical programmer - mostly low-level, but sometimes
high-level (however those terms might be defined), I use whatever type
is convenient and appropriate for the task at hand. And "bool" is one
of the most common types I use.
 
For my own coding, I don't really care whether "bool" is a typedef for
"_Bool" or a keyword in itself, nor do I care if "true" and "false" are
keywords, macros, enums, or whatever, as long as they work correctly.
However, if these are all keywords in a language, then it gives me a
guarantee that code from elsewhere uses these types and values in
exactly the same way. I don't need to check that the code I import has
defined "typedef enum { uninitialised, true, false } bool;", or some
other incompatible fun. So from that viewpoint, having these as
keywords can be helpful in practice.
 
But that's /my/ experience - Malcolm's is apparently different.
 
> C already has a Boolean type. The question was whether renaming it bool
> is the result of fanatical academic interference in the standard.
> That's what I was asking about.
 
I would have thought there were other changes in C23 (and even more so,
some of the proposals that didn't make it into the standard) were better
candidates for the title of "fanatical academic interference". But
perhaps Malcolm sees things differently.
JiiPee <kerrttuPoistaTama11@gmail.com>: Aug 25 08:11PM +0300

I had this situation many times, that I wanted to use friend in class
but I dont want friend be able to get
access to ALL members, only maybe one function. I wish there was a
feature in C++ like this:
 
class Parent
{
private:
void foo() { : friend Child // new feature
}

void foo2() {
}
};
 
and now Child can get access to foo() and ONLY it:
 
class Child
{
public:
Parent* m_parent{nullptr}; // later initialized ...
void foo3() {
// Can access only foo()
m_parent->foo(); // this is OK
// cannot access any other privates
m_parent->foo2(); // this is NOT OK
}
};
 
Can anybody suggest this to Bjarne? hehe
"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Aug 25 08:13PM +0200

On 25 Aug 2022 19:11, JiiPee wrote:
>         m_parent->foo2(); // this is NOT OK
>     }
> };
 
You can easily work around that limitation, like this:
 
 
class Child;
 
class Parent
{
public:
class Restricted
{
friend class Child;
 
static void foo( Parent& self ) //: friend Child
{
self.foo();
}
};
 
private:
void foo() {}
void foo2() {}
};
 
class Child
{
public:
Parent* m_parent{nullptr}; // later initialized ...
 
void foo3() {
// Can access only foo()
Parent::Restricted::foo( *m_parent ); // this is OK
// cannot access any other privates
#ifdef FAIL
m_parent->foo2(); // this is NOT OK
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)