Re: C23 thoughts and opinions

On 24/05/2024 01:06, Malcolm McLean wrote:

On 22/05/2024 20:50, David Brown wrote:

On 22/05/2024 21:10, Malcolm McLean wrote:

>
But even boolean type and const.

>
Const documents the code, makes the action of a function clearer to the reader, and helps catch mistakes.
>
These are all things that make the language better, and have done so for the past 25 years.
>

Of course quite alot of the functions don't actually change the structures they are passed. But is littering the code with const going to help? And why do you really need a boolean when an int can hold either a zero or non-zero value?
>
And don't you just want a pared down, clean language?
>

>
I want a language with the features I need and that help me to write good clear code.  Minimal is not helpful, any more than needlessly complex is helpful.
>

 So the code I'm working on at the moment.
 It's an implemention of XPath (a subset, of course). XPath is sort of query language for XML. You pass a query string like "/bookstore/book//title" and that selects all children of [root]/bookstore/book with the element tag "title".
 Now querying the document shouldn't change it. So in C++ it should bepassed in as a XMLDOC const &. In C, declaring the pointer a const XMLDOC * conveyes the intention, but doesn't actually achieve the safety you want and get with C++.

The safety is the same in C and C++ (unless your C++ code provides const and non-const overloads for the function).  References in C++ don't let you pass a null pointer, but you can "cast away" the const in a const reference as easily as you can remove the const in a const pointer:
void naughty(const int & x) {
     int & y = (int &) x;
     y++;
}
In both cases, the "const" is a promise to the reader and a promise to the compiler, but you can break that promise if you do so explicitly.

 However the algorithm I have just moved to needs a bit associated with each node it can turn on and of. Now in fact I did this via a hash table. But it is very tempting and far more efficient to simply add a hacky field to the XMLNODE structure - after all, I wrote the XML parser. And in C++ "mutable" is designed for just this. But in C,
were're either const or not. And isn't it maybe better to leave the const qualifier off the document pointer?

"mutable" is just a kosher way of breaking your const promises.  In cases where "mutable" might be useful, I generally prefer to differentiate between the part of structure that is fixed and unchanging, and the part that is more volatile status.  (This can also be better from the viewpoint of cache friendliness, if that is of concern.)  But if I had a situation where C++ "mutable" would be the best choice, and I had to implement it in C without "mutable", I am not sure that casting to non-const in the implementation function would be must worse.

 In fact, wouldn't we just be better off without const?

No.
We'd be better off having everything const - /really/ constant - by default, and having to explicitly declare the few things that actually have to be changed after initialisation.  That's how many modern programming languages do it.

After all, you need to read the function specifications anyway, and they should say that querying for a path will not alter the document.
 

/Never/ write things in comments or documentation if you can express the same thing in code.