By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,905 Members | 1,293 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,905 IT Pros & Developers. It's quick & easy.

CString functions

P: n/a
I want to do the following to strings:

1) Check if first four characters are "DATA"

2) Get the middle 'word' from the following string "DATA 123 xyz" (the
middle word is variable length) - extract the "123".

3) Get the last word/number from the following string "DATA SEND 1467436267"

What functions should I use to achieve this? I'm new to C++ and finding
string manipulation tricky.
Oct 22 '05 #1
Share this Question
Share on Google+
25 Replies


P: n/a

Gareth wrote:
I want to do the following to strings:

1) Check if first four characters are "DATA"

2) Get the middle 'word' from the following string "DATA 123 xyz" (the
middle word is variable length) - extract the "123".

3) Get the last word/number from the following string "DATA SEND 1467436267"

What functions should I use to achieve this? I'm new to C++ and finding
string manipulation tricky.


If you use CString it provides lots of facilities for this. Have a look
at -

CString::Left
CString::Mid
CString::Right
CString::Find
CString::Tokenize

Regards,

Hugh

Oct 22 '05 #2

P: n/a
Gareth wrote:
I want to do the following to strings:

1) Check if first four characters are "DATA"

2) Get the middle 'word' from the following string "DATA 123 xyz" (the
middle word is variable length) - extract the "123".

3) Get the last word/number from the following string "DATA SEND 1467436267"

What functions should I use to achieve this? I'm new to C++ and finding
string manipulation tricky.


CString is not a standard C++ class. Look in a microsoft.public.*
newsgrouop for CString.

For std::string, use :

std::string::substr(),
std::string::find_first_of()
std::string::find_last_of()

Oct 22 '05 #3

P: n/a
"red floyd" <no*****@here.dude> wrote in message
news:c8*****************@newssvr29.news.prodigy.ne t...
CString is not a standard C++ class. Look in a microsoft.public.*
newsgrouop for CString.


.... This is posted to microsoft.public.vc.language and
microsoft.public.vc.mfc where, I might add, we recently came up with the
conclusion that CString rules! :)

--
- Mark Randall
http://zetech.swehli.com

"Those people that think they know everything are a great annoyance to those
of us who do"
Isaac Asimov
Oct 22 '05 #4

P: n/a
I definitely agree, CString rules, all methods contained in the class will
do what the original post wanted. This one class will do it all for him.

john

"Mark Randall" <mark[__OKTHISISFAKE_]yr@REMOVETHISgoogle.ANDTHIScom> wrote
in message news:uu**************@TK2MSFTNGP09.phx.gbl...
"red floyd" <no*****@here.dude> wrote in message
news:c8*****************@newssvr29.news.prodigy.ne t...
CString is not a standard C++ class. Look in a microsoft.public.*
newsgrouop for CString.
... This is posted to microsoft.public.vc.language and
microsoft.public.vc.mfc where, I might add, we recently came up with the
conclusion that CString rules! :)

--
- Mark Randall
http://zetech.swehli.com

"Those people that think they know everything are a great annoyance to

those of us who do"
Isaac Asimov

Oct 23 '05 #5

P: n/a
> "red floyd" <no*****@here.dude> wrote in message
news:c8*****************@newssvr29.news.prodigy.ne t...
CString is not a standard C++ class. Look in a microsoft.public.*
newsgrouop for CString.


... This is posted to microsoft.public.vc.language and
microsoft.public.vc.mfc where, I might add, we recently came up with the
conclusion that CString rules! :)


Who is "we"? IMHO CString is not that good, (not thread safe, bloated, and
so on), but as red floyd mentioned this is OT here.

Simon
Oct 23 '05 #6

P: n/a
http://www.techenclave.com/forums/pa...n-22038-4.html

--
- Mark Randall
http://zetech.swehli.com

"Those people that think they know everything are a great annoyance to those
of us who do"
Isaac Asimov

"Simon" <sp********@example.com> wrote in message
news:3s************@individual.net...
Who is "we"? IMHO CString is not that good, (not thread safe, bloated, and
so on), but as red floyd mentioned this is OT here.

Oct 23 '05 #7

P: n/a
> http://www.techenclave.com/forums/pa...n-22038-4.html


er, thanks for the link.

regards.

Simon
Oct 23 '05 #8

P: n/a
On Sun, 23 Oct 2005 01:43:08 GMT, "The Code Master"
<Th*************@hotmail.com> wrote in comp.lang.c++:
I definitely agree, CString rules, all methods contained in the class will
do what the original post wanted. This one class will do it all for him.

john
Opinions of top-posters cheerfully ignored at every opportunity.

"Mark Randall" <mark[__OKTHISISFAKE_]yr@REMOVETHISgoogle.ANDTHIScom> wrote
in message news:uu**************@TK2MSFTNGP09.phx.gbl...
"red floyd" <no*****@here.dude> wrote in message
news:c8*****************@newssvr29.news.prodigy.ne t...


[snip]

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Oct 23 '05 #9

P: n/a
Define "bloated". What is bloated? The size of the data structures? The size of the
class? What subset do you think is non-bloated, and why should I give up the features I
need to satisfy your definition of a small class?

I have found a large number of places in std:: where there is no thread safety nor
pretension thereof; one of my students chose to use ostreams instead of FILE * in a lab
example, and the result when run multithreaded was quite a lesson to them on thread
safety. For example, there is "safety" and there is, well, safety. Which is which
depends on what you expect as "correct" behavior.

Also, if 99.9999% of the uses of a data structure are from a single thread, do you REALLY
want to pay for thread synchronization on every operation, even though it is not needed? I
am a strong believer in putting synchronization in places where it is needed and ignoring
it when it is not needed. To make classes "thread safe" you need to pay the price on
every operation.

Define "and so on".

While I agree that std:: has a lot of charm, it is clumsy to use in Windows programming,
and the "cost" of CString is actually very low for most uses. Also, it is compatible with
the MFC library.
joe

On Sun, 23 Oct 2005 10:34:43 +0100, "Simon" <sp********@example.com> wrote:
"red floyd" <no*****@here.dude> wrote in message
news:c8*****************@newssvr29.news.prodigy.ne t...
CString is not a standard C++ class. Look in a microsoft.public.*
newsgrouop for CString.


... This is posted to microsoft.public.vc.language and
microsoft.public.vc.mfc where, I might add, we recently came up with the
conclusion that CString rules! :)


Who is "we"? IMHO CString is not that good, (not thread safe, bloated, and
so on), but as red floyd mentioned this is OT here.

Simon

Joseph M. Newcomer [MVP]
email: ne******@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Oct 24 '05 #10

P: n/a
Some (most?) will say CString is MS-specific and OT here. But CString has a
bunch in common with the std libs.

1) if (str.Left(4) == "DATA") ...

2) & 3) Check your MSDN documentation. You'll want to use the "Find"
function to look for the separator char, then use the "Mid" and/or "Right"
to get the other fragments.

Alternately, you could copy the contents to a buffer and use the 'C' strtok
function.

--
---------------------------------------------------------------------
DataGet & PocketLog www.dataget.com
Data Collectors www.baxcode.com
--------------------------------------------------------------------

"Gareth" <ga****@aaa.com> wrote in message
news:yj****************@newsfe6-win.ntli.net...
I want to do the following to strings:

1) Check if first four characters are "DATA"

2) Get the middle 'word' from the following string "DATA 123 xyz" (the
middle word is variable length) - extract the "123".

3) Get the last word/number from the following string "DATA SEND 1467436267"
What functions should I use to achieve this? I'm new to C++ and finding
string manipulation tricky.

Oct 24 '05 #11

P: n/a

"Joseph M. Newcomer" <ne******@flounder.com> wrote in message
news:8c********************************@4ax.com...
Define "bloated". What is bloated? The size of the data structures? The
size of the
class? What subset do you think is non-bloated, and why should I give up
the features I
need to satisfy your definition of a small class?
I suspect you know exactly what I mean by "bloated".
CString is OK, but why use such a large class, (and MFC), just to do string
manipulations.
I have found a large number of places in std:: where there is no thread
safety nor
pretension thereof; one of my students chose to use ostreams instead of
FILE * in a lab
example, and the result when run multithreaded was quite a lesson to them
on thread
safety. For example, there is "safety" and there is, well, safety. Which
is which
depends on what you expect as "correct" behavior.
What does that mean? I understand the words, but what are you actually
trying to say?

Also, if 99.9999% of the uses of a data structure are from a single
thread, do you REALLY
want to pay for thread synchronization on every operation, even though it
is not needed? I
am a strong believer in putting synchronization in places where it is
needed and ignoring
it when it is not needed. To make classes "thread safe" you need to pay
the price on
every operation.
99.99999% in your projects maybe. Not in mine.
the std does everything CString does and is thread safe, so why not use it?
what add the overhead of MFC for string manipulations?

Define "and so on".
http://www.answers.com/and%20so%20on

While I agree that std:: has a lot of charm, it is clumsy to use in
Windows programming,
Why is it clumsy? if you are not comfortable with the std:: then that's a
different problem altogether.
and the "cost" of CString is actually very low for most uses. Also, it is
compatible with
the MFC library.
Again, this statement is not true for me and for most users in comp.land.c++
..
joe

As mentioned, the OP posted in the wrong NG in the first place.

Simon
Oct 24 '05 #12

P: n/a
> what add the overhead of MFC for string manipulations?

There is none, CString is now seperate from MFC and is template based
CStringT into CString, CStringW and CStringA.

--
- Mark Randall
http://zetech.swehli.com

"Those people that think they know everything are a great annoyance to those
of us who do"
Isaac Asimov

Oct 24 '05 #13

P: n/a
what add the overhead of MFC for string manipulations?


There is none, CString is now seperate from MFC and is template based
CStringT into CString, CStringW and CStringA.


'now'?, by that I guess you mean VS2005? or VS7.1? or VS8.0? I am still
using VS6 when doing Windows programs.

But in any case, I am glad to see that CString is moving away from MFC.

Simon
Oct 24 '05 #14

P: n/a
I agree!

Dave
"Jack Klein" <ja*******@spamcop.net> wrote in message
news:lo********************************@4ax.com...
Opinions of top-posters cheerfully ignored at every opportunity.

Oct 24 '05 #15

P: n/a

"Simon" <sp********@example.com> wrote in message
news:3s************@individual.net...
I suspect you know exactly what I mean by "bloated".
CString is OK, but why use such a large class,


Large in terms of data storage? Is it?

Large in terms of having lots of methods? That's what makes it so
useful. I don't think it has many that I haven't used at one time
or another.

Dave
--
David Webber
Author MOZART the music processor for Windows -
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm
Oct 24 '05 #16

P: n/a
I generally ignore the opinions of bottom posters. I use a news reader that
keeps the threads intact so I don't need to reread all the old stuff most of
the time. If the answer appears interesting, I can read the previous quoted
text.

"David Webber" <da**@musical.demon.co.uk> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
I agree!

Dave
"Jack Klein" <ja*******@spamcop.net> wrote in message
news:lo********************************@4ax.com...
Opinions of top-posters cheerfully ignored at every opportunity.


Oct 24 '05 #17

P: n/a

"David J. Craig" <Se*****************@shogunyoshimuni.com.net> wrote
in message news:%2****************@TK2MSFTNGP14.phx.gbl...
I generally ignore the opinions of bottom posters....

"David Webber" <da**@musical.demon.co.uk> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
I agree!

Dave
"Jack Klein" <ja*******@spamcop.net> wrote in message
news:lo********************************@4ax.com...
Opinions of top-posters cheerfully ignored at every opportunity.


I agree!

Dave
--
David Webber
Author MOZART the music processor for Windows -
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm
Oct 24 '05 #18

P: n/a
FWIW, I find bottom posting to be annoying. I have to scroll through the
entire previous message to see the response. When one top posts an answer
can be read and if the reader wants to see the original message (which they
already read before) they can scroll down to see the rest. Appropriate
trimming is required of course.

Tom

"David Webber" <da**@musical.demon.co.uk> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
I agree!

Dave
"Jack Klein" <ja*******@spamcop.net> wrote in message
news:lo********************************@4ax.com...
Opinions of top-posters cheerfully ignored at every opportunity.


Oct 24 '05 #19

P: n/a
Applause.

"David J. Craig" <Se*****************@shogunyoshimuni.com.net> wrote in
message news:%2****************@TK2MSFTNGP14.phx.gbl...
I generally ignore the opinions of bottom posters. I use a news reader
that keeps the threads intact so I don't need to reread all the old stuff
most of the time. If the answer appears interesting, I can read the
previous quoted text.

Oct 24 '05 #20

P: n/a
I agree about CString. It has always been one of my favorite MFC classes
(up there with CFile and CTime). I think people who gripe about MFC have
never taken the time to learn it. I've tried lots of other paradigms for
Windows programming (I do client desktop applications) and I can never find
anything better than MFC as a framework. It is easy to understand, makes
sense, and is definitely *not* bloated. In my opinion it's worth ever byte.

Tom

"Joseph M. Newcomer" <ne******@flounder.com> wrote in message
news:8c********************************@4ax.com...
Define "bloated". What is bloated? The size of the data structures? The
size of the
class? What subset do you think is non-bloated, and why should I give up
the features I
need to satisfy your definition of a small class?

I have found a large number of places in std:: where there is no thread
safety nor
pretension thereof; one of my students chose to use ostreams instead of
FILE * in a lab
example, and the result when run multithreaded was quite a lesson to them
on thread
safety. For example, there is "safety" and there is, well, safety. Which
is which
depends on what you expect as "correct" behavior.

Also, if 99.9999% of the uses of a data structure are from a single
thread, do you REALLY
want to pay for thread synchronization on every operation, even though it
is not needed? I
am a strong believer in putting synchronization in places where it is
needed and ignoring
it when it is not needed. To make classes "thread safe" you need to pay
the price on
every operation.

Oct 24 '05 #21

P: n/a
In article news:<#O**************@TK2MSFTNGP12.phx.gbl>, Tom Serface wrote:
FWIW, I find bottom posting to be annoying. I have to scroll through the
entire previous message to see the response. [snip] Appropriate trimming is required of course.


Exactly. With proper trimming there is nothing about bottom-posting that
should annoy anyone.

The quoted text should never be so long as to push the new material off the
bottom of the Window. Under-trimming tends to be an indicator of a poorly
considered post, and such posts can usually be disregarded with little loss.
--
Cheers,
Daniel.

Oct 24 '05 #22

P: n/a
In article news:<3s************@individual.net>, Simon wrote:
IMHO CString is not that good, (not thread safe, bloated, and
so on), ...


CString is a good deal less bloated than it's more respectable, more
standard, semi-cousin std::basic_string. It's a good choice for Windows API
programming (with MFC, which is surely on-topic here) because the APIs know
and understand it. However, instatiations of std::basic_string bay be a
better choice for back-end code that you might want to be able to use on
other platforms.

The trouble with CString is that it isn't one single class, VC6 and VS200x
have different implementations, and both of them are somewhat (and
differently) schizophrenic about Unicode. VC6s implementation uses shared
data and copy-on-write for performance, but suffers badly when strings have
to be shared between threads. VS200x's implementation doesn't share data
but does use a small-string optimization which gives perfromance benefits
in different situations.

The various implementations are all quite good -- but it pays to know which
one you are using and what its compromises are.

Cheers,
Daniel.

Oct 24 '05 #23

P: n/a
In article news:<#j**************@TK2MSFTNGP14.phx.gbl>, Tom Serface wrote:
I agree about CString. It has always been one of my favorite MFC classes
(up there with CFile and CTime).


You jest, surely. CFile and CTime have some deep and irredeemable flaws in
theirs designs, but CString gives you pretty much what it says on the tin.

Cheers,
Daniel.
Oct 24 '05 #24

P: n/a
CFile and CTime work great for me. I have run into some problems with
CTime, but nothing I could work around and nothing that made it less useful.

Oh well.

Tom

"Daniel James" <wa*********@nospam.aaisp.org> wrote in message
news:VA******************@nospam.aaisp.org...
In article news:<#j**************@TK2MSFTNGP14.phx.gbl>, Tom Serface
wrote:
I agree about CString. It has always been one of my favorite MFC classes
(up there with CFile and CTime).


You jest, surely. CFile and CTime have some deep and irredeemable flaws in
theirs designs, but CString gives you pretty much what it says on the tin.

Cheers,
Daniel.

Oct 24 '05 #25

P: n/a
See below...
On Mon, 24 Oct 2005 10:41:36 +0100, "Simon" <sp********@example.com> wrote:

"Joseph M. Newcomer" <ne******@flounder.com> wrote in message
news:8c********************************@4ax.com.. .
Define "bloated". What is bloated? The size of the data structures? The
size of the
class? What subset do you think is non-bloated, and why should I give up
the features I
need to satisfy your definition of a small class?
I suspect you know exactly what I mean by "bloated".
CString is OK, but why use such a large class, (and MFC), just to do string
manipulations.

****
No, I don't know what you mean by "bloated". I know what "bloated" is, and I don't see
that in CString, so I guess ;you have a different definition of the word that the rest of
us. Bloated would mean that it contained gratuitous methods that served no purpose.
Exactly *what* part of the CString class would you eliminate to reduce its size to
something you think is not "bloated"? Be prepared to justify each of your choices against
those of us who critically depend on those features. Also, when talking about "bloated",
make sure that you do not include features that are normally part of the C string library
(such as MakeReverse) or you will be claiming next that the str___ functions are also
"bloated". Or perhaps, just because you use a tiny subset of CString, you think that the
rest of us should give up capability to satisfy your definition of "not-bloated"?

Note: perhaps you are also confused by thinking that classes with a lot of members use a
lot of code. Has it occurred to you that many of those string members are just very thin
wrappers on the underlying C library, or Windows system facilities?
****
I have found a large number of places in std:: where there is no thread
safety nor
pretension thereof; one of my students chose to use ostreams instead of
FILE * in a lab
example, and the result when run multithreaded was quite a lesson to them
on thread
safety. For example, there is "safety" and there is, well, safety. Which
is which
depends on what you expect as "correct" behavior.
What does that mean? I understand the words, but what are you actually
trying to say?

****
What makes ;you think that std:: is "thread-safe"? Or, perhaps you have a different
interpretation of thread safety than the rest of us...I pointed out that I have seen that
ostreams, for example, exhibit characteristics of non-thread-safe functions, such as
allowing strange intermixing of output.

I just went back and read the source code for the string type (the string header file). It
is very complex code. Perhaps I might go so far as to suggest it might be bloated, but we
don't seem to agree on what this means. But I could not find any evidence of thread
safety in, for example, the append function. Perhaps you could identify, in the code
below, where the synchronization occurs? For your convenience, I have added line numbers

1 _Myt& append(const _Myt& _Right,
2 size_type _Roff, size_type _Count)
3 { // append _Right [_Roff, _Roff + _Count)
4 if (_Right.size() < _Roff)
5 _String_base::_Xran(); // _Roff off end
6 size_type _Num = _Right.size() - _Roff;
7 if (_Num < _Count)
8 _Count = _Num; // trim _Count to size
9 if (npos - _Mysize <= _Count)
10 _String_base::_Xlen(); // result too long
11
12 if (0 < _Count && _Grow(_Num = _Mysize + _Count))
13 { // make room and append new stuff
14 _Traits::copy(_Myptr() + _Mysize,
15 _Right._Myptr() + _Roff, _Count);
16 _Eos(_Num);
17 }
18 return (*this);
19 }

I note that I saw no evidence of any synchronization done by the callers, e.g., += is just
a call on append. Or pehaps your definition of "thread safe" does not actually encompass
thread safety?

Example: thread 1 has a string of length 100. Immediately after line 4 is executed, and
determines that _Roff is valid, thread 1 is suspended. Thread 2 now comes in and
truncates the string to 0 length. Oops. In fact, _Roff is now illegal. But never mind;
when thread 1 resumes, it now executes line 6, producing an erroneous result.

I see no thread safety here.
****

Also, if 99.9999% of the uses of a data structure are from a single
thread, do you REALLY
want to pay for thread synchronization on every operation, even though it
is not needed? I
am a strong believer in putting synchronization in places where it is
needed and ignoring
it when it is not needed. To make classes "thread safe" you need to pay
the price on
every operation.
99.99999% in your projects maybe. Not in mine.
the std does everything CString does and is thread safe, so why not use it?
what add the overhead of MFC for string manipulations?

****
See above. Show me where I missed the place where synchronization is actually done
between two threads appending to the same string.
****

Define "and so on".


http://www.answers.com/and%20so%20on

While I agree that std:: has a lot of charm, it is clumsy to use in
Windows programming,


Why is it clumsy? if you are not comfortable with the std:: then that's a
different problem altogether.
and the "cost" of CString is actually very low for most uses. Also, it is
compatible with
the MFC library.


Again, this statement is not true for me and for most users in comp.land.c++
.
joe

As mentioned, the OP posted in the wrong NG in the first place.

Simon

Joseph M. Newcomer [MVP]
email: ne******@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Oct 29 '05 #26

This discussion thread is closed

Replies have been disabled for this discussion.