FROM : Alastair Houghton
DATE : Sun Feb 03 19:16:54 2008
On 3 Feb 2008, at 16:44, Thomas Engelmeier wrote:
> On 01.02.2008, at 18:35, John Stiles wrote:
>
>> Well, most C++ code should be using new and not malloc() anyway.
>> malloc() is a holdover from the Bad Untyped Days of C.
>
> That particular API has some semantics that proliverate bad
> programming practice, anyway - structs with trailing variable length
> data buffers. A lot of C casts, offsetof and whatever.
Structs with variable length data buffers are not "bad programming
practice".
You may not *like* them, but that's different from them being
inherently bad, even if it's a sentiment shared by many others. In
some circumstances they are the best way to solve a problem. This is
primarily the case where the overhead from keeping the variable length
data separate would be too high; a straightforward example is with
strings, which are *often* represented with a struct with variable-
length trailing data. (Indeed, I think NS/CFString does exactly this
in some cases.)
Put another way, eschewing malloc() or variable length structs in all
situations is not pragmatic---it's dogmatic, and that's never a good
way to make a decision.
Kind regards,
Alastair.
--
http://alastairs-place.net
DATE : Sun Feb 03 19:16:54 2008
On 3 Feb 2008, at 16:44, Thomas Engelmeier wrote:
> On 01.02.2008, at 18:35, John Stiles wrote:
>
>> Well, most C++ code should be using new and not malloc() anyway.
>> malloc() is a holdover from the Bad Untyped Days of C.
>
> That particular API has some semantics that proliverate bad
> programming practice, anyway - structs with trailing variable length
> data buffers. A lot of C casts, offsetof and whatever.
Structs with variable length data buffers are not "bad programming
practice".
You may not *like* them, but that's different from them being
inherently bad, even if it's a sentiment shared by many others. In
some circumstances they are the best way to solve a problem. This is
primarily the case where the overhead from keeping the variable length
data separate would be too high; a straightforward example is with
strings, which are *often* represented with a struct with variable-
length trailing data. (Indeed, I think NS/CFString does exactly this
in some cases.)
Put another way, eschewing malloc() or variable length structs in all
situations is not pragmatic---it's dogmatic, and that's never a good
way to make a decision.
Kind regards,
Alastair.
--
http://alastairs-place.net
| Related mails | Author | Date |
|---|---|---|
| John Stiles | Jan 30, 16:22 | |
| Cor | Jan 31, 00:17 | |
| Vance | Jan 31, 00:42 | |
| Uli Kusterer | Jan 31, 00:53 | |
| John Stiles | Jan 31, 01:00 | |
| Thomas Engelmeier | Jan 31, 09:22 | |
| Jiva DeVoe | Jan 31, 16:17 | |
| Shawn Erickson | Jan 31, 17:39 | |
| Shawn Erickson | Jan 31, 17:40 | |
| John Stiles | Jan 31, 18:25 | |
| Kevin Elliott | Jan 31, 19:17 | |
| Jay Reynolds Freem… | Jan 31, 19:20 | |
| Thomas Engelmeier | Feb 1, 12:13 | |
| John Stiles | Feb 1, 18:35 | |
| Thomas Engelmeier | Feb 3, 17:44 | |
| Alastair Houghton | Feb 3, 19:16 |






Cocoa mail archive

