std::string vs. Unicode UTF-8

[kuyper@wizard.net]

Re: std::string vs. Unicode UTF-8

Simon Bone wrote:[color=blue]
> On Thu, 06 Oct 2005 00:20:59 -0600, kuyper wrote:
>
>[color=green]
> > What might be worthwhile is to require some actual support for Unicode.
> > I'm not sure it's a good idea to impose such a requirement; there's a
> > real advantage to giving implementors the freedom to not support
> > Unicode if they know that their particular customer base has no need
> > for it. However, such a requirement would at least guarantee some
> > benefit to some users, which requiring wchar_t to be at least 16 bits
> > would NOT do.
> >[/color]
>
> Like the freedom not to implement export because no-one in their customer
> base needs it? ;-)[/color]

Not really. The freedom to not implement export exists because
customers don't insist that an implementation be fully conforming in
that regard. The freedom to provide a trivial implementation of wide
characters is available because the standard is quite deliberatly
designed to allow even a fully conforming implementation to provide
such an implementation. Those freedoms seem quite different to me.
[color=blue]
> I think standard Unicode support would be more widely appreciated than
> export. ...[/color]

Perhaps; I can't speak for anyone but myself. Personally, in my current
job I have absolutely no need for Unicode support, or even support for
any encoding other than US ASCII, nor for any locale other than the "C"
locale. On the other hand, I'd love to be able to use "export". I'm not
opposed to supporting other locales, it just isn't relevant on my
current job.

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.e du ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

[Simon Bone]

Re: std::string vs. Unicode UTF-8

On Fri, 07 Oct 2005 06:20:01 +0000, kuyper wrote:
[color=blue]
> Simon Bone wrote:[color=green]
>> On Thu, 06 Oct 2005 00:20:59 -0600, kuyper wrote:
>>
>>[color=darkred]
>> > What might be worthwhile is to require some actual support for Unicode.
>> > I'm not sure it's a good idea to impose such a requirement; there's a
>> > real advantage to giving implementors the freedom to not support
>> > Unicode if they know that their particular customer base has no need
>> > for it. However, such a requirement would at least guarantee some
>> > benefit to some users, which requiring wchar_t to be at least 16 bits
>> > would NOT do.
>> >[/color]
>>
>> Like the freedom not to implement export because no-one in their customer
>> base needs it? ;-)[/color]
>
> Not really. The freedom to not implement export exists because
> customers don't insist that an implementation be fully conforming in
> that regard. The freedom to provide a trivial implementation of wide
> characters is available because the standard is quite deliberatly
> designed to allow even a fully conforming implementation to provide
> such an implementation. Those freedoms seem quite different to me.
>[/color]

I didn't intend to compare the C++98 export requirements to the C++98
wide character requirements, but rather to some hypothetical C++0x Unicode
requirements.

At the moment, implementors have a freedom in how they implement wide
character support that in practice seems to make writing portable programs
that handle plain text more difficult than it needs to be. Adding a
requirement to support Unicode directly would help IMO.
[color=blue][color=green]
>> I think standard Unicode support would be more[/color][/color]
widely appreciated than[color=blue][color=green]
>> export. ...[/color]
>
> Perhaps; I can't speak for anyone but myself. Personally, in my current
> job I have absolutely no need for Unicode support, or even support for
> any encoding other than US ASCII, nor for any locale other than the "C"
> locale. On the other hand, I'd love to be able to use "export". I'm not
> opposed to supporting other locales, it just isn't relevant on my
> current job.
>[/color]

I find support for extended characters in most of the software I use, even
if not in all I write. Unicode really has become very widespread - enough
to be considered as portable as US ASCII ever was. So I would like support
guaranteed by the standard.

And for what its worth, I think I'd like to be able to use export too. I'm
not trying to argue for losing that (or even the hope of that), but
rather for increased requirements in plain text handling facilities. I
think a standard Unicode library would be widely enough implemented to
displace most of the various libraries currently used. It is enough of a
hassle to pass Unicode data around between different codebases now to be
worth fixing this.

I feel a lot of C++ code right now is probably using one or another
library to solve the need to use Unicode. Moving to a future where most
code needing this support uses a single, well specified interface would be
a big improvement.

If a particular implementor sees their customers as not needing this, no
doubt they will ship without it, regardless of what the standard says.
This could well happen for some compilers targeting embedded systems; and
that is not a change. Lots of implementations have rough edges and when a
particular C++ codebase is ported, problems are often found. It doesn't
mean we should give up any hope of a useful standard. Rather, it helps us
work out who is to blame or at least where the extra work should be
targeted (at improving the compiler or changing the codebase).

Simon Bone

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.e du ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

[quisam]

ResourceManager , suspend to disk

Hi,

I've been out of C++ now for around 9 years. (Doing java since then)
For an upcoming project I have to get back into it.

So I have been looking around what changed in the last ten years in the
C++ world and found interesting things like STL, boost, ICU, etc.

Now I'm looking for a solution for the following problem:

I need some kind of RessourceManage r, which is able to suspend
some threads and dump their memory to disk. It must maintain
dependencies between ressources and should be as transparanet
as possible to the rest of the source code.

I think a starting point would be to use an Allocator which is connected
to a ResourceManager .

Is there any standard way, which I haven't found, to do this?

Many thanks for any answer!
Markus