[HH] c++ strings?

[Jerry Feldman]

On 11/20/2012 12:04 PM, Matthew Gillen wrote:
> On 11/20/2012 10:34 AM, Mark Woodward wrote:
>> On 11/20/2012 10:06 AM, Matthew Gillen wrote:
>>> Likewise with malloc vs. new: they are NOT freely interchangeable.
>>> Managing a C++ class with 'new/delete' will ensure that
>>> constructors/destructors get called.  Managing that same object with
>>> malloc/free does not invoke constructor/destructor pairs, it merely
>>> allocates memory.  Furthermore, there is no guarantee that the way
>>> 'new' and 'malloc' manage memory is compatible; e.g. you could have
>>> issues if you 'new' and object and then 'free' it, or 'malloc' and
>>> object then 'delete' it.
>> New/delete are interesting. Typically, a pointer returned by "new" can
>> be freed by "free," however, new and delete involve the constructors and
>> destructors.
>
> What you're suggesting is not portable, as in "the language spec does
> not guarantee that you can 'free' something allocated via 'new'.
> There's a school of thought that says "screw the spec, whatever gcc
> allows/supports is what matters", but it's also almost always a bad
> idea (do you want to verify that your class' destructor is empty,
> along with any inherited destructors?  If those destructors are
> non-empty, are you going to duplicate the code contained therein for
> the sake of being able to call 'free'?).
>
> Every time I've relied on some nice feature of gcc that isn't
> explicitly spelled out in the spec, I end up getting burned when
> someone down the line eventually makes me compile it on a microsoft
> compiler...
>
>
Agreed. The standard generally states that some things are
"implementation defined". Not only is it non-portable, but just because
it might appear to work, it could actually break in another application
compiled by the same compiler. Or it could break later if that
application were compiled with n update to the compiler. Doing things
like that essentially are creating latent bugs. I once had a Unix
command break a build. That command had not been modified in many years.
The issue there was that the current version of the compiler was able to
detect a latent bug. After taking a very hard look at the code I was
able to see what was wrong.

-- 
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/e7f73332/attachment.sig>