Re: pseudo-specs for a String class: tokenization

On Mon, Sep 8, 2008 at 3:44 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On Mon, 2008-09-08 at 23:52 +1200, Amos Jeffries wrote:
>
>> >>>> I'd rather add a version whcih takes the String but not the delimiters.
>
>> >>> I would recommend avoiding implicit conversions from String to anything
>> >>> and I doubt there is a reasonable set of default delimiters.
>
>> >> Why there would be an implicit conversion?
>
>> > Ask Amos -- he has suffered enough from it to give an entertaining
>> > answer :-). Or see the attached source file.
>>
>> All my failed attempts were broken the String MemBuf size separation. I
>> was attempting to expand String to implicit conversion as-is but got
>> hamstrung when memory buffers were cast to char* and the MemBuf data
>> pointer were silently converted to String's and copy-allocator size
>> asserts kicked in :-)
>>
>> This new method of attack should not encounter that due to two
>> differences. Firstly the lack of a buffer size assert :-) and lack of
>> need for an implicit conversion between the types.
>
> Which emphasizes the original point that a Tokenizer constructor that
> takes String but no delimiters is not needed and (because implicit
> conversions, in general, have many negative side-effects) should be
> avoided.
>
> BTW, besides hard-to-find bugs, implicit conversions complicate
> development because they make many compiler error or warning messages
> confusing. The compiler tries the implicit conversion whenever it
> should, and that often happens in places totally unrelated to the class
> being silently converted to, which confuses many developers.

It's fine.
Which means that a KBuf (const char *) is not a good idea, and I'll drop it.

But I'd leave the operator = and I'd leave KBuf(const char *, size_t)
in the equation.

KBuf foo="bar";
is quite convenient IMO.

-- 
 /kinkie