[HH] c++ strings?

[Jerry Feldman]

On 11/20/2012 09:37 AM, Mark Woodward wrote:
> 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.
>
Mark,
There are reasons why you should avoid both mixing stdio (cstdio)
iostream  as well as the C Malloc(3) and the C++ new allocator.
In the case of I/O, you can get some interleaves because iostream and
stdio use different buffers. Not a major issue, and sometimes using the
printf (safe ones) library calls in C++ is useful.

In the case of malloc vs the C++ operators, such as new, there could be
some serious problems. First let me give you some of my background. I
worked on a small team to port Purify to Tru64. This required
instrumenting both malloc, new, brk, sbrk, et. al. The issue is that the
new operator and malloc would be working with different pools. Both use
either sbrk or mmap or both. So, mixing malloc and new could cause the
application to use more heap than using just new. In some cases, the new
operator is actually layered on malloc. All C++ guides say not to mix
the two. Remember that by using new, you have a certain amount of
cleanup using a destructor where in malloc you do not. Remember, when
malloc is called for the first time, it requests a large amount of
memory for the pool.. Same with new. There are some cases where your
application could run out of memory even though there is plenty
available. One of the test cases I wrote was to force an application to
run out of memory in this case, but at the same time I knew exactly how
malloc and new were implemented. If I remember correctly, at that time
malloc used a combination of sbrk and mmap.

So, while it is not a good thing to mix cstdio and iostream and malloc
and new, there are some valid reasons to do so, but use them with care.
And from my purist standpoint, while C++ was built on top of C
originally, when coding in C++ code in C++ not in C.

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 543 bytes
Desc: OpenPGP digital signature
URL: <http://lists.blu.org/pipermail/hardwarehacking/attachments/20121120/ec0a1ef4/attachment.sig>