Comment by t43562
1 year ago
C++ was a total disaster for one reason and everything came out of this:
It cannot handle running out of memory safely.
Handling an out of memory exception requires memory. 50% of the nastiness came out of the way Symbian tried to address this by redefining the new operator so that it could return null instead of raising an exception - the whole approach to memory management became horrendous because of this. 2 stage initialisation etc. It meant that all existing C++ code and containers were not portable.
20% of the nastiness came out of C++ being very immature at the time it was all started so OS classes for handling various kinds of unicode strings were not nice, there was no ABI stability. At Nokia the ARM compiler was used and it was very slow and required licenses which made it expensive to build in parallel.
20% of the nastiness came from choosing the windows DLL model over the linux .so one with export slots so that adding one method to a class would move the slots around and make a DLL incompatible if you didn't go through a complicated freexing process which seemed to go wrong from time to time. Adding one item to a datastructure also could crash existing programs which is par for the course in C++ but not Java and this was quite shitty.
These percentages are just my rough stab at it - maybe enough to give an idea.
I have written tons of perfectly fine C++ code for many platforms. I totally failed doing something for Nokia because tooling and documentation was terrible.
Not with the same constraints. How often does your program expect to run out of memory for example? On phones at that time it was expected to be common and it was absolutely essential that it be handled gracefully.
Were all your operating system calls asynchronous?
[flagged]