Saturday, October 8, 2022

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

"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Oct 08 02:56PM +0200

On 7 Oct 2022 11:47, Juha Nieminen wrote:
> I have encountered this small dilemma several times. It's a question of
> const correctness and proper OO design in C++.
 
> Should a virtual function in a base class be const or not? [snip]
 
Others have already answered this to my mind satisfactorily.
 
However, consider also the case of whether a non-virtual member function
should be `const` or not.
 
One possible dilemma is proxy class like the one returned by
`std::vector<bool>::operator[]`, where its assignment operator can and
in my opinion should be `const` because it doesn't modify /that/ object,
 
class Proxy
{
public:
auto operator=( const bool value ) const -> Proxy;
};
 
But the whole point of assignment is to modify an object, in this case
the real `vector`. So I guess a case can be made that the assignment
operator should not be `const`. E.g., the state that's observable via
this proxy object, changes as a result of an assignment to it.
 
The reason that I think it should be `const` is that the `const` adds a
constraint that can be useful for programmers: that /this/ object's
internal non-`mutable` state doesn't change.
 
Nothing about "visible" state or that; for this case it's all about
internal object state.
 
Then if one doesn't accept that as a universal criterion, and I DON'T,
then the question is what is it that makes classes different in this
respect?
 
I have no good answer.
 
 
- Alf
Bonita Montero <Bonita.Montero@gmail.com>: Oct 08 04:35PM +0200

There is no general answer or it depends on what you expect from
this interface. In individual cases, this question is then easy
to answer and therefore I do not know why it has to be discussed.
Michael S <already5chosen@yahoo.com>: Oct 08 11:03AM -0700

On Saturday, October 8, 2022 at 5:35:51 PM UTC+3, Bonita Montero wrote:
> There is no general answer or it depends on what you expect from
> this interface. In individual cases, this question is then easy
> to answer and therefore I do not know why it has to be discussed.
 
There is a general answer - don't use inheritance except as substitute
for interfaces, which typically means abstract classes with no data members.
All other forms of inheritance are known antipattern.
Use aggregation instead.
Bonita Montero <Bonita.Montero@gmail.com>: Oct 08 08:36PM +0200

Am 08.10.2022 um 20:03 schrieb Michael S:
> for interfaces, which typically means abstract classes with no data members.
> All other forms of inheritance are known antipattern.
> Use aggregation instead.
 
Inheritance might be sometimes more difficult to handle.
But if you handle it correctly it's often less work than
with pure interfaces.
Mr Flibble <flibble@reddwarf.jmc.corp>: Oct 08 08:19PM +0100

On Sat, 8 Oct 2022 11:03:35 -0700 (PDT)
> for interfaces, which typically means abstract classes with no data
> members. All other forms of inheritance are known antipattern.
> Use aggregation instead.
 
Bullshit. Whilst in general composition is to be preferred over
inheritance there is nothing fundamentally wrong with deep inheritance
hierarchies if you have the slightest clue; it certainly is NOT an
anti-pattern: it is just another tool in the toolbox.
 
/Flibble
Manfred <noname@add.invalid>: Oct 08 09:42PM +0200

On 10/7/2022 11:47 AM, Juha Nieminen wrote:
> in cases where it's very possible that a derived implementation wants
> to change its own state (and thus would want the function to not be
> const).
 
As others have said, 'const'-ness is not really correlated with the
function being virtual or not; rather, it is a design choice strictly
coupled with the expected behavior (or contract) of the function.
In short, if it changes the (logical) state of the object, then it's
just non-const; if it doesn't, and it is not meant to change it, then it
may be (and probably is best, if you are convinced of your design)
qualified as const.
 
I'll add that during a course on C++ design, more than two decades ago,
the guy stressed that 'const is a very strong qualifier' in the C++ type
system.
Emphasis on /strong/, meaning that the decision whether some member is
or is not const should be considered thoroughly in C++ design, despite
how tiny the change is in code.
If, later along the way, you find yourself in the need of changing that
design choice, then I'd either make a new function or at least make an
overload (which, in C++, works well given the 'strong' nature of the
qualifier)
 
<snip>
 
> Except that sometimes, in some situations, there may not be any
> reasonable way to implement a const version of a function, because
> it *has to* change the object in order to function correctly.
 
I see here one of two things happening: either the 'state' of the object
or the semantics of the function is not defined properly.
A third, rare IME, alternative is that you would have some data member
that is not really part of the logical state of the object - that's the
use for 'mutable'.
Andrey Tarasevich <andreytarasevich@hotmail.com>: Oct 08 11:18AM -0700

On 10/7/2022 12:41 PM, Andrey Tarasevich wrote:
> reports errors neither in your example nor in mine. Meanwhile, Clang and
> MSVC still stick to the "early instantiation" approach, which allows
> them to see the problems in our examples.
 
Oh, I see that it was actually Clang that accepted the code...
 
Frankly, I'm having hard time trying to find a single version of Clang
that would accept it. GCC complains too, since partial specialization
after instantiation is a different kind of error. And a well-diagnosable
one.
 
Which version of Clang were you using?
 
--
Best regards,
Andrey
Michael S <already5chosen@yahoo.com>: Oct 08 10:57AM -0700

On Saturday, October 8, 2022 at 2:01:05 AM UTC+3, Tim Rentsch wrote:
> Not that I disagree necessarily, but can you say what it is about
> function overloading you don't like? (For the time being let's
> ignore the larger topic of polymorphism with templates.)
 
Difficulty (for human reader) to find out which of name-sakes is called at
given place.
15 years ago I would add another reason - this sort of polymorphism
interacts badly with default function parameters, which I considered
really useful. But today I am less sure that I still consider default
function parameters particularly useful.
 
[O.T.]
I probably would consider them very useful in the language that has
option for calling functions with designated (rather than positional)
syntax of parameters passing.
But neither C nor C++ are likely to ever provide such syntax.
More so C++. For C, there exists slight hope.
[/O.T.]
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)