constexpr issues

[wyn...@gmail.com]

Recently, I am learning to use constexpr keyword. Some questions arouse
in a test program t.cpp:

1: The impl. of cslen(const char*) uses ::strlen, g++ seems to accept it
as 'constexpr' (std::strlen is not). Is the impl. of cslen correct?
2: As the diagnosis shown, "Token::Pi.begin()" seemd not recognized as a
constexpr, why and how to correct it?

//---------------------------------------------------
#include <iostream>
#include <cstring>

#define ENDL "\n"

constexpr size_t cslen(const char* s) { return ::strlen(s); };

class Str {
const char *m_str;
size_t m_len;
public:
constexpr Str(const char* s) : m_str(s), m_len(cslen(s)) {};
constexpr size_t len() const { return m_len; };
constexpr const char* begin() const { return m_str; };
};

static constexpr char S1[cslen("ad")]={'s',0};
static constexpr Str S2{"S2..."};

struct Token {
static constexpr Str Pi{"Pi"};
};

int main()
{
std::cout << S1 << ENDL;
std::cout << S2.len() << ", " << S2.begin() << ENDL;
std::cout << Token::Pi.begin() << ENDL;
return 0;
}
//---------------------------------------------------

>g++ --version
g++ (GCC) 8.2.1 20181011 (Red Hat 8.2.1-4)
Copyright (C) 2018 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.

>g++ t.cpp
/usr/bin/ld: /tmp/ccFBOjNS.o: in function `main':
t2.cpp:(.text+0x6f): undefined reference to `Token::Pi'
collect2: error: ld returned 1 exit status


52,40 Bot

[Öö Tiib]

You need to tell g++ that you want to use C++17 features
(-std=c++17).

g++ -std=c++17 t.cpp

Seems to work.
Also it is usually worth to ask it to perform
a bit more diagnostics than it does by default. At least
-Wall and -Wextra and perhaps -pedantic. So:

g++ -std=c++17 -Wall -Wextra -pedantic t.cpp

You will get warning about redundant ;

[wyn...@gmail.com]

Öö Tiib於 2018年11月26日星期一 UTC+8下午9時01分12秒寫道：

Thanks.
"g++ -std=c++17 t.cpp" works well, I forgot the standard option for g++.
But the standard I am after is c++11. "g++ -std=c++11 t.cpp" causes the
same linker error! I can not understand why.

[Öö Tiib]

On Monday, 26 November 2018 16:37:03 UTC+2, wyn...@gmail.com wrote:
> Öö Tiib 於 2018年11月26日星期一 UTC+8下午9時01分12秒寫道：

If you want to use C++11 then you should not use C++17 features.
You have to define the Token::Pi in C++11. Adding that to end of
your file ...:

constexpr Str Token::Pi;

... will make it to compilöe with -std=c++11 too.

If you want to learn to use constexpr then I would suggest to forget
C++11. The constexpr as of C++11 is rather limited and crippled,
especially about functions. There it feels like a hack to simplify
some of most obscure template metaprogramming tricks and
for some performance optimizations.

The constexpr of C++17 on the other hand feels like a way to
mark pure functions (in functional programming sense) with keyword
constexpr. Preferring pureness is quite good programming idiom
in general, about like preferring immutability is good programming
idiom in general.

[wyn...@gmail.com]

Öö Tiib於 2018年11月28日星期三 UTC+8上午12時28分20秒寫道：

It works, but hardly to say better than pre-C++11 style,
after having read https://en.cppreference.com/w/cpp/language/constant_expression

> If you want to learn to use constexpr then I would suggest to forget
> C++11. The constexpr as of C++11 is rather limited and crippled,
> especially about functions. There it feels like a hack to simplify
> some of most obscure template metaprogramming tricks and
> for some performance optimizations.
>
> The constexpr of C++17 on the other hand feels like a way to
> mark pure functions (in functional programming sense) with keyword
> constexpr.

c++11 solved many previous deficiencies but also introduced many fold
complexity of the language for really nothing worthy of, relatively.
So c++11 should be enough for me, I have no time to resolve those
newly invented use-cases and corner issues. Thanks anyway, for your
usage experiences.

> Preferring pureness is quite good programming idiom
> in general, about like preferring immutability is good programming
> idiom in general.

Let's say. my philosophy is reality. I feel Python is becoming much
more popular and requested from the job market, than c++.
(pureness? immutability?)

[Öö Tiib]

I do not understand what is your point and what is "better".
Yes, to learn C++ one has to read quite a lot of manuals and
books.

> > If you want to learn to use constexpr then I would suggest to forget
> > C++11. The constexpr as of C++11 is rather limited and crippled,
> > especially about functions. There it feels like a hack to simplify
> > some of most obscure template metaprogramming tricks and
> > for some performance optimizations.
> >
> > The constexpr of C++17 on the other hand feels like a way to
> > mark pure functions (in functional programming sense) with keyword
> > constexpr.
>
> c++11 solved many previous deficiencies but also introduced many fold
> complexity of the language for really nothing worthy of, relatively.
> So c++11 should be enough for me, I have no time to resolve those
> newly invented use-cases and corner issues. Thanks anyway, for your
> usage experiences.

So ... C++11 added sub-bar constexpr and therefore C++11 is enough
for you?

> > Preferring pureness is quite good programming idiom
> > in general, about like preferring immutability is good programming
> > idiom in general.
>
> Let's say. my philosophy is reality. I feel Python is becoming much
> more popular and requested from the job market, than c++.
> (pureness? immutability?)

You compare different tools and philosophies.
Pureness and immutability help both people and compilers to
reason about code and to improve or to optimize it.
Python is scripting language that entirely ignores those
concerns. Where efficiency is needed there it calls
C or C++ programs or modules.

[wyn...@gmail.com]

Öö Tiib於 2018年11月28日星期三 UTC+8下午9時13分36秒寫道：

I was trying to use constexpr and to know that the code has to be
written like pre-c++11 style (a bit frustrated, c++17 way is 'better')

> Yes, to learn C++ one has to read quite a lot of manuals and
> books.
>

That sayed a lot.
Is it good or bad one has to read A LOT c++ manuals and books?

> > > If you want to learn to use constexpr then I would suggest to forget
> > > C++11. The constexpr as of C++11 is rather limited and crippled,
> > > especially about functions. There it feels like a hack to simplify
> > > some of most obscure template metaprogramming tricks and
> > > for some performance optimizations.
> > >
> > > The constexpr of C++17 on the other hand feels like a way to
> > > mark pure functions (in functional programming sense) with keyword
> > > constexpr.
> >
> > c++11 solved many previous deficiencies but also introduced many fold
> > complexity of the language for really nothing worthy of, relatively.
> > So c++11 should be enough for me, I have no time to resolve those
> > newly invented use-cases and corner issues. Thanks anyway, for your
> > usage experiences.
>
> So ... C++11 added sub-bar constexpr and therefore C++11 is enough
> for you?
>

I can read just common, less cultural English, can't figure out 'sub-bar'.
And yes, c++11 should be enough for me, I hope.

> > > Preferring pureness is quite good programming idiom
> > > in general, about like preferring immutability is good programming
> > > idiom in general.
> >
> > Let's say. my philosophy is reality. I feel Python is becoming much
> > more popular and requested from the job market, than c++.
> > (pureness? immutability?)
>
> You compare different tools and philosophies.
> Pureness and immutability help both people and compilers to
> reason about code and to improve or to optimize it.
> Python is scripting language that entirely ignores those
> concerns. Where efficiency is needed there it calls
> C or C++ programs or modules.

If some new keyword(or ...) is invented to improve convenience and
optimiztion, I am sure it wil do, but also sure other 'untouched'
part will suffer the opposite effect to the extent proportional to
that the new thing convers, not yet mentioning the complexity and
user/developer burdon grows by multipication when they are mixed in
use/consideration.
I rember Bjarne Stroustrup used to be very careful abour the core
part of the language. But stuffs after c++11 are more and more
'for fun' looked to me (much less insightful).

I am seeing programming languages from the perspective of the user,
not developer. So whatever the underlying language should not be
relevant to the user language in this concern. I don't like Python
but it is favored more than c++ by many is fact.

[Öö Tiib]

It is difficulty. Lot of somewhat overlapping features, more
variance in ways to reach same result. Often the differences
in fitness for particular purpose are small and so the
differences of readability, safety, reliability and/or performance
of result will be also small. It is complicated to learn to realize
when these differences might be significant. Hard to master,
hard to beat when mastered.

>
> > > > If you want to learn to use constexpr then I would suggest to forget
> > > > C++11. The constexpr as of C++11 is rather limited and crippled,
> > > > especially about functions. There it feels like a hack to simplify
> > > > some of most obscure template metaprogramming tricks and
> > > > for some performance optimizations.
> > > >
> > > > The constexpr of C++17 on the other hand feels like a way to
> > > > mark pure functions (in functional programming sense) with keyword
> > > > constexpr.
> > >
> > > c++11 solved many previous deficiencies but also introduced many fold
> > > complexity of the language for really nothing worthy of, relatively.
> > > So c++11 should be enough for me, I have no time to resolve those
> > > newly invented use-cases and corner issues. Thanks anyway, for your
> > > usage experiences.
> >
> > So ... C++11 added sub-bar constexpr and therefore C++11 is enough
> > for you?
>
> I can read just common, less cultural English, can't figure out 'sub-bar'.
> And yes, c++11 should be enough for me, I hope.

My English is anyway bad. I meant that features added by C++11
were really major but somewhat inconveniently or weakly thought
thru. C++14 and C++17 have attempted to fix it, not to add much
new.

> > > > Preferring pureness is quite good programming idiom
> > > > in general, about like preferring immutability is good programming
> > > > idiom in general.
> > >
> > > Let's say. my philosophy is reality. I feel Python is becoming much
> > > more popular and requested from the job market, than c++.
> > > (pureness? immutability?)
> >
> > You compare different tools and philosophies.
> > Pureness and immutability help both people and compilers to
> > reason about code and to improve or to optimize it.
> > Python is scripting language that entirely ignores those
> > concerns. Where efficiency is needed there it calls
> > C or C++ programs or modules.
>
> If some new keyword(or ...) is invented to improve convenience and
> optimiztion, I am sure it wil do, but also sure other 'untouched'
> part will suffer the opposite effect to the extent proportional to
> that the new thing convers, not yet mentioning the complexity and
> user/developer burdon grows by multipication when they are mixed in
> use/consideration.
> I rember Bjarne Stroustrup used to be very careful abour the core
> part of the language. But stuffs after c++11 are more and more
> 'for fun' looked to me (much less insightful).

The constexpr function of C++11 can contain only one, return,
statement. That is clearly too limiting.

> I am seeing programming languages from the perspective of the user,
> not developer. So whatever the underlying language should not be
> relevant to the user language in this concern. I don't like Python
> but it is favored more than c++ by many is fact.

User Is using software. User does not care with what tools it
is made. Programming language is tool of developer.
So it is developer who should choose what tool to use
for what task. Python is better tool for some situations,
C++ for other situations.

[james...@alumni.caltech.edu]

On Thursday, November 29, 2018 at 8:25:08 AM UTC-5, Öö Tiib wrote:
> On Thursday, 29 November 2018 02:26:25 UTC+2, wyn...@gmail.com wrote:
> > Öö Tiib於 2018年11月28日星期三 UTC+8下午9時13分36秒寫道：

...

> > > So ... C++11 added sub-bar constexpr and therefore C++11 is enough
> > > for you?
> >
> > I can read just common, less cultural English, can't figure out 'sub-bar'.
> > And yes, c++11 should be enough for me, I hope.
>
> My English is anyway bad. I meant that features added by C++11
> were really major but somewhat inconveniently or weakly thought
> thru. C++14 and C++17 have attempted to fix it, not to add much
> new.

I suspect you meant "sub-par" <https://en.wiktionary.org/wiki/sub-par>.

[Scott Lurndal]

wyn...@gmail.com writes:
>=C3=96=C3=B6 Tiib=E6=96=BC 2018=E5=B9=B411=E6=9C=8828=E6=97=A5=E6=98=9F=E6=
>=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=889=E6=99=8213=E5=88=8636=E7=A7=92=E5=
>=AF=AB=E9=81=93=EF=BC=9A

>> So ... C++11 added sub-bar constexpr and therefore C++11 is enough
>> for you?

>>=20

>
>I can read just common, less cultural English, can't figure out 'sub-bar'.
>And yes, c++11 should be enough for me, I hope.
>

The expression 'sub-par' generally means at a quality less than
average. Yet in the game of golf, sub-par is actually excellent :-)

[wyn...@gmail.com]

Öö Tiib於 2018年11月29日星期四 UTC+8下午9時25分08秒寫道：

That's another helpful piece of information for me.
By the way, is the function definition
constexpr size_t slen(const char* cstr) { return ::strlen(cstr); }
correct in c++11 (or c++14,c++17)?

> > I am seeing programming languages from the perspective of the user,
> > not developer. So whatever the underlying language should not be
> > relevant to the user language in this concern. I don't like Python
> > but it is favored more than c++ by many is fact.
>
> User Is using software. User does not care with what tools it
> is made. Programming language is tool of developer.
> So it is developer who should choose what tool to use
> for what task. Python is better tool for some situations,
> C++ for other situations.

We were using the same words 'user/developer' in different context.
with 'user' I meant (c++) language user
with 'developer' I meant (c++) language developer
Because I used to encounter c++ language developers here in this
forum, or people who speak like c++ language developers. I thought
you might be a c++ language developer too, or at least one devoted
to the development of c++ language.

I sensed you recommend c++17. The major concern is a part of my
program require nearly exaustive accompanying test codes. If c++17
is adopted, I have to skip/ignore those new things added sine c++11,
I am not sure this skip/ignore-ness is safe, or proper.

By the way, thanks to Scott Lurndal who explained 'sub-par'

[Öö Tiib]

On Friday, 30 November 2018 03:18:21 UTC+2, wyn...@gmail.com wrote:
> Öö Tiib於 2018年11月29日星期四 UTC+8下午9時25分08秒寫道：
> > On Thursday, 29 November 2018 02:26:25 UTC+2, wyn...@gmail.com wrote:
> > > Öö Tiib於 2018年11月28日星期三 UTC+8下午9時13分36秒寫道：
> > > > On Wednesday, 28 November 2018 02:09:10 UTC+2, wyn...@gmail.com wrote:
> > > > > Öö Tiib於 2018年11月28日星期三 UTC+8上午12時28分20秒寫道：

snipping a bit.

No. Implementation may do strlen compile time as optimization
but C++ committee avoids retrofitting constexpr to library
functions. I don't know the reason of it. People can make
their own in C++11 with recursion:

constexpr
int length(const char* str)
{
return *str ? 1 + length(str + 1) : 0;

}

> > > I am seeing programming languages from the perspective of the user,
> > > not developer. So whatever the underlying language should not be
> > > relevant to the user language in this concern. I don't like Python
> > > but it is favored more than c++ by many is fact.
> >
> > User Is using software. User does not care with what tools it
> > is made. Programming language is tool of developer.
> > So it is developer who should choose what tool to use
> > for what task. Python is better tool for some situations,
> > C++ for other situations.
>
> We were using the same words 'user/developer' in different context.
> with 'user' I meant (c++) language user
> with 'developer' I meant (c++) language developer

Ok, I misunderstood.

> Because I used to encounter c++ language developers here in this
> forum, or people who speak like c++ language developers. I thought
> you might be a c++ language developer too, or at least one devoted
> to the development of c++ language.

I am programmer. I am not implementer of programming
languages. I have actually only in one project dealt with kind
of self-made scripting language. It convinced me that such
efforts are waste of time. There are too many programming
languages. There are no point to add one more. It is lot easier
and fruitful to fit one of those into any situation.

> I sensed you recommend c++17.

Actually C++14 improved constexpr in language. The C++17 added
constexpr-compatible class templates (string_view, optional and
variant) to standard library.

> The major concern is a part of my
> program require nearly exaustive accompanying test codes. If c++17
> is adopted, I have to skip/ignore those new things added sine c++11,
> I am not sure this skip/ignore-ness is safe, or proper.

I do not understand that logic. How difficulties with C++17
follow from tests? Tests are normal with any toolset and there
are AFAIK nothing in C++17 that makes testing harder. It is even
easier to migrate to newer compiler when there are tests since
those help to discover cases when some incompatibility or
defect starts to manifest itself.

[wyn...@gmail.com]

Öö Tiib於 2018年11月30日星期五 UTC+8下午5時12分05秒寫道：

Brilliant solution! (or resolution made by c++11)

I mean manually writting test cases for, for instance, all the
'new words' that can be found in the mentioned webpage for constexpr
https://en.cppreference.com/w/cpp/language/constant_expression
like , including constexpr, lvalue-rvalue*reference, glvalue,
prvalue, immediate function, lambda expression, odr-use , implicit conversion,...

Hope you can see that is not an easy job. I had done such things for
pre-c++11. Even today there are still several things inconvenient to
say loudly, e.g. multiple inheritance. I appreciate your expertise
in c++. But if you examine it closely, you might end-up recall the
experience 'waste of time' again. That is what I thought and the
reason hesitate.

[Öö Tiib]

Do you use all that in your code? If you don't then why to test
how compiler handles it? Is your program a parser of C++? Tests
are usually checking if the program (or functions in it) give expected
outputs to test inputs, and not how C++ features work on any kind
of code.

> Hope you can see that is not an easy job. I had done such things for
> pre-c++11. Even today there are still several things inconvenient to
> say loudly, e.g. multiple inheritance. I appreciate your expertise
> in c++. But if you examine it closely, you might end-up recall the
> experience 'waste of time' again. That is what I thought and the
> reason hesitate.

In my programs inheritance is rare, the few inheritance trees are flat
and multiple inheritance is extra rare. The tests are only written if
these few classes with multiple inheritance behave as expected
in contexts where these are used. I do not need tests how multiple
inheritance works in general and in whatever context.

[wyn...@gmail.com]

Öö Tiib於 2018年11月30日星期五 UTC+8下午10時50分28秒寫道：

The major part are library codes, test codes are made to assure the API
can be more correctly used in as many scenarios as possible.
Take Qt library (pre-c++11) for analogy, I had a QString-like class.
To upgrade to c++11, I should evaluate the possibility of adding move
ctor/assignment..members to QString. Whether adding or not in the final,
I should examine by writting test cases that explicitly use rref things
or implicitly interpreted to use.
All classes/functions... have to go through such similar examination
procedure against each new feature.
Luckily, in this illustrated case I know I can safely ignore rref things.
Another analogy would be like Qt's foreach. Since I don't use foreach,
just can imagine the labor (and the mental struggle) I would take to
upgrade to newer c++ version.

> > Hope you can see that is not an easy job. I had done such things for
> > pre-c++11. Even today there are still several things inconvenient to
> > say loudly, e.g. multiple inheritance. I appreciate your expertise
> > in c++. But if you examine it closely, you might end-up recall the
> > experience 'waste of time' again. That is what I thought and the
> > reason hesitate.
>

> In my programs inheritance is rare,the few inheritance trees are flat

> and multiple inheritance is extra rare.

Multiple inheritance is rare is because of years of experiences and
evolution (something like exception specification). The bottom thing is
class inheritance is not that omni-capable as it used to be believed.

> The tests are only written if
> these few classes with multiple inheritance behave as expected
> in contexts where these are used. I do not need tests how multiple
> inheritance works in general and in whatever context.

'Tests are only written..." is the problem of c++ from at least c++11
and latter years. Some form of program writting invented is
just because people focus in the beauty, efficiency or whatever fancy
reasons too much to underestimate the shadow side (tests not done enough).
At least I know 'size bloat' is not a good sign (you might find many
rarely used things appear in compiled files or in executibles instead).

[Öö Tiib]

It sounds like you try to write classes that do something useful but
can't be misused. I also try to make my classes straight to the point
for what these are meant but I do not worry about misusage too
deeply. If something can be used then it can be also misused.

> Luckily, in this illustrated case I know I can safely ignore rref things.
> Another analogy would be like Qt's foreach. Since I don't use foreach,
> just can imagine the labor (and the mental struggle) I would take to
> upgrade to newer c++ version.

You can always avoid making clones of library functions. There is
std::foreach since C++98 and there is range based for since C++11.
The chances are rather slim that your self-made version wins those.

>
> > > Hope you can see that is not an easy job. I had done such things for
> > > pre-c++11. Even today there are still several things inconvenient to
> > > say loudly, e.g. multiple inheritance. I appreciate your expertise
> > > in c++. But if you examine it closely, you might end-up recall the
> > > experience 'waste of time' again. That is what I thought and the
> > > reason hesitate.
> >
> > In my programs inheritance is rare,the few inheritance trees are flat
> > and multiple inheritance is extra rare.
>
> Multiple inheritance is rare is because of years of experiences and
> evolution (something like exception specification). The bottom thing is
> class inheritance is not that omni-capable as it used to be believed.

I am programmer not politician and so I don't believe in silver bullets.
For me inheritance is a feature of some programming languages.
A tool like any other. That tool is meant to resolve certain
complications with certain kind of objects. Typically the complication
manifests itself as long methods/functions with lot of if-else or
switch-case chains that handle that kind of objects. That can
be fine or can make code hard to follow, test and maintain.

The complication itself is infrequent and inheritance is often not the
best tool to resolve it. A situation where same group of objects has
several and orthogonal such complications is ultra rare. Therefore
most usages of multiple inheritance are misuse of the tool.

> > The tests are only written if
> > these few classes with multiple inheritance behave as expected
> > in contexts where these are used. I do not need tests how multiple
> > inheritance works in general and in whatever context.
>
> 'Tests are only written..." is the problem of c++ from at least c++11
> and latter years. Some form of program writting invented is
> just because people focus in the beauty, efficiency or whatever fancy
> reasons too much to underestimate the shadow side (tests not done enough).
> At least I know 'size bloat' is not a good sign (you might find many
> rarely used things appear in compiled files or in executibles instead).

I agree that all kind of testing (unit, automated and manual) are often
not done enough. The reason is that it is work too. Mature, well
tested product means lot of work of highly skilled specialists. That
is expensive. If we go extreme, 100%, no defects, then that means
we need omnipotent specialists. It is AFAIK impossible so we have
to balance our resource usage.

[wyn...@gmail.com]

Öö Tiib於 2018年12月3日星期一 UTC+8下午6時50分14秒寫道：

Therefore, my strategy (including from being misused) is keeping the API
simple and forcing users to check for errors explicitly (even inside the
library, I also check the underlying things for errors if convenient).
Most people don't like to check for errors explicitly rather like to see
the completed written program terse, beautiful,...,even 'smart'.
Objectively to say, we got what we want. For my part, I could work at
home writting programs quite mechanically, even mindlessly (not good,
though). 99% of bugs reported from clients are not serious and can be
identified and fixed in one day. That is the practical reason why I need
to check the API against newer c++ features in the 1st place, another
reason is pure academic, theoretical.

> > Luckily, in this illustrated case I know I can safely ignore rref things.
> > Another analogy would be like Qt's foreach. Since I don't use foreach,
> > just can imagine the labor (and the mental struggle) I would take to
> > upgrade to newer c++ version.
>
> You can always avoid making clones of library functions. There is
> std::foreach since C++98 and there is range based for since C++11.
> The chances are rather slim that your self-made version wins those.
>

My mistake, I though Qt4's foreach was invented before c++.
The analogy was trying to say that if some new c++ feature or 'keyword'
collides with or comes too close to one's existing codes, that would cause headache, e.g. thread, many people should have such experience.

> >
> > > > Hope you can see that is not an easy job. I had done such things for
> > > > pre-c++11. Even today there are still several things inconvenient to
> > > > say loudly, e.g. multiple inheritance. I appreciate your expertise
> > > > in c++. But if you examine it closely, you might end-up recall the
> > > > experience 'waste of time' again. That is what I thought and the
> > > > reason hesitate.
> > >
> > > In my programs inheritance is rare,the few inheritance trees are flat
> > > and multiple inheritance is extra rare.
> >
> > Multiple inheritance is rare is because of years of experiences and
> > evolution (something like exception specification). The bottom thing is
> > class inheritance is not that omni-capable as it used to be believed.
>
> I am programmer not politician and so I don't believe in silver bullets.
> For me inheritance is a feature of some programming languages.
> A tool like any other. That tool is meant to resolve certain
> complications with certain kind of objects. Typically the complication
> manifests itself as long methods/functions with lot of if-else or
> switch-case chains that handle that kind of objects. That can
> be fine or can make code hard to follow, test and maintain.
>
> The complication itself is infrequent and inheritance is often not the
> best tool to resolve it. A situation where same group of objects has
> several and orthogonal such complications is ultra rare. Therefore
> most usages of multiple inheritance are misuse of the tool.
>

I was talking about history. Class inheritance had been believed powerful
like crazy, so why not go further, so multiple inheritance it is.

> > > The tests are only written if
> > > these few classes with multiple inheritance behave as expected
> > > in contexts where these are used. I do not need tests how multiple
> > > inheritance works in general and in whatever context.
> >
> > 'Tests are only written..." is the problem of c++ from at least c++11
> > and latter years. Some form of program writting invented is
> > just because people focus in the beauty, efficiency or whatever fancy
> > reasons too much to underestimate the shadow side (tests not done enough).
> > At least I know 'size bloat' is not a good sign (you might find many
> > rarely used things appear in compiled files or in executibles instead).
>
> I agree that all kind of testing (unit, automated and manual) are often
> not done enough. The reason is that it is work too. Mature, well
> tested product means lot of work of highly skilled specialists. That
> is expensive. If we go extreme, 100%, no defects, then that means
> we need omnipotent specialists.

If you say it is also a work, meaning a pre-determined release is
scheduled first, than the problem is the plan, sounds to me.
No one can claim 100% correct (including this sentence).
The tests I see that could be done are quite simple, just enumerate all
usecases(unbiased) as many as possible, laborsome, though.

> It is AFAIK impossible so we have
> to balance our resource usage.

That's the trick. More invention or more tests?