C Style Strings

[scroopy]

Hi,

I've always used std::string but I'm having to use a 3rd party library
that returns const char*s. Given:

char* pString1 = "Blah ";
const char* pString2 = "Blah Blah";

How do I append the contents of pString2 to pString? (giving "Blah
Blah Blah")

I looked at strcat but that crashes with an unhandled exception.

Thanks

[Andrew Poelstra]

On 2006-06-02, Noah Roberts <ro**********@g mail.com> wrote:

we******@gmail. com wrote:

Well hang on -- this is precisely where you can make an argument for C
over C++. In C since you are forced to do everything by hand, you have
the advantage of being able to do everything by hand. For example, you
use local stack based memory to back certain allocations if you know
that the lifetime of the resource is equal to the lifetime of the
function call. In C++ you can hope your compiler can figure it out; if
not it will use new/delete which eventually falls back to malloc/free
which is hundreds of times slower.

That statement about C++ is simply incorrect; I can't even imagine
where it is coming from.

I imagine that it comes from a basic understanding of stack-based memory.

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
You can lead a blind man to water but you can't make him chug it.

[Noah Roberts]

Andrew Poelstra wrote:

On 2006-06-02, Noah Roberts <ro**********@g mail.com> wrote:

we******@gmail. com wrote:

Well hang on -- this is precisely where you can make an argument for C
over C++. In C since you are forced to do everything by hand, you have
the advantage of being able to do everything by hand. For example, you
use local stack based memory to back certain allocations if you know
that the lifetime of the resource is equal to the lifetime of the
function call. In C++ you can hope your compiler can figure it out; if
not it will use new/delete which eventually falls back to malloc/free
which is hundreds of times slower.

That statement about C++ is simply incorrect; I can't even imagine
where it is coming from.

I imagine that it comes from a basic understanding of stack-based memory.

How do you figure?

[Andrew Poelstra]

On 2006-06-02, Noah Roberts <ro**********@g mail.com> wrote:

Andrew Poelstra wrote:

On 2006-06-02, Noah Roberts <ro**********@g mail.com> wrote:

>
> we******@gmail. com wrote:
>> Well hang on -- this is precisely where you can make an argument for C
>> over C++. In C since you are forced to do everything by hand, you have
>> the advantage of being able to do everything by hand. For example, you
>> use local stack based memory to back certain allocations if you know
>> that the lifetime of the resource is equal to the lifetime of the
>> function call. In C++ you can hope your compiler can figure it out; if
>> not it will use new/delete which eventually falls back to malloc/free
>> which is hundreds of times slower.
>
> That statement about C++ is simply incorrect; I can't even imagine
> where it is coming from.
>

I imagine that it comes from a basic understanding of stack-based memory.

How do you figure?

If you have stack-based memory, any memory allocated will be deallocated
by the hardware by definition when the memory is popped.

Without stack-based memory, malloc() and free() must be called (on a lower
level than C++ lets you see), which invokes the OS to manage freeing memory
and managing it.

Obviously, deallocating memory as a side effect of simply popping a stack is
many times faster than calling a function and letting the OS sort it out.

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
You can lead a blind man to water but you can't make him chug it.

[Chris Smith]

Andrew Poelstra <ap*******@loca lhost.localdoma in> wrote:

On 2006-06-02, Noah Roberts <ro**********@g mail.com> wrote:

we******@gmail. com wrote:

function call. In C++ you can hope your compiler can figure it out; if
not it will use new/delete which eventually falls back to malloc/free
which is hundreds of times slower.

That statement about C++ is simply incorrect; I can't even imagine
where it is coming from.

I imagine that it comes from a basic understanding of stack-based memory.

I don't believe the complaint was about stack memory. It was about the
incorrect statement regarding C++. The same statement may be considered
valid concerning Java, C#, VB, or C++/CLI, for example; but those are
different languages from C++. (The word "valid" should be taken lightly
there; I haven't verified the hundreds of times.)

C++ perfectly well allows programmers to allocate any "objects" (not
quite, really, since they don't own their identity so they are a sort of
2/3-object... but in C++ vocab they are objects) on the stack, with all
the accompanying performance benefits.

--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation

[Noah Roberts]

Chris Smith wrote:

Andrew Poelstra <ap*******@loca lhost.localdoma in> wrote:

On 2006-06-02, Noah Roberts <ro**********@g mail.com> wrote:

we******@gmail. com wrote:
> function call. In C++ you can hope your compiler can figure it out; if
> not it will use new/delete which eventually falls back to malloc/free
> which is hundreds of times slower.

That statement about C++ is simply incorrect; I can't even imagine
where it is coming from.

I imagine that it comes from a basic understanding of stack-based memory.

I don't believe the complaint was about stack memory. It was about the
incorrect statement regarding C++. The same statement may be considered
valid concerning Java, C#, VB, or C++/CLI, for example; but those are
different languages from C++. (The word "valid" should be taken lightly
there; I haven't verified the hundreds of times.)

C++ perfectly well allows programmers to allocate any "objects" (not
quite, really, since they don't own their identity so they are a sort of
2/3-object... but in C++ vocab they are objects) on the stack, with all
the accompanying performance benefits.

Yes, that is what I was talking about. C++ and C do not differ in the
way it was being stated.

[Malcolm]

"kwikius" <an**@servocomm .freeserve.co.u k> wrote

scroopy wrote:

Hi,

I've always used std::string but I'm having to use a 3rd party library
that returns const char*s. Given:

char* pString1 = "Blah ";
const char* pString2 = "Blah Blah";

How do I append the contents of pString2 to pString? (giving "Blah
Blah Blah")
#include <malloc.h>
#include <cstring>

char* concat(const char * str1, const char* str2)
{
char * result = (char*) malloc(strlen( str1) + strlen (str2) + 1);
if( result != NULL){
strcpy(result,s tr1);
strcat(result, str2);
}
return result;
}

Perfectly unexceptional code.
It won't execute as efficiently as it might, but then most programs can
manipulate a string much faster than a human can read it, however
inefficiently written.

If we want we can do a speed-up

void fastconcat(char *out, char *str1, char *str2)
{
while(*str1)
*out++ = *str1++;
while(*str2)
*out++ = *str2++;
*out = 0;
}

this is a bit of nuisance since it throws the burden of memory allocation
onto the user, it is also rather dangerous sinvce we don't check the buffer.
But it will be very fast. That's the beauty of C, you can roll the function
to the problem you face.
#include <iostream>
#include <string>

char* pString1 = "Blah ";
const char* pString2 = "Blah Blah";
int main()
{
// C-style
char* str = concat(pString1 ,pString2);
if(str != NULL){
std::cout << str <<'\n';
free(str);
}

// C++ style
std::string str1=std::strin g(pString1) + pString2;
Ok what's going on here?
You have a string, and now you are calling what looks like a string
constructor to create another type of string. Why do you need two types of
string in the program? Do they behave differently when passed to cout? How
do I know that they will behave in the same way?
std::cout << str1 <<'\n';
}

I'm not sure if that is the optimal C method. Its interesting to note
how much better the C++ version is though!

So what's the big - O analysis of that '+' operation? Where is this
documented? What if I want to sacrifice a bit of safety for speed, as we did
with C? Can I overload the string '+' operator to achieve this?

Apologies to our friends on C++, but this was a provocative post.
--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $7.20 paper, available www.lulu.com/bgy1mm

[Tomás]

Malcolm posted:

If we want we can do a speed-up

void fastconcat(char *out, char *str1, char *str2)
{
while(*str1)
*out++ = *str1++;
while(*str2)
*out++ = *str2++;
*out = 0;
}

I'd say that has the potential to "run slower" than a version which uses
strcpy. A system would be more efficient copying int's than char's, so
strcpy could be implemented platform-specifically as something like:

(Unchecked code:)

inline bool NoByteZero(unsi gned const v)
{
return ( ( (v & 0x7F7F7F7F) + 0x7F7F7F7F ) | v ) | 0x7F7F7F7F;
}

void strcpy(char *pdest, const char *psource)
{
int *idest = reinterpret_cas t<int*>(pdest) ;
int *isource = reinterpret_cas t<int*>(psource );

for ( ; NoByteZero(*iso urce); *idest++ = *isource++);

char *cdest = reinterpret_cas t<char*>(idest) ;
char *csource = reinterpret_cas t<char*>(isourc e);

while( *cdest++ = *csource++ );
}

(This code makes the presumption that on the given platform, it's okay to
access memory which isn't yours.)
-Tomás

[kwikius]

Malcolm wrote:

"kwikius" <an**@servocomm .freeserve.co.u k> wrote void fastconcat(char *out, char *str1, char *str2)
{
while(*str1)
*out++ = *str1++;
while(*str2)
*out++ = *str2++;
*out = 0;
}

this is a bit of nuisance since it throws the burden of memory allocation
onto the user, it is also rather dangerous sinvce we don't check the buffer.
You are joking right?
But it will be very fast. That's the beauty of C, you can roll the function
to the problem you face.
The whole point is that you cant. C doesnt give you the tools.

[..]

// C++ style
std::string str1=std::strin g(pString1) + pString2;

Ok what's going on here?
You have a string, and now you are calling what looks like a string
constructor to create another type of string.

It is the same type.

Why do you need two types of string in the program? Do they behave differently when passed to cout? How
do I know that they will behave in the same way?

std::cout << str1 <<'\n';
}
They are the same type
I'm not sure if that is the optimal C method. Its interesting to note
how much better the C++ version is though!
So what's the big - O analysis of that '+' operation? Where is this
documented?

Its part of the C++ standard library.

What if I want to sacrifice a bit of safety for speed, as we did with C? Can I overload the string '+' operator to achieve this?
Sure, as long as it doesnt clash with overloads defined in the C++
standard.
Apologies to our friends on C++, but this was a provocative post.

Sorry if the post was provocative. C is a wonderful language and I will
have to get back to it some time.

regards
Andy Little

[Barry Schwarz]

On Thu, 1 Jun 2006 21:31:58 +0100, "Malcolm"
<re*******@btin ternet.com> wrote:

"kwikius" <an**@servocomm .freeserve.co.u k> wrote

scroopy wrote:

Hi,

I've always used std::string but I'm having to use a 3rd party library
that returns const char*s. Given:

char* pString1 = "Blah ";
const char* pString2 = "Blah Blah";

How do I append the contents of pString2 to pString? (giving "Blah
Blah Blah")

#include <malloc.h>
#include <cstring>

char* concat(const char * str1, const char* str2)
{
char * result = (char*) malloc(strlen( str1) + strlen (str2) + 1);
if( result != NULL){
strcpy(result,s tr1);
strcat(result, str2);
}
return result;
}

Perfectly unexceptional code.
It won't execute as efficiently as it might, but then most programs can
manipulate a string much faster than a human can read it, however
inefficientl y written.

If we want we can do a speed-up

void fastconcat(char *out, char *str1, char *str2)
{
while(*str1)
*out++ = *str1++;
while(*str2)
*out++ = *str2++;
*out = 0;
}

Why do you believe that manually stepping through each character will
be faster when strcpy and strcat can take advantage of any CISC
instructions the hardware might offer?
Remove del for email

[Jerry Coffin]

In article <5u************ *************** *****@4ax.com>,
sc******@doezl. net says...

[ ... ]

strcpy(result,s tr1);
strcat(result, str2);

[ ... ]
If we want we can do a speed-up

void fastconcat(char *out, char *str1, char *str2)
{
while(*str1)
*out++ = *str1++;
while(*str2)
*out++ = *str2++;
*out = 0;
}

Why do you believe that manually stepping through each character will
be faster when strcpy and strcat can take advantage of any CISC
instructions the hardware might offer?

The first method steps through the first string once (in
strcpy) to copy it, and then again (in strcat) to find
its end, before concatenating the second string onto it.

His method avoids stepping through the first string the
second time.

--
Later,
Jerry.

The universe is a figment of its own imagination.