473,327 Members | 2,055 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,327 software developers and data experts.

STL string - converting to low case

Hi!

I have a STL string, which I need to convert to low case.
In VC 6 I used:
string sInputBuffer = _strlwr((char*)sBuffer.c_str());

However, now in MSVC.NET 2005 I am getting a warning, that _strlwr is
depricated. Instead, it's proposed to use _strlwr_s :
http://msdn2.microsoft.com/en-us/library/y889wzfw.aspx

How should I use this new function with STL, if I don't want to
allocate memory on heap.

Thanks.

Vadim

Jan 16 '06 #1
37 22366

Vadim wrote:
Hi!

I have a STL string, which I need to convert to low case.
In VC 6 I used:
string sInputBuffer = _strlwr((char*)sBuffer.c_str());


Try this maybe (std C++ - don't know about MVC):

std::transform( sBuffer.begin(), sBuffer.end(), sBuffer.begin(),
::tolower );

Cheers,
Andre

Jan 16 '06 #2

Vadim wrote:
Hi!

I have a STL string, which I need to convert to low case.
In VC 6 I used:
string sInputBuffer = _strlwr((char*)sBuffer.c_str());

However, now in MSVC.NET 2005 I am getting a warning, that _strlwr is
depricated. Instead, it's proposed to use _strlwr_s :
http://msdn2.microsoft.com/en-us/library/y889wzfw.aspx

How should I use this new function with STL, if I don't want to
allocate memory on heap.


Are you sure you need to convert to lower case? If all you want is
case insensitive comparison you might have a look at char_traits.

Jan 16 '06 #3
Vadim wrote:
I have a STL string, which I need to convert to low case.
In VC 6 I used:
string sInputBuffer = _strlwr((char*)sBuffer.c_str());
Ugh!
However, now in MSVC.NET 2005 I am getting a warning, that _strlwr is
depricated. Instead, it's proposed to use _strlwr_s :
http://msdn2.microsoft.com/en-us/library/y889wzfw.aspx

How should I use this new function with STL, if I don't want to
allocate memory on heap.


http://groups.google.com/groups?q=co...se&qt_s=Search

V
Jan 16 '06 #4
In article <11*********************@g14g2000cwa.googlegroups. com>,
Vadim <va*******@gmail.com> wrote:
string sInputBuffer = _strlwr((char*)sBuffer.c_str());


Ouch. I suggest you look up the definition of _strlwr.

Also, note that c_str() returns a non-modifiable c-style string.
--
Mark Ping
em****@soda.CSUA.Berkeley.EDU
Jan 16 '06 #5
Try this:

struct lowercase_func {
void operator()(std::string::value_type& v) { v = tolower(v); }
};
std::string make_lowercase(std::string s) {
for_each(s.begin(), s.end(), lowercase_func());
return s;
}

Jan 17 '06 #6
In message <11**********************@g49g2000cwa.googlegroups .com>,
at******@gmail.com writes
Try this:

struct lowercase_func {
void operator()(std::string::value_type& v) { v = tolower(v); }
};
std::string make_lowercase(std::string s) {
for_each(s.begin(), s.end(), lowercase_func());
return s;
}

But for_each is intended to be a non-modifying operation. OK, it will
work, but std::transform(s.begin(), s.end(), s.begin(), tolower) would
more clearly express your intention.

--
Richard Herring
Jan 17 '06 #7

ro**********@gmail.com wrote:
Are you sure you need to convert to lower case? If all you want is
case insensitive comparison you might have a look at char_traits.


and exactly which function of char_traits would you use to do that?

Jan 17 '06 #8
Thanks for your help.
In fact, I do need to make some case insensitive finds, but since some
parts of my original string I will have to convert later to unified
case, I decieded to convert the original string to low case. It seems
that there is no any perfoamnce problem. 250 Kb file in my string is
converted to low case almost without seeing delay in "Step over"
debugging.

I do have perfomance problem with reading from file and I guess you can
help me:
I have a text file, which I read entirely to my string variable.
Originally I made some checks while reading, so my code looks like
that:

ifstream is;
is.open (INPUT_FILE);
string sInputBuffer;

while (is.good())
{
sInputBuffer+= is.get();
}

Now, I just only read the contents of the file to string buffer.
Reading char after char is definitely the bad thing. What would be the
most efficient way of reading the whole file?

Thanks a lot!

Vadim

Jan 17 '06 #9
> >
struct lowercase_func {
void operator()(std::string::value_type& v) { v = tolower(v); }
};
std::string make_lowercase(std::string s) {
for_each(s.begin(), s.end(), lowercase_func());
return s;
}

But for_each is intended to be a non-modifying operation. OK, it will
work, but std::transform(s.begin(), s.end(), s.begin(), tolower) would
more clearly express your intention.


You're right, std::transform should probably be used instead. However
(you may already know this) the direct usage of tolower is not
portable. See the discussion at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11108

Aaron

Jan 17 '06 #10

Richard Herring wrote:
In message <11**********************@g49g2000cwa.googlegroups .com>,
at******@gmail.com writes
Try this:

struct lowercase_func {
void operator()(std::string::value_type& v) { v = tolower(v); }
};
std::string make_lowercase(std::string s) {
for_each(s.begin(), s.end(), lowercase_func());
return s;
}

But for_each is intended to be a non-modifying operation. OK, it will
work, but std::transform(s.begin(), s.end(), s.begin(), tolower) would
more clearly express your intention.


Except transform does not modify the original, for_each does (so I
don's see how you can make that first statement actually). You can use
transform to modify like above but it is actually slower that using
for_each because you are copying AND assigning whereas for_each will
modify directly without either of those operations...although in this
particular case you do that anyway so it may be faster to use transform
and loose the extra call.

In every book I have ever seen for_each is listed as a modifying
algorithm along with transform, merge, fill, generate, etc... It is
perfectly legitimate to use it as such and quite common to do so.

Jan 17 '06 #11
In message <11**********************@g47g2000cwa.googlegroups .com>,
ro**********@gmail.com writes

Richard Herring wrote:
In message <11**********************@g49g2000cwa.googlegroups .com>,
at******@gmail.com writes
>Try this:
>
>struct lowercase_func {
> void operator()(std::string::value_type& v) { v = tolower(v); }
>};
>std::string make_lowercase(std::string s) {
> for_each(s.begin(), s.end(), lowercase_func());
> return s;
>}
> But for_each is intended to be a non-modifying operation. OK, it will
work, but std::transform(s.begin(), s.end(), s.begin(), tolower) would
more clearly express your intention.


Except transform does not modify the original, for_each does (so I
don's see how you can make that first statement actually).


I make it because for_each appears in section 25.1.1 of the Standard at
25.1.1, the first sub-section of 25.1, "Non-modifying sequence
operations". The first two parameters of for_each are only required to
be input iterators and its "Effects" clause does not say that anything
pointed to by the iterators is modified.
You can use
transform to modify like above but it is actually slower that using
for_each because you are copying AND assigning whereas for_each will
modify directly without either of those operations...although in this
particular case you do that anyway so it may be faster to use transform
and loose the extra call.

In every book I have ever seen for_each is listed as a modifying
algorithm along with transform, merge, fill, generate, etc...
That might surprise the authors of the Standard.
It is
perfectly legitimate to use it as such
It's an obvious extension of the semantics required by the Standard,
provided that you pass parameters which happen to satisfy the
requirements of a mutable iterator. I'll leave it to the language
lawyers to argue whether that translates to "perfectly legitimate".
and quite common to do so.


--
Richard Herring
Jan 17 '06 #12

Richard Herring wrote:
In message <11**********************@g47g2000cwa.googlegroups .com>,
ro**********@gmail.com writes

In every book I have ever seen for_each is listed as a modifying
algorithm along with transform, merge, fill, generate, etc...


That might surprise the authors of the Standard.


Only if they have completely independent, dual personalities.

By "authors of the Standard" I assume you mean people who were on the
committee...if you are talking about the people that did the
typesetting I don't know, nor do I care, what surprises them or doesn't.

Jan 17 '06 #13
In message <11**********************@o13g2000cwo.googlegroups .com>,
ro**********@gmail.com writes

Richard Herring wrote:
In message <11**********************@g47g2000cwa.googlegroups .com>,
ro**********@gmail.com writes
>In every book I have ever seen for_each is listed as a modifying
>algorithm along with transform, merge, fill, generate, etc...

Let's see...

How about Bjarne Stroustrup, "The C++ Programming language", Third
Edition, where for_each is described in section 18.5, "Nonmodifying
Sequence Algorithms" ? Granted, he goes on to explain how it can be used
as a modifying algorithm, but it's quite definitely in the nonmodifying
section of the relevant chapter.

Or Matthew H Austern, "Generic Programming and the STL", where for_each
is in chapter 11, "Nonmutating Algorithms"?

That might surprise the authors of the Standard.


Only if they have completely independent, dual personalities.

By "authors of the Standard" I assume you mean people who were on the
committee...


I mean those who assigned for_each to the category of non-modifying
sequence operations in the Standard. And who make no reference in the
same standard to using it with anything other than forward iterators,
and no mention of it modifying the sequence.
if you are talking about the people that did the
typesetting I don't know, nor do I care, what surprises them or doesn't.

I don't believe typographical error is involved here.

--
Richard Herring
Jan 17 '06 #14

ro**********@gmail.com wrote:
Only if they have completely independent, dual personalities.

By "authors of the Standard" I assume you mean people who were on the
committee...if you are talking about the people that did the
typesetting I don't know, nor do I care, what surprises them or doesn't.
If you really want a modifying for_each then write one.

template
<
typename InOutIter,
typename Op

Op for_each2( InOutIter start, const InOutIter & end, Op op )
{
for( ; start != end ; ++start )
{
op( *start );
}
return op;
}

Not exactly difficult now was that.

Jan 17 '06 #15
On 17 Jan 2006 05:17:49 -0800, "Vadim" <va*******@gmail.com> wrote:
Now, I just only read the contents of the file to string buffer.
Reading char after char is definitely the bad thing. What would be the
most efficient way of reading the whole file?


Look at getline(). It reads a whole line at a time.

rossum
--

The ultimate truth is that there is no ultimate truth
Jan 17 '06 #16

Earl Purple wrote:
ro**********@gmail.com wrote:
Only if they have completely independent, dual personalities.

By "authors of the Standard" I assume you mean people who were on the
committee...if you are talking about the people that did the
typesetting I don't know, nor do I care, what surprises them or doesn't.
If you really want a modifying for_each then write one.


You don't need to.
Not exactly difficult now was that.


I really fail to understand what call there was for that.

Jan 17 '06 #17

ro**********@gmail.com wrote:

You don't need to.
Not with most implementations but according to the standard, someone
might implement for_each to not work in writable mode, in which case
there would be a need to.
I really fail to understand what call there was for that.


By the way you still haven't answered my post above on how you would
implement case-insensitive lookup using char_traits.

Jan 18 '06 #18
In article <B2**************@baesystems.com>,
Richard Herring <ju**@[127.0.0.1]> wrote:
In message <11**********************@o13g2000cwo.googlegroups .com>,
ro**********@gmail.com writes

Richard Herring wrote:
In message <11**********************@g47g2000cwa.googlegroups .com>,
ro**********@gmail.com writes

>In every book I have ever seen for_each is listed as a modifying
>algorithm along with transform, merge, fill, generate, etc...


Let's see...

How about Bjarne Stroustrup, "The C++ Programming language", Third
Edition, where for_each is described in section 18.5, "Nonmodifying
Sequence Algorithms" ? Granted, he goes on to explain how it can be used
as a modifying algorithm, but it's quite definitely in the nonmodifying
section of the relevant chapter.


Let's do that...

The for_each() algorithm is classified as nonmodifying because it
doesn't explicitly modify a sequence. However, if applied to a
non-const sequence for_each()'s operation (its third argument) may
change the elements of the sequence."

He even gives an example. Hummm...

You see, a "modifying" algorithm is called such because it explicitly
changes some sequence, not because it allows a sequence to be changed.

--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.
Jan 18 '06 #19
In message <po******************************@news.east.earthl ink.net>,
Daniel T. <po********@earthlink.net> writes
In article <B2**************@baesystems.com>,
Richard Herring <ju**@[127.0.0.1]> wrote:
In message <11**********************@o13g2000cwo.googlegroups .com>,
ro**********@gmail.com writes
>
>Richard Herring wrote:
>> In message <11**********************@g47g2000cwa.googlegroups .com>,
>> ro**********@gmail.com writes
>
>> >In every book I have ever seen for_each is listed as a modifying
>> >algorithm along with transform, merge, fill, generate, etc...


Let's see...

How about Bjarne Stroustrup, "The C++ Programming language", Third
Edition, where for_each is described in section 18.5, "Nonmodifying
Sequence Algorithms" ? Granted, he goes on to explain how it can be used
as a modifying algorithm, but it's quite definitely in the nonmodifying
section of the relevant chapter.


Let's do that...

The for_each() algorithm is classified as nonmodifying because it
doesn't explicitly modify a sequence. However, if applied to a
non-const sequence for_each()'s operation (its third argument) may
change the elements of the sequence."

He even gives an example. Hummm...

You see, a "modifying" algorithm is called such because it explicitly
changes some sequence, not because it allows a sequence to be changed.


Right. So according to that definition too, for_each is not a modifying
algorithm.

--
Richard Herring
Jan 18 '06 #20

Richard Herring wrote:
In message <po******************************@news.east.earthl ink.net>,
Daniel T. <po********@earthlink.net> writes
In article <B2**************@baesystems.com>,
Richard Herring <ju**@[127.0.0.1]> wrote:
In message <11**********************@o13g2000cwo.googlegroups .com>,
ro**********@gmail.com writes
>
>Richard Herring wrote:
>> In message <11**********************@g47g2000cwa.googlegroups .com>,
>> ro**********@gmail.com writes
>
>> >In every book I have ever seen for_each is listed as a modifying
>> >algorithm along with transform, merge, fill, generate, etc...

Let's see...

How about Bjarne Stroustrup, "The C++ Programming language", Third
Edition, where for_each is described in section 18.5, "Nonmodifying
Sequence Algorithms" ? Granted, he goes on to explain how it can be used
as a modifying algorithm, but it's quite definitely in the nonmodifying
section of the relevant chapter.


Let's do that...

The for_each() algorithm is classified as nonmodifying because it
doesn't explicitly modify a sequence. However, if applied to a
non-const sequence for_each()'s operation (its third argument) may
change the elements of the sequence."

He even gives an example. Hummm...

You see, a "modifying" algorithm is called such because it explicitly
changes some sequence, not because it allows a sequence to be changed.


Right. So according to that definition too, for_each is not a modifying
algorithm.


According to some arbitrary definition for_each may be classified as a
non-modifying algorithm (but for practical purposes it is and one of
its primary uses is to modify every element in a sequence. Running to
the standard, which picks such an arbitrary definition because
standards have to, to back the assertion that it shouldn't be used for
such purposes is silly. The standard does not require that the
operator has no side effects and so long as you are passing a mutable
iterator and can bypass item assignment it is very likely to be in you
best interests to do so.

Jan 18 '06 #21

Earl Purple wrote:
ro**********@gmail.com wrote:

You don't need to.
Not with most implementations but according to the standard, someone
might implement for_each to not work in writable mode, in which case
there would be a need to.


Would require a casting of a template type to a const version of that
type. VERY unlikely and would turn up very quickly. This is a
non-issue.
I really fail to understand what call there was for that.


By the way you still haven't answered my post above on how you would
implement case-insensitive lookup using char_traits.


I didn't read such a post and if you are really interested go read
Thinking in C++ v2 or any other book that talks about
char_traits....hell, do a google search. I'm not doing your homework
for you.

Jan 18 '06 #22

ro**********@gmail.com wrote:
I didn't read such a post and if you are really interested go read
Thinking in C++ v2 or any other book that talks about
char_traits....hell, do a google search. I'm not doing your homework
for you.


It's not my homework, it's yours. You said it could be done with
char_traits so I am asking you to prove it.

Jan 18 '06 #23

Earl Purple wrote:
ro**********@gmail.com wrote:
I didn't read such a post and if you are really interested go read
Thinking in C++ v2 or any other book that talks about
char_traits....hell, do a google search. I'm not doing your homework
for you.


It's not my homework, it's yours. You said it could be done with
char_traits so I am asking you to prove it.


I gave you a direct source. The very same source I first learned the
technique from in fact. You can get this source for free on the
Internet.

I don't have, need, or want to prove anything to you. If you are
actually interested in learning you have all the information you need
to go do so. If, as it seems, you just want to hassle someone about
advice they gave to someone else (and just an idea that could be looked
into at that) then you are wasting my time, and I don't like that.

This is as far as I go.

Jan 18 '06 #24
In message <11**********************@g44g2000cwa.googlegroups .com>,
ro**********@gmail.com writes

Richard Herring wrote:
In message <po******************************@news.east.earthl ink.net>,
Daniel T. <po********@earthlink.net> writes
>In article <B2**************@baesystems.com>,
> Richard Herring <ju**@[127.0.0.1]> wrote:
>
>> In message <11**********************@o13g2000cwo.googlegroups .com>,
>> ro**********@gmail.com writes
>> >
>> >Richard Herring wrote:
>> >> In message <11**********************@g47g2000cwa.googlegroups .com>,
>> >> ro**********@gmail.com writes
>> >
>> >> >In every book I have ever seen for_each is listed as a modifying
>> >> >algorithm along with transform, merge, fill, generate, etc...
>>
>> Let's see...
>>
>> How about Bjarne Stroustrup, "The C++ Programming language", Third
>> Edition, where for_each is described in section 18.5, "Nonmodifying
>> Sequence Algorithms" ? Granted, he goes on to explain how it can be used
>> as a modifying algorithm, but it's quite definitely in the nonmodifying
>> section of the relevant chapter.
>
>Let's do that...
>
> The for_each() algorithm is classified as nonmodifying because it
> doesn't explicitly modify a sequence. However, if applied to a
> non-const sequence for_each()'s operation (its third argument) may
> change the elements of the sequence."
>
>He even gives an example. Hummm...
>
>You see, a "modifying" algorithm is called such because it explicitly
>changes some sequence, not because it allows a sequence to be changed.
Right. So according to that definition too, for_each is not a modifying
algorithm.


According to some arbitrary definition for_each may be classified as a
non-modifying algorithm (but for practical purposes it is and one of
its primary uses is to modify every element in a sequence. Running to
the standard, which picks such an arbitrary definition because
standards have to,


This particular standard is full of footnotes and other clarifying text
where such a decision could be justified if it truly was arbitrary, but
on this issue it's silent.
to back the assertion that it shouldn't be used for
such purposes is silly.
(No sillier than claiming that "every book" backs the opposite view.)

If I had made any such assertion, it would indeed be silly. All I said
was that since for_each is classified as non-modifying, using an
explicitly modifying algorithm, std::transform, would more clearly
express the original poster's intent.
The standard does not require that the
operator has no side effects and so long as you are passing a mutable
iterator and can bypass item assignment it is very likely to be in you
best interests to do so.

Possibly. Since in the original example assignment still occurs when
using for_each, the hypothetical performance improvement of bypassing it
doesn't arise here.

--
Richard Herring
Jan 18 '06 #25

Richard Herring wrote:
In message <11**********************@g44g2000cwa.googlegroups .com>,
ro**********@gmail.com writes

The standard does not require that the
operator has no side effects and so long as you are passing a mutable
iterator and can bypass item assignment it is very likely to be in you
best interests to do so.

Possibly. Since in the original example assignment still occurs when
using for_each, the hypothetical performance improvement of bypassing it
doesn't arise here.


I stated such in my original reply...maybe you should read it again.

Jan 18 '06 #26

ro**********@gmail.com wrote:

I don't have, need, or want to prove anything to you. If you are
actually interested in learning you have all the information you need
to go do so. If, as it seems, you just want to hassle someone about
advice they gave to someone else (and just an idea that could be looked
into at that) then you are wasting my time, and I don't like that.

This is as far as I go.


It's because you don't know. And I do know because I have implemented a
specialised version of char_traits. And I know that char_traits has a
compare() function but that is equivalent to memcmp() and has no
knowledge of lower and upper-case at all.

If there were such a function it would be in locale but even there it
doesn't actually exist.

Jan 18 '06 #27

Earl Purple wrote:
ro**********@gmail.com wrote:

I don't have, need, or want to prove anything to you. If you are
actually interested in learning you have all the information you need
to go do so. If, as it seems, you just want to hassle someone about
advice they gave to someone else (and just an idea that could be looked
into at that) then you are wasting my time, and I don't like that.

This is as far as I go.


It's because you don't know. And I do know because I have implemented a
specialised version of char_traits.


Then you already know how to do it and you are just being a jerk for no
reason that is apparent to me.

Goodbye now...have fun with that attitude.

Jan 18 '06 #28

ro**********@gmail.com wrote:

Then you already know how to do it and you are just being a jerk for no
reason that is apparent to me.

Goodbye now...have fun with that attitude.


Well I don't know how to do it with char_traits, I think it is
impossible. It is possible to do wtih locale but not directly, i.e. you
have to use a tolower or toupper member of locale, because I am not
aware of any general string conversion or case-insensitive comparison
method in locale.

I do think there should be a case-sensitive comparison in C++ and I
think locale would be the correct library in which to implement it.

Jan 18 '06 #29

Earl Purple wrote:
ro**********@gmail.com wrote:

Then you already know how to do it and you are just being a jerk for no
reason that is apparent to me.

Goodbye now...have fun with that attitude.


Well I don't know how to do it with char_traits, I think it is
impossible.


Well, like I said, you now know of and have ready access to the very
source I got the technique from. I believe it is also explained in
Josuttis but I may be mistaken. You can read it, learn it, and make up
your own mind whether to use it.

Jan 18 '06 #30

ro**********@gmail.com wrote:
Earl Purple wrote:
It's not my homework, it's yours. You said it could be done with
char_traits so I am asking you to prove it.


I gave you a direct source.


I can't see that. What am I missing?

You brought up a very interesting topic (using char_traits for case
insensitive string comparisons). It would have been nice if you would
have elaborated more on the topic (for all our benefit).

Failing to see your source, here's what I came up with on Herb Sutter's
page:
http://www.gotw.ca/gotw/029.htm

<synopsis>
The article by Herb Sutter outlines how to generate your own string
class that does everything stl::string does, but compares strings
independend of their case. He does so by creating a new ci_char_traits
class and defining a new string type:
typedef basic_string<char, ci_char_traits> ci_string;
</synopsis>

The use of char_traits for this is very intruiging. Especially given
the fact that char_traits usuaally have been in the "black magic" camp
of the STL for me so far.

Cheers,
Andre

Jan 18 '06 #31

in*****@gmail.com wrote:
ro**********@gmail.com wrote:
Earl Purple wrote:
It's not my homework, it's yours. You said it could be done with
char_traits so I am asking you to prove it.


I gave you a direct source.


I can't see that. What am I missing?


The rest of my post.

Thinking in C++ v2.

Jan 18 '06 #32

in*****@gmail.com wrote:
<synopsis>
The article by Herb Sutter outlines how to generate your own string
class that does everything stl::string does, but compares strings
independend of their case. He does so by creating a new ci_char_traits
class and defining a new string type:
typedef basic_string<char, ci_char_traits> ci_string;
</synopsis>


If you did that you'd have to implement the compare function but doing
that will still require a toupper or tolower call.

Is it really worth rewriting the whole of char_traits just to do that?
You may as well just write a comparison functor (so you can use it as a
predicate in std::map).

Jan 18 '06 #33
Sorry Roberts, but you act like a troll.

It's clear you "wondered" it is easy to implement it with char_traits

Or you may be nice and explain to Earl and to us how to implement it :)

This is the purpose of newsgroups

Jan 19 '06 #34
Diego Martins wrote:
Sorry Roberts, but you act like a troll.

It's clear you "wondered" it is easy to implement it with char_traits

Or you may be nice and explain to Earl and to us how to implement it :)

This is the purpose of newsgroups


You can do case insensitive comparisons with strings if you use/create
the strings with the correct char_traits. Stroustrup talks about this
in his book "The C++ Programming Language" 3rd edition. I don't
remember the exact pages, but I'm pretty sure it's in the "Strings"
chapter.

You basically create a "ci_string" class like so:
typedef basic_string<char, ct> ci_string;

....where "ct" is your own char_traits class. The char_traits class has
a "eq" function that returns true if two chars are "equivalent". (It
also has many other functions as well.)

I don't really like this approach because you're defining a new kind of
"case insensitive string" that are essentially incompatible with all
"normal" strings, and are thus useless for lots of operations that you
would normally like to do with them (like many iostream operations).

Aaron

Jan 19 '06 #35

Diego Martins wrote:
Sorry Roberts, but you act like a troll.

It's clear you "wondered" it is easy to implement it with char_traits
I don't understand that statement.

Or you may be nice and explain to Earl and to us how to implement it :)


I did better. I gave a source. Why give a half ass explaination when
an expert source is readily available? God, for free even...

You people that are bitching about this are just lazy. Go download and
read "Thinking in C++ V2" if you are truely interested. I really don't
think you are and so you probably won't and will continue complaining...

Jan 19 '06 #36

Aaron Graham wrote:
I don't really like this approach because you're defining a new kind of
"case insensitive string" that are essentially incompatible with all
"normal" strings, and are thus useless for lots of operations that you
would normally like to do with them (like many iostream operations).


Yeah, all your streams and such have to use those traits in order to
read directly and you can't assign to or copy directly into 'normal'
strings. It can be a useful technique though in some cases.

Jan 19 '06 #37
Which cases?

Jan 20 '06 #38

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
by: karthi | last post by:
hi, I need user defined function that converts string to float in c. since the library function atof and strtod occupies large space in my processor memory I can't use it in my code. regards,...
2
by: Edvin | last post by:
Why is binary array written to a file different than when converting the binary array to string and then writing it to file! For example: // --- Allocate byte array byte arrByte = new byte;...
4
by: Russell Warren | last post by:
I've got a case where I want to convert binary blocks of data (various ctypes objects) to base64 strings. The conversion calls in the base64 module expect strings as input, so right now I'm...
2
by: Brian Parker | last post by:
I am beginning to work with VB2005.NET and I'm getting some problems with string formatting converting an application from VB6. VB6 code:- sTradeDate = Format(pArray(4,i Record), "mmddyy") ...
21
by: phpCodeHead | last post by:
Code which should allow my constructor to accept arguments: <?php class Person { function __construct($name) { $this->name = $name; } function getName()
14
by: Mosfet | last post by:
Hi, what is the most efficient way of doing a case insensitive comparison ? I am trying to write a universal String class and I am stuck with the case insensitive part : TCHAR is a char in...
16
by: gaga | last post by:
my function should accept a pointer to a string as its argument. and it should convert each charater to an uppercase letter. I know what i need to do, its just my syntax is all out of whack. ...
4
by: J Peyret | last post by:
Well, as usual I am confused by unicode encoding errors. I have a string with problematic characters in it which I'd like to put into a postgresql table. That results in a postgresql error so I...
14
by: Jamenson | last post by:
Hi everyone! I want to convert strings like "LEONARDO DI CAPRIO" to "Leonardo di Caprio". The function StrConv converts to "Leonardo Di Caprio" and we think it is innapropriated. Any help...
3
by: kronus | last post by:
I'm receiving an xml file that has a child called modified and it represents a date value in the form of a string -- Nov 14, 2008 -- and in my app, I have items associated with each object and I'm...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.