Re: string tokenizing
From: Jerry Coffin (jcoffin_at_taeus.com)
Date: 10/22/03
- Next message: Jerry Coffin: "Re: Why no copy_if?"
- Previous message: red floyd: "Is there an inverse of gmtime()?"
- In reply to: David Rubin: "Re: string tokenizing"
- Next in thread: David B. Held: "Re: string tokenizing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 22 Oct 2003 16:24:11 GMT
In article <3F902AB2.5B2944B7@nomail.com>, bogus_address@nomail.com
says...
[ ... ]
> > I'm on my laptop right now, so I don't have the standard handy to
> > check with, but I don't remember using anything that shouldn't work
> > with wchar_t, etc., as well.
>
> For example, table_size, classic_table(), and the constructor taking a
> const mask* argument are only defined in std::ctype<char> AFAIK.
Doing some looking, you're right. I may need to re-think the code a
bit.
[ ... ]
> I was suggesting that you use 'space' rather than 'mask', which, of
> course, will give you a compile error. My understanding is that mask()
> will create a mask temporary initialized to zero (since it's an integer
> type). My *guess* (although there is no guarantee) is that mask() is
> equivalent to space in most implementations.
Your guess is wrong, AFAIK. mask() creates a value that basically says
the character doesn't fit _any_ classification. I.e. it's not a space
or a digit or alphabetic, or control, or anything else. mask is
required to be a bitmask type, and if no bits are set, it doesn't
classify the character as anything at all.
> Even if it's not, an
> 'empty' table would then be full of spaces rather than some
> implementation-defined value.
...which would utterly _ruin_ its usefulness. The whole idea is to
produce a table that ONLY classifies a character as a space (for
example) if you say it should be a space. Setting it to fill the table
with a value that said everything was a space would produce utterly
useless results -- when you extract from an istream, it will skip across
anything its locale says it a space character, so doing this would
produce a ctype that always skipped across all input.
[ ... ]
> This is a subtle point. I don't have the standard in front of me, but
> isn't this covered by C++PL3ed, 12.2.2:
>
> Class objects are constructed from the bottom up: first the base,
> then the members, and then the derived class itself.
>
> This suggests to me that table_size is initialized (at least) by the
> base class constructor, and is therefore available when the tab member
> is "constructed"...
Theoretically that might cover it. Practically speaking, a number of
compilers fail when/if you try to use table_size as the size of an
array. Since I don't care to ignore those compilers, my alternative is
to write code that works with them.
--
Later,
Jerry.
The universe is a figment of its own imagination.
- Next message: Jerry Coffin: "Re: Why no copy_if?"
- Previous message: red floyd: "Is there an inverse of gmtime()?"
- In reply to: David Rubin: "Re: string tokenizing"
- Next in thread: David B. Held: "Re: string tokenizing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
