#735 Make C++11 accessible in all parts of the SDCC code base

[Benedikt Freisen]

According to Language Dialects used in SDCC, SDCC uses C++11 for those portions of the code base that are written in C++.
In my opinion, it would make sense to use C++11, consistently, because C99 constrains developers to programming techniques that are way past their best-before date and forces them to keep reinventing wheels that a modern C++ STL or BOOST already provide.

Converting the code base to C++11 would involve the following steps:

• [x] Rename the .c and .h files to .cc and .hpp and adjust the source and make files
  • This has already been done based on [r12060] as a proof of concept. It involved:
    • A lot of static_casts, because C++ is pickier about types
    • A lot of constness adjustments and the occasional const_cast, primarily in the context of string literals
    • The occasional reinterpret_cast
    • Renaming of a few variables and types that are keywords in C++.
  • It has already exposed [bugs:#3179], because the linker has access to more type information.
  • Most importantly: The regression tests pass!
• [ ] Adjust the implementation of the Safe_alloc/Safe_free family to use new[] and delete[], instead. This allows the successive replacement of occurrences, potentially in an automated way via regex.
• [ ] Turn the accessor macro hell in SDCCsymt into member functions or at least wrappers of member functions. Then make the attributes private, so that they cannot be accessed in an unsafe way. This could expose potential bugs.
• [ ] Turn most of the enums into enum classes, i.e. scoped enumerations. This helps with readability and avoids name clashes.
• [ ] Try to get rid of dbuf and dbuf_string. std::string and std::stringstream are more versatile and can be passed by value.
• [ ] Try to get rid of SDCCset, SDCChasht and SDCCbitv in favor of standard containers and boost::dynamic_bitset or sensible sub-classes. C++ containers can be iterated over via range-based for. It might even be possible to replace entire code blocks with invocations of "find" or "count" or std::algorithm one-liners. At least the conversion to range-based for can probably be done in a semi-automated manner with a regex-enabled IDE's find+replace.
• [ ] Bonus: Use IDE-friendly doxygen style for all comments that document functions, variables or attributes.

[Philipp Klaus Krause]

However, using C makes the entry barrier for new developers lower. Knowing C is a reasonable expectation on new developers of a C compiler. C++ is an extra burden.

[Benedikt Freisen]

The is certainly valid as a generic statement.
However, having seen the code base and skimmed through most of it, lately, I politely disagree.
In my opinion, the average C programmer is more likely to understand C-like C++ that uses C++ features and libraries where appropriate, than the code base as it is now.
And as far as the containers are concerned, [feature-requests:#688] only scratches the surface.

Going forward, I will try to explore in different directions to see what might lead to desirable improvements.
One of them is certainly improved cost correctness and type correctness:
Assigning string literals to non-const char pointers is hardly ever a good idea, much like setting variables of enum type to an implicitly type cast literal zero or defining a function with return type "void *" just to cast the result to the exact same non-void pointer type for every invocation.
All that was exposed by the pickier compiler and the corrections should find their way into the official code base sooner rather than later, i.e soon after the pending release.