Boost logo

Boost :

From: John Nagle (nagle_at_[hidden])
Date: 2004-06-12 11:14:16

    I think we're back to using an abstract base class.
The hacks to get around it introduce worse problems.

    Take a look at my approach at

That's a straightforward approach. The only
fundamental objection is that you take a virtual function
call overhead on some operations.

What needs to be done to that?
Should I check it into the Boost sandbox, and
if so, how? Comments, please. Thanks.

                        John Nagle

Bill Seymour wrote:

> Rob Stewart:
>>From: John Nagle <nagle_at_[hidden]>
>>>>From: "Reece Dunn" <msclrhd_at_[hidden]>
>>>>> class fs_base
>>>>> {
>>>>> size_t len;
>>>>> szie_t capacity; // needed for buffer-safe operations
>>>>> CharT str[ 1 ];
>>>>> // string manipulation functions
>>>>> fs_base( size_t c ): capacity( c ){}
>>>>> };
>>>>> template< size_t n >
>>>>> class fixed_string: public fs_base
>>>>> {
>>>>> CharT data[ n ];
>>>>> fixed_string(): fs_base( n ){}
>>>>> };
>>> Are you assuming that "data[n]" physically follows
>>>"str[1]" in memory, and that "data[n]" can be addressed
>>>by subscripting "str[1]" out of range? ...
>>Oh, right. It was C99 that blessed the struct hack. Oh well.
> Well, yes; but the struct hack is not what the code above
> tries to do. What C99 says is that you can malloc sizeof(fs_base)
> plus some extra, then address str[2] to str[whatever up to
> malloc'd size]. Even in C99 (and even if C understood the
> C++-specific stuff in the above), there is no relationship
> between fs_base::str and fixed_string::data (except that
> they don't overlap).
> --Bill Seymour
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at