Why We Don't Want Academics in Charge of Language Standards

#1 · April 3, 2024, 11:47 AM

Quote from seasoned_geek on April 3, 2024, 11:47 AM
Most of you know I have been using Copperspice for development of RedDiamond (which will be the editor of this distro if I/we ever spin an ISO). The fact it was forked from Qt 4.8 and has been ripping out all things QML is a major selling point. Sadly one of the members is too caught up in the language standard to smell the tea brewing in the real world. Since I am certain they won't unhide my reply in this message thread, bringing it here.

They quoted me

An alias is not a typedef. Calling an alias a typedef gets you into all kinds of trouble.

The following text was copied directly from cppreference, which is a trusted site for interpreting the C++ standard.

"A type alias declaration introduces a name which can be used as a synonym for the type denoted by type-id. It does not introduce a new type and it cannot change the meaning of an existing type name. There is no difference between a type alias declaration and typedef declaration. This declaration may appear in block scope, class scope, or namespace scope."

typedef is global

This is not how C++ works. Both typedef and type alias declarations (using) can be global or scoped to a class or just a single method or namespace. A typedef or a using declaration can be global, but there is no guarantee and you can not assume the scope based on the kind of declaration.

Since the identifier "size_type" is documented as part of the QString class this means it is a part of the class and not a global declaration. If you look through the API documentation of our libraries or the C++ standard you will see every container has its own definition of "size_type" and they do not conflict nor are they the same.

In case you didn't catch on the second line in italics is also them quoting me.

Now all of you reading this know typedef is global and you know why. Doesn't matter what the language standard says, there is an earthly reality that must be followed. Naturally, I had to respond pointing out the error of their ways and the fact they worship a false god.

This is how coding that matters works. (Matters being defined as all Safety Critical Systems and Devices) Easiest to paste from here.

[MISRA C++ Rule 2–10–3, Required] - A typedef name (including qualification, if any) shall be a unique identifier.
[MISRA C++ Rule 2–10–4, Required] - A class, union or enum name (including qualification, if any) shall be a unique identifier.

Some tools have slightly different wording.

https://pvs-studio.com/en/docs/warnings/v2619/

Typedef names should be unique across all name spaces

The TI development environment has been enforcing it since at least the 2004 standard came out.

Formal MISRA C++ 2008 can be found here.

P. 46 provides some clearer wording

Reusing a class, union or enum name, either as another type or for any other purpose, may lead to
developer confusion.

The class, union or enum name shall not be duplicated anywhere in the project, even if the
declarations are identical.

This rule is not violated when the definition is made in a header file, and that header file is
included in multiple source files.

I have been working in embedded systems (mostly medical devices) for the past decade. There is a bigger crackdown now, when using OpenSource code to make ALL the code used by the project adhere to at least one of the safety coding standards. Formally reviewed by project team and everything.

Doesn't matter if it is SEI CERT C++, BARR Group with extensions for C++, Joint Strike Force, or Misra C++ (most any year thought 2008 is pretty common now).

BARR group has been used with extensions for many medical devices though the C++ extensions aren't as easily found. Misra C++ is actually supported by many advanced editors or IDEs. CppCheck is even starting to support Misra 2012. I suspect the "addon" tag means "buy the license to get this feature"

At any rate, most of the people and companies I point at CopperSpice for their project take one look at the code base and pass. Bringing it up to a safety standard and being saddled with maintaining their own one-off is too much risk.

The first thing I learned coming to the embedded world from the land of big systems is this:

Just because the compiler lets you do it doesn't make it right.

So, this brings us back to a reality we all face now or soon will face in the future. Yeah, OpenSource is "free as in beer" but more and more regulated environments are requesting/demanding/requiring we bring the libraries we use into full "safety standard" compliance code. The reality is that none of the "free as in beer" have even tried to meet such a standard. Most of those charging hideous license fees (Qt anyone?) can't even dream about a codebase close to any safety coding standard. It's why many of us find ourselves reaching for stuff like NanoGUI, with a codebase so small whipping it into shape is no problem.

If we are going to cultivate a medical device developer Linux distro, the tools we allow in need to be limited in number and well cultivated. If an OpenSource library is going to be allowed in, it has to be up to a safety critical coding standard.

This means a C++ library shall not contain any pre-C++11 enums. They will all be Enum Classes. It means that all typedef/alias creation will be globally unique within the library. None of this academic bullshit of aliasing "size_type" to be something different for every container. If you really are adamant about aliasing within a container class then you have to prefix size_type with the container name in the name itself. No, Container::size_type is not good enough.

Please chime in on this discussion.

Most of you know I have been using Copperspice for development of RedDiamond (which will be the editor of this distro if I/we ever spin an ISO). The fact it was forked from Qt 4.8 and has been ripping out all things QML is a major selling point. Sadly one of the members is too caught up in the language standard to smell the tea brewing in the real world. Since I am certain they won't unhide my reply in this message thread, bringing it here.

They quoted me

An alias is not a typedef. Calling an alias a typedef gets you into all kinds of trouble.

The following text was copied directly from cppreference, which is a trusted site for interpreting the C++ standard.

"A type alias declaration introduces a name which can be used as a synonym for the type denoted by type-id. It does not introduce a new type and it cannot change the meaning of an existing type name. There is no difference between a type alias declaration and typedef declaration. This declaration may appear in block scope, class scope, or namespace scope."

typedef is global

This is not how C++ works. Both typedef and type alias declarations (using) can be global or scoped to a class or just a single method or namespace. A typedef or a using declaration can be global, but there is no guarantee and you can not assume the scope based on the kind of declaration.

Since the identifier "size_type" is documented as part of the QString class this means it is a part of the class and not a global declaration. If you look through the API documentation of our libraries or the C++ standard you will see every container has its own definition of "size_type" and they do not conflict nor are they the same.

In case you didn't catch on the second line in italics is also them quoting me.

Now all of you reading this know typedef is global and you know why. Doesn't matter what the language standard says, there is an earthly reality that must be followed. Naturally, I had to respond pointing out the error of their ways and the fact they worship a false god.

This is how coding that matters works. (Matters being defined as all Safety Critical Systems and Devices) Easiest to paste from here.

[MISRA C++ Rule 2–10–3, Required] - A typedef name (including qualification, if any) shall be a unique identifier.
[MISRA C++ Rule 2–10–4, Required] - A class, union or enum name (including qualification, if any) shall be a unique identifier.

Some tools have slightly different wording.

https://pvs-studio.com/en/docs/warnings/v2619/

Typedef names should be unique across all name spaces

The TI development environment has been enforcing it since at least the 2004 standard came out.

Formal MISRA C++ 2008 can be found here.

P. 46 provides some clearer wording

Reusing a class, union or enum name, either as another type or for any other purpose, may lead to
developer confusion.
The class, union or enum name shall not be duplicated anywhere in the project, even if the
declarations are identical.
This rule is not violated when the definition is made in a header file, and that header file is
included in multiple source files.

I have been working in embedded systems (mostly medical devices) for the past decade. There is a bigger crackdown now, when using OpenSource code to make ALL the code used by the project adhere to at least one of the safety coding standards. Formally reviewed by project team and everything.

Doesn't matter if it is SEI CERT C++, BARR Group with extensions for C++, Joint Strike Force, or Misra C++ (most any year thought 2008 is pretty common now).

BARR group has been used with extensions for many medical devices though the C++ extensions aren't as easily found. Misra C++ is actually supported by many advanced editors or IDEs. CppCheck is even starting to support Misra 2012. I suspect the "addon" tag means "buy the license to get this feature"

At any rate, most of the people and companies I point at CopperSpice for their project take one look at the code base and pass. Bringing it up to a safety standard and being saddled with maintaining their own one-off is too much risk.

The first thing I learned coming to the embedded world from the land of big systems is this:

Just because the compiler lets you do it doesn't make it right.

So, this brings us back to a reality we all face now or soon will face in the future. Yeah, OpenSource is "free as in beer" but more and more regulated environments are requesting/demanding/requiring we bring the libraries we use into full "safety standard" compliance code. The reality is that none of the "free as in beer" have even tried to meet such a standard. Most of those charging hideous license fees (Qt anyone?) can't even dream about a codebase close to any safety coding standard. It's why many of us find ourselves reaching for stuff like NanoGUI, with a codebase so small whipping it into shape is no problem.

If we are going to cultivate a medical device developer Linux distro, the tools we allow in need to be limited in number and well cultivated. If an OpenSource library is going to be allowed in, it has to be up to a safety critical coding standard.

This means a C++ library shall not contain any pre-C++11 enums. They will all be Enum Classes. It means that all typedef/alias creation will be globally unique within the library. None of this academic bullshit of aliasing "size_type" to be something different for every container. If you really are adamant about aliasing within a container class then you have to prefix size_type with the container name in the name itself. No, Container::size_type is not good enough.

Please chime in on this discussion.