Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Fri, 24 May 2024 16:39:02 +0200
Organization: A noiseless patient Spider
Lines: 88
Message-ID: <v2q8q6$2c8rq$1@dont-email.me>
References: <v2l828$18v7f$1@dont-email.me> <v2lfvr$1ahhf$1@dont-email.me>
 <v2liar$1avch$1@dont-email.me> <v2oi6f$1vfk7$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 24 May 2024 16:39:03 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="aa31083d92649562fe347cd52a2a5ec5";
	logging-data="2499450"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19RnSe1sU53jjnMXztCcokPcDEfgbTWPLg="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:LJUeZMjd6olVI//qMHnXaOTtd1M=
Content-Language: en-GB
In-Reply-To: <v2oi6f$1vfk7$1@dont-email.me>
Bytes: 4739

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.