Notes from C++ static analysis

[Paulo Pinto]

On Thursday, 27 June 2013 at 02:25:54 UTC, Andrei Alexandrescu 
wrote:
> On 6/26/13 2:47 PM, Paulo Pinto wrote:
>> Am 26.06.2013 20:52, schrieb H. S. Teoh:
>>> On Wed, Jun 26, 2013 at 08:08:08PM +0200, bearophile wrote:
>>>> An interesting blog post found through Reddit:
>>>>
>>>> http://randomascii.wordpress.com/2013/06/24/two-years-and-thousands-of-bugs-of-/
>>>>
>>> [...]
>>>> The most common problem they find are errors in the format 
>>>> string of
>>>> printf-like functions (despite the code is C++):
>>>
>>> None of my C++ code uses iostream. I still find stdio.h more 
>>> comfortable
>>> to use, in spite of its many problems. One of the most 
>>> annoying features
>>> of iostream is the abuse of operator<< and operator>> for 
>>> I/O. Format
>>> strings are an ingenious idea sorely lacking in the iostream 
>>> department
>>> (though admittedly the way it was implemented in stdio is 
>>> rather unsafe,
>>> due to the inability of C to do many compile-time checks).
>>
>> I have been an adept of iostreams since day one and never 
>> understood why
>> people complain so much about them or the operator<< and 
>> operator>>
>> for that matter.
>
> The problems with C++ iostreams are well-known and pernicious:
>
> 1. Extremely slow by design.
>
> 2. Force mixing representation with data by design
>
> 3. Keep conversion state within, meaning they force very 
> bizarre tricks even for simple things such as printing/scanning 
> hex numbers.
>
> 4. Approach to exception safety has the wrong default.
>
> 5. Approach to internationalization (locales) has the most 
> byzantine design I've ever seen. Even people who took part to 
> the design can't figure it all out.
>
>
> Andrei

I always liked their OO model and for the type of applications we 
use performance never was a problem.

My iostreams experience is mostly coupled to serialization of 
data structures, simple console applications.

Exception safety might be an issue, sadly I was never able to 
write portable C++ code at work that used either RTTI or 
exceptions. Just too many issues, which always lead to the 
architects forbidding their use.

Thanks for the explanation.

--
Paulo