[HH] c++ strings?

[Mark Woodward]

On 11/20/2012 09:21 AM, Jerry Feldman wrote:
> On 11/20/2012 06:12 AM, Mark Woodward wrote:
>> On 11/20/2012 01:55 AM, David Kramer wrote:
>>> You probably want sprintf, which is like printf except it outputs a
>>> string instead of writing the output to stdout.
>>>
>>> http://www.cplusplus.com/reference/clibrary/cstdio/sprintf/
>> You never, ever, really never, want to use sprintf in any program.
>> Each and every occurrence of "sprintf" should be replaced by snprintf
>> as soon as possible. The sprintf call is unbounded is a stability risk
>> as well as a potential security hole.
> C++ native strings are identical to C language strings using all the C
> library functions, but there is a very rich C++ string class that is
> part of the STL (standard template Library)(std::string).
> http://www.cplusplus.com/reference/string/string/
>
> IMHO, as a long time contractor I always recommend coding in the same
> style that is prevalent in the companies that I have worked in. When
> coding in C++ I rarely use the C language strings or printfs. Again,
> from a purist standpoint, in C++ you should generally use the cout set
> of input/output operators.

This is a pet peeve of mine. What is a C++ "purist?" C++ is a very broad 
language with a lot of capabilities. The "cout" object is merely one of 
those to be used or not based on need.

For some reason, "purists" want to ignore that C++ is for all practical 
purposes a set of extensions to C. Furthermore, that, for some reason, 
programs must be coded entirely differently than you would C code. I 
reject this mentality as something akin to "java-envy" or something.

There is nothing wrong with the various incarnations of printf. There is 
no reason not to use malloc if you want. There is no reason not to use 
"char *" for strings. Templates need not be used.

C++ code is that which compiles using a C++ compiler, not some 
ideological construct that must be adhered too.
>
>
>
> _______________________________________________
> Hardwarehacking mailing list
> Hardwarehacking at blu.org
> http://lists.blu.org/mailman/listinfo/hardwarehacking

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blu.org/pipermail/hardwarehacking/attachments/20121120/d6f97a7a/attachment.html>