Subject: Re: [boost] [string] proposal
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-01-29 07:06:31
> >> It might turn you away because you obviously love std::string.
> >> Generalizing is a different matter and is largely a hot-air blowing
> >> exercise that is futile for convincing anybody.
> > I would say it more clear:
> > 1. All users that use C libraries and need c_str() at boundaries
> > And this is a huge amount of users that need to communicate
> > with modules that are already working and ready but written in C.
> > And this is about of half of libraries there is C is the lowest
> > level API that allows easy bindings to all languages.
> But c_str() doesn't have to be part of the string's interface.
What is better
fd = creat(file.c_str(),0666)
fd = creat(boost::string::lineraize(file),0666)
Isn't it obvious?
> So, what was the point again?
> I know, so what is your point?
> >> >
> >> > I beg your pardon? It is efficient as all functions
> >> > are as efficient as memcpy with exceptions of overflow/underflow
> >> > happens which require some virtual functions calls
> >> > which are pretty fast as well...
> >> >
> >> > Also 99% of issues are just solved with reserve.
> >> > (and I work with text parsing, combining and processing a lot)
> >> >
> >> And you obviously don't work with systems that have to do this
> >> multiple thousand times in one second to not know what the effects of
> >> NUMA are and why allocating a contiguous amount of memory is the
> >> performance killer that it is.
> > I know, but I hadn't suggested that streambuf should use single memory
> > chunk.
> So then what's the point of making strings use a single contiguous
> memory chunk if it's not necessary?
When you create large text chunks it makes sense and then
create a sing string from it if you want.
> > I'm sorry but I think that much more real problem is that:
> > - My father in law can't use Thunderbird because he defined non-ascii
> > user name and Thunderbird fails to open the profile. So he needs to create
> > new
> > account because half of the other programs are broken when Unicode
> > paths are used!
> So fix Thunderbird.
> > - That acrobat reader can't open files with Unicode file names that
> > user have (at least it was last time I've tried it)
> So go work for Adobe and fix Acrobat Reader.
> > - That you can't write cross platform Unicode aware code using
> > simple std::string/char * or what even encoding non-aware
> > string there.
> You can, there are already libraries for that sort of thing if you
> insist on using std::string.
If the tool causes bugs and problems in every second problem,
then seems that there is a problem in the tool.
You can't fix all programs but you can make tools better
so less issues would arise.
So basically what you say that
"there is no problem with encodings in current C++ world"
I'm sorry but you are wrong.
You know what...
I'd really like your data structure if you were not
calling it string but rather bytes chunk or immutable
What you are suggesting has noting to do with text,
and I don't understand how do you fail to see this.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk