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

C Style Strings

P: n/a
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
Jun 1 '06 #1
Share this Question
Share on Google+
89 Replies


P: n/a

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")

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


That's easy, do it the C way:

char* result=new char[strlen(s1)+strlen(s2)+1];
strcpy(result,s1);
strcat(result,s2);

Regards
Jiri Palecek

Jun 1 '06 #2

P: n/a
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")


a) Keep using std::string for your own stuff. The std::string class has
methods that allow you to interact with C-style string interfaces of
libraries.

b) Note that in your example above, pString1 is initialized to a const
string. Any attempt to modify that string would be undefined behavior. The
danger lies in not declaring pString1 as a char const *.

c) You could do:

#include <string>
#include <algorithm>

char * strdup ( std::string str ) {
char * result = new char [ str.length() +1 ];
std::copy( str.begin(), str.end(), result );
result[ str.length() ] = 0;
return ( result );
}

int main ( void ) {
char * pString1 = "Blah ";
char const * pString2 = "Blah Blah";
pString1 = strdup( std::string( pString1 ).append( pString2 ) );
}
However, I would prefer to use std::string for my own stuff:

#include <string>

int main ( void ) {
std::string pString1 = "Blah "; // rhs returned by some library
std::string pString2 = "Blah Blah"; // rhs returned by some library
pString1.append( pString2 );
}
Best

Kai-Uwe Bux
Jun 1 '06 #3

P: n/a
On Thu, 01 Jun 2006 08:35:36 +0100, scroopy <sc*****@nospam.com>
wrote:
I've always used std::string but I'm having to use a 3rd party library
that returns const char*s.
First you need to find out if you 'own' the returned string, i.e. if
you must free (maybe delete) the returned char*. Good C libraries
usually don't require the user to call free.
Given:

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

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


You can append a const char* to a std::string:

string myString = "Blah ";
const char* s = myLibFunc (...);
if (s) {
myString += s; // or myString.append(s);
}
// free (s); // if it's a bad lib

Best wishes,
Roland Pibinger
Jun 1 '06 #4

P: n/a
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,str1);
strcat(result, str2);
}
return result;
}

#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::string(pString1) + pString2;
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!

regards
Andy Little

Jun 1 '06 #5

P: n/a
Roland Pibinger wrote:
First you need to find out if you 'own' the returned string, i.e. if
you must free (maybe delete) the returned char*. Good C libraries
usually don't require the user to call free.


Out of interest ... What is a good C library resource management
strategy? ... for example (say) modifying the following example

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

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

int main()
{
char* str = concat(pString1,pString2);
if(str != NULL){
std::cout << str <<'\n';
free(str); // How to avoid this in C-style?
}
}

regards
Andy Little

Jun 1 '06 #6

P: n/a
"kwikius" <an**@servocomm.freeserve.co.uk> wrote:
scroopy wrote:
How do I append the contents of pString2 to pString? (giving "Blah
Blah Blah")
#include <malloc.h>
#include <cstring>


This is not C...
char* concat(const char * str1, const char* str2)
{
char * result = (char*) malloc(strlen( str1) + strlen (str2) + 1);


....and this is the wrong way to do this in C. And, really, also in C++:
use new.

So don't cross-post stuff like that. Follow-ups set.

Richard
Jun 1 '06 #7

P: n/a
Richard Bos said:
"kwikius" <an**@servocomm.freeserve.co.uk> wrote:
scroopy wrote:
> How do I append the contents of pString2 to pString? (giving "Blah
> Blah Blah")


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


This is not C...


....and it's not C++ either, so I'm not sure why you set followups to clc++.

The entire article, in fact (his, not yours), was a classic example of the
kind of thing you get in the Hackitt and Scarper school of programming.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 1 '06 #8

P: n/a
Richard Bos wrote:
"kwikius" <an**@servocomm.freeserve.co.uk> wrote:
scroopy wrote:
How do I append the contents of pString2 to pString? (giving "Blah
Blah Blah")
#include <malloc.h>
#include <cstring>


This is not C...
char* concat(const char * str1, const char* str2)
{
char * result = (char*) malloc(strlen( str1) + strlen (str2) + 1);


...and this is the wrong way to do this in C.


Out of interest what is the right way? BTW... It would seem to me to
make sense to cross-post this to comp.lang.c as it is somewhat O.T. for
C++. I think It makes sense in terms of a language comparison though,
don't you think?
And, really, also in C++:
hmmm... Touchy arent we? I showed a C++ way in my previous post.
use new.
Sure? .. The best way is not to allocate resources the users has to
manage , isnt it?.
So don't cross-post stuff like that. Follow-ups set.


Hmm... Are you sure I wouldnt get a better answer to the how to do it
in C question in a C newsgroup?

regards
Andy Little

Jun 1 '06 #9

P: n/a
Richard Heathfield wrote:
Richard Bos said:
"kwikius" wrote:
scroopy wrote:
> How do I append the contents of pString2 to pString? (giving "Blah
> Blah Blah")

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


This is not C...


...and it's not C++ either, so I'm not sure why you set followups to clc++.

The entire article, in fact (his, not yours), was a classic example of the
kind of thing you get in the Hackitt and Scarper school of programming.


Thats great! Thanks! Its always good to get positive feedback!

regards
Andy Little

Jun 1 '06 #10

P: n/a
On 1 Jun 2006 01:29:33 -0700, "kwikius"
<an**@servocomm.freeserve.co.uk> wrote:
Roland Pibinger wrote:
First you need to find out if you 'own' the returned string, i.e. if
you must free (maybe delete) the returned char*. Good C libraries
usually don't require the user to call free.


Out of interest ... What is a good C library resource management
strategy? ... for example (say) modifying the following example

char* concat(const char * str1, const char* str2)


This is almost the declaration of strcat, but strcat operates on the
given buffer and doesn't allocate anything. AFAIK, no Standard C
library functions returns anything to be freed.
Your example could be rewritten as:

char* concat (const char * str1, const char* str2, char* result,
size_t resultLen);

The function returns NULL when the 'contract' (string concatenation)
cannot be fulfilled, e.g. because the result-buffer is to small.
resultLen is for additional safety.

Best wishes,
Roland Pibinger
Jun 1 '06 #11

P: n/a
Roland Pibinger wrote:
On 1 Jun 2006 01:29:33 -0700, "kwikius"
<an**@servocomm.freeserve.co.uk> wrote:


[...]
Out of interest ... What is a good C library resource management
strategy? ... for example (say) modifying the following example

char* concat(const char * str1, const char* str2)


This is almost the declaration of strcat, but strcat operates on the
given buffer and doesn't allocate anything. AFAIK, no Standard C
library functions returns anything to be freed.
Your example could be rewritten as:

char* concat (const char * str1, const char* str2, char* result,
size_t resultLen);

The function returns NULL when the 'contract' (string concatenation)
cannot be fulfilled, e.g. because the result-buffer is to small.
resultLen is for additional safety.


Thanks for the answer. So the answer to the question of a library
resource management strategy in C is that there isnt one. Everything to
do with resource managment should be done manually by the user, whereas
in C++ it is usual to automate resource management thus dramatically
simplifying life for the user. That would seem to be a clear win for
C++ over C!

regards
Andy Little

Jun 1 '06 #12

P: n/a
kwikius wrote:
Richard Bos wrote:
"kwikius" <an**@servocomm.freeserve.co.uk> wrote:

scroopy wrote:

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

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


This is not C...

char* concat(const char * str1, const char* str2)
{
char * result = (char*) malloc(strlen( str1) + strlen (str2) + 1);


...and this is the wrong way to do this in C.

Out of interest what is the right way? BTW...


He was probably referring to the cast, which isn't used in C due to
implicit conversion from void*

--
Ian Collins.
Jun 1 '06 #13

P: n/a
On 1 Jun 2006 02:20:01 -0700, "kwikius"
<an**@servocomm.freeserve.co.uk> wrote:
So the answer to the question of a library
resource management strategy in C is that there isnt one.
Let the user provide the necessary resources. Actually, IMO, that's a
very good resource management strategy. In C and C++.
Everything to
do with resource managment should be done manually by the user, whereas
in C++ it is usual to automate resource management thus dramatically
simplifying life for the user. That would seem to be a clear win for
C++ over C!


Yes, the C++ advantage stems from RAII.

Best wishes,
Roland Pibinger
Jun 1 '06 #14

P: n/a
On 1 Jun 2006 01:57:05 -0700, "kwikius"
<an**@servocomm.freeserve.co.uk> wrote:
Richard Heathfield wrote:
The entire article, in fact (his, not yours), was a classic example of the
kind of thing you get in the Hackitt and Scarper school of programming.


Thats great! Thanks! Its always good to get positive feedback!


BTW, an interesting C-string library can be found here:
http://synesis.com.au/software/cstring/index.html

Best wishes,
Roland Pibinger
Jun 1 '06 #15

P: n/a

Ian Collins skrev:
kwikius wrote:
Richard Bos wrote:
"kwikius" <an**@servocomm.freeserve.co.uk> wrote:
scroopy wrote:

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

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

This is not C...
char* concat(const char * str1, const char* str2)
{
char * result = (char*) malloc(strlen( str1) + strlen (str2) + 1);

...and this is the wrong way to do this in C.

Out of interest what is the right way? BTW...


He was probably referring to the cast, which isn't used in C due to
implicit conversion from void*


To explicitise an implicit conversion does not stop it being C. It just
starts it being C++ as well.

/Peter

--
Ian Collins.


Jun 1 '06 #16

P: n/a
Roland Pibinger wrote:
On 1 Jun 2006 01:57:05 -0700, "kwikius"
<an**@servocomm.freeserve.co.uk> wrote:
Richard Heathfield wrote:
The entire article, in fact (his, not yours), was a classic example of the
kind of thing you get in the Hackitt and Scarper school of programming.


Thats great! Thanks! Its always good to get positive feedback!


BTW, an interesting C-string library can be found here:
http://synesis.com.au/software/cstring/index.html


It looks like a C++ style string written in C! The telling part is the
create and destroy functions, which would of course be replaced by
language facilities if written in C++.

regards
Andy Little

Jun 1 '06 #17

P: n/a
peter koch wrote:
Ian Collins skrev:

He was probably referring to the cast, which isn't used in C due to
implicit conversion from void*

To explicitise an implicit conversion does not stop it being C. It just
starts it being C++ as well.

No it doesn't, but try telling that to the folks down the hall, they get
very hot under the collar.

There is a valid reason for not doing explicit casts on function returns
in C, it masks missing headers (not an issue in C++).

--
Ian Collins.
Jun 1 '06 #18

P: n/a
kwikius wrote:
scroopy wrote:
I've always used std::string but I'm having to use a 3rd party library
that returns const char*s. Given:
I assume most of the code is C++ and that you have to handle C strings
as well.
I'm facing the same problem (plus a third party string class...). My
approach
was to get rid of the C strings as soon as possible. And only convert
back at
the last minute.
char* pString1 = "Blah ";
const char* pString2 = "Blah Blah";

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


std::string result = std::string(pString1) + pString2;

#include <malloc.h> not a valid header (in either language)
#include <cstdlib>

or better yet don't use malloc(). Mixing malloc() and new can be hairy.
#include <cstring>
when using C headers decide which sort to use. If you use this you need
to
namespace qualify your C calls.
char* concat(const char * str1, const char* str2)
{
char * result = (char*) malloc(strlen( str1) + strlen (str2) + 1);
std::malloc() or use new or use std::string
if( result != NULL){
strcpy(result,str1); std::strcpy() etc.
strcat(result, str2);
}
return result;
}


<snip>

--
Nick Keighley

Jun 1 '06 #19

P: n/a

kwikius wrote:
Roland Pibinger wrote:
On 1 Jun 2006 01:29:33 -0700, "kwikius"
<an**@servocomm.freeserve.co.uk> wrote:


[...]
Out of interest ... What is a good C library resource management
strategy? ... for example (say) modifying the following example

char* concat(const char * str1, const char* str2)


This is almost the declaration of strcat, but strcat operates on the
given buffer and doesn't allocate anything. AFAIK, no Standard C
library functions returns anything to be freed.
Your example could be rewritten as:

char* concat (const char * str1, const char* str2, char* result,
size_t resultLen);

The function returns NULL when the 'contract' (string concatenation)
cannot be fulfilled, e.g. because the result-buffer is to small.
resultLen is for additional safety.


Thanks for the answer. So the answer to the question of a library
resource management strategy in C is that there isnt one. Everything to
do with resource managment should be done manually by the user, whereas
in C++ it is usual to automate resource management thus dramatically
simplifying life for the user. That would seem to be a clear win for
C++ over C!

Even if it is popular in C. Many C libraries use another way:
GString is a good example of a clean C interface:
http://developer.gnome.org/doc/API/g...#G-STRING-FREE

Instead of having to call "free", the user must call a library-provided
resource deallocating function.

Using internally, functions which use with the any range of
user-provided memory (or iterators) is a good way to reuse efficiently
code.
However, in C, as in C++, it is good to encapsulate things and to
provide comfortable interfaces.

Jun 1 '06 #20

P: n/a

SuperKoko wrote:
Even if it is popular in C. Many C libraries use another way:
GString is a good example of a clean C interface:
http://developer.gnome.org/doc/API/g...#G-STRING-FREE

Instead of having to call "free", the user must call a library-provided
resource deallocating function.
That is necessary to prevent heap corruption if the library and the
client code use different heap managers.

If the client is written in C++ you can use boost::scoped_ptr (or
shared_ptr) with a custom deleter that calls the deallocating function
when appropriate. So you can add your own RAII.

I am not totally against libraries allocating resource that require to
be freed, but if they do so it should be obvious. For example, a
library will often provide a class factory. If I ever have my libraries
create anything in this way, the function name always begins with (or
is called) create.
Using internally, functions which use with the any range of
user-provided memory (or iterators) is a good way to reuse efficiently
code.
However, in C, as in C++, it is good to encapsulate things and to
provide comfortable interfaces.


However when a library is written in C it is often written for
relatively low-level programming. Often a function will require you to
provide a buffer and its length. It will never overwrite the buffer but
will often flag you if the buffer you provided was inadequate. And
sometimes you can request ahead (at little cost) how big your buffer
needs to be.

C also has that wonderful technique of sticking a variable-length
buffer at the end of a structure thus:

struct some_type
{
header_info header;
char data[1];
};

but you malloc sizeof( header_info ) + actual_data_size (or safer
sizeof( some_type ) + data_size - 1 );

and then later on you call a "free" on the whole thing. It means that
you only have one "malloc" for everything. Beware that such a struct
cannot be safely copied though! (well if you do it will be sliced).

Jun 1 '06 #21

P: n/a
scroopy posted:
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

Maybe something like this.

Unchecked code:
void DestroyString( const char* const p )
{
delete [] p;
}

#include <cstddef>
#include <cstring>
#include <cstdlib>

char * const Concantenate( const char *a, const char *b )
{
std::size_t const len_a = std::strlen(a);
std::size_t const len_b = std::strlen(b);

char *p = new char[ len_a + len_b + 1 ];

std::memcpy( p, a, len_a );

std::memcpy( p + len_a, b, len_b + 1 );

return p;
}

#include <iostream>

int main()
{
char * const p = Concantenate("Hello ", "World!");

std::cout << p << '\n';

DestroyString(p);

std::system("PAUSE");
}
-Tomás
Jun 1 '06 #22

P: n/a
kwikius 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>

This is neither a C header nor a C++ header, so off-topic in both groups
to which you posted.
#include <cstring>

This is not a C header, so off-topic in one of the groups to which you
posted.

If you _must_ post to both <news:comp.lang.c++> and <news:comp.lang.c>,
try to make your post topical in each. As it stands, your post is
topical in neither.

There is hardly ever any excuse for posting to both newsgroups; these
are concerned with two different languages, and advice given in posts to
both is almost certainly going to be wrong, or at least non-idiomatic,
in at least one of them.
Jun 1 '06 #23

P: n/a
Martin Ambuhl wrote:
kwikius wrote:
#include <malloc.h>

This is neither a C header nor a C++ header, so off-topic in both groups
to which you posted.


Ok.
#include <cstring>

This is not a C header, so off-topic in one of the groups to which you
posted.


Ok.
If you _must_ post to both <news:comp.lang.c++> and <news:comp.lang.c>,
try to make your post topical in each. As it stands, your post is
topical in neither.
The code in the post attempts to highlight the different problems of
dealing with resource management in both languages. Having to deal
manually with resources and having to check results of functions for
validity are both sources of additional code complexity in C it seems.
Maybe there are plans to address this situation in the next version of
the C standard?
There is hardly ever any excuse for posting to both newsgroups; these
are concerned with two different languages, and advice given in posts to
both is almost certainly going to be wrong, or at least non-idiomatic,
in at least one of them.


If I have given incorect advice, I apologise. FWIW I certainly dont
advocate use of malloc or C-style strings or manual memory management.
IOW I advocate use of C++ over C. C holds no advantage whatever. The
concat function shows very neatly why it is best to avoid C-style
strings in C++. In C it seems that it is possible to do better though
there seems to be no standard higher level string library. Maybe there
are plans to address this situation in the next version of the C
standard?

Whatever... Happy coding!

regards
Andy Little

Jun 1 '06 #24

P: n/a
kwikius wrote:
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::string(pString1) + pString2;
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!


yeah, it's always better when programs randomly drop
"terminate called after throwing an instance of 'std::bad_alloc'
what(): St9bad_alloc
Aborted"
messages on the screen and then stop working.

Jun 2 '06 #25

P: n/a
kwikius wrote:
Martin Ambuhl wrote:
kwikius wrote:
.... snip ...
The code in the post attempts to highlight the different problems of
dealing with resource management in both languages. Having to deal
manually with resources and having to check results of functions for
validity are both sources of additional code complexity in C it seems.
Maybe there are plans to address this situation in the next version of
the C standard?
I guess you want garbage collection and exceptions support. Both impose
run-time overhead. Increasingly, C is used in embedded programming
where both might be unfeasible and unnecessary. I don't think there is
much chance that they will be standardised.

Third-party garbage collectors are available for C. But if you really
want these features built into the langauge, maybe you should consider
Java?
If I have given incorect advice, I apologise. FWIW I certainly dont
advocate use of malloc or C-style strings or manual memory management.
Good for you.
IOW I advocate use of C++ over C. C holds no advantage whatever.
It depends on what you're trying to do. Sweeping generalisations aren't
correct.
The concat function shows very neatly why it is best to avoid C-style
strings in C++.
Indeed. If you decide to program in C++, then you should program in
C++.
In C it seems that it is possible to do better though
there seems to be no standard higher level string library.
Yes, anyone who wants an abstract string library has to either roll his
own or use pre-existing ones. The former case, especially, allows one
to optimise for their specific requirements, though I don't think the
code will be significantly better than std::string.
Maybe there are plans to address this situation in the next version of the C
standard?


I doubt it. Even the next revision of the standard is a minimum of 3-4
years away, and the standard committee have always resisted turning C
into another C++/Java wannabe.

Jun 2 '06 #26

P: n/a
kwikius <an**@servocomm.freeserve.co.uk> wrote:
In C it seems that it is possible to do better though
there seems to be no standard higher level string library. Maybe there
are plans to address this situation in the next version of the C
standard?


One very big difference between C and some other languages (say, Java
and C# and VB, for example) is that there is no big organization that's
got billions of dollars invested in making C the next Big Thing. As a
result, the language is not as large or complex, and far more stable,
than some of these other languages. I doubt you'll see future versions
of C making really huge changes in the language or APIs to conform with
higher-level programming goals. After all, if you wanted this you
wouldn't use C, and the standards organization doesn't particularly care
if you use C or not.

Short answer: probably not.

--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
Jun 2 '06 #27

P: n/a
santosh wrote:
kwikius wrote:
... snip ...
The code in the post attempts to highlight the different problems of
dealing with resource management in both languages. Having to deal
manually with resources and having to check results of functions for
validity are both sources of additional code complexity in C it seems.
Maybe there are plans to address this situation in the next version of
the C standard?
I guess you want garbage collection and exceptions support. Both impose
run-time overhead. Increasingly, C is used in embedded programming
where both might be unfeasible and unnecessary. I don't think there is
much chance that they will be standardised.


Yes. C++ claims to be as useable as C in embedded systems, but I have
heard that use of exceptions rather than error codes causes problems.
There is a marginal effect on performance but AFAIK the larger problems
are due to the latency involved in unwinding the stack as well as
apparently extra memory use for the exception handling code. I guess
that the different style of error handling also causes major problems
with integration. There is probably also an element of sticking with
the way things have always been done. AFAIK Most compilers can turn
off exceptions, though I think this is non-standard even in the
so-called free-standing c++ implementations.
Third-party garbage collectors are available for C. But if you really
want these features built into the langauge, maybe you should consider
Java?


I kind of like Java Swing.
If I have given incorect advice, I apologise. FWIW I certainly dont
advocate use of malloc or C-style strings or manual memory management.


Good for you.
IOW I advocate use of C++ over C. C holds no advantage whatever.


It depends on what you're trying to do. Sweeping generalisations aren't
correct.


Actually after posting I am pretty sure that the C code will be faster.
Creating a C++ string probably involves an allocation. The C++ string
concat operator(+) may also involve an allocation,whereas the C code
only has one allocation. That is the downside of automated resource
management.
The concat function shows very neatly why it is best to avoid C-style
strings in C++.


Indeed. If you decide to program in C++, then you should program in
C++.


Well I like other languages too. I like the platform independent spirit
of Java and its GUI support, but I guess I would miss C++.

regrads
Andy Little

Jun 2 '06 #28

P: n/a
kwikius wrote:
Martin Ambuhl wrote:
kwikius wrote:
#include <malloc.h> This is neither a C header nor a C++ header, so off-topic in both groups
to which you posted.


Ok.
#include <cstring>

This is not a C header, so off-topic in one of the groups to which you
posted.


Ok.
If you _must_ post to both <news:comp.lang.c++> and <news:comp.lang.c>,
try to make your post topical in each. As it stands, your post is
topical in neither.
These guys are real great at keeping the snow out of their cave, even
if they don't realize that its part of an avalanche on top of them.
The code in the post attempts to highlight the different problems of
dealing with resource management in both languages. Having to deal
manually with resources and having to check results of functions for
validity are both sources of additional code complexity in C it seems.
Maybe there are plans to address this situation in the next version of
the C standard?
The C standard is not something where people try to actually address
actual real world problems. You can look at their own manifesto --
they claim to "endorse standard practice" and things along those lines.
So in a sense they *endorse* all the problems with the C language, so
long as it is standard practice. Hence the continuing presence of
"gets" in the library.

C++ obviously goes a long way to addressing resources and error
handling in a useful way (RAII and real exception handling) however it
is not a garbage collecting language and thus it will always take a
little more effort to program in it properly. And of course C leaves
the whole concept of construction and destruction up to the programmer.
There is hardly ever any excuse for posting to both newsgroups; these
are concerned with two different languages, and advice given in posts to
both is almost certainly going to be wrong, or at least non-idiomatic,
in at least one of them.


If I have given incorect advice, I apologise. FWIW I certainly dont
advocate use of malloc or C-style strings or manual memory management.
IOW I advocate use of C++ over C. C holds no advantage whatever.


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.
[...] The
concat function shows very neatly why it is best to avoid C-style
strings in C++. In C it seems that it is possible to do better though
there seems to be no standard higher level string library. Maybe there
are plans to address this situation in the next version of the C
standard?


Take a look at http://bstring.sf.net/ . I claim that even just the C
API is generally better than C++'s std::string, or Microsoft's CString
classes. But it includes a C++ API as well which should make everyone
happy.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Jun 2 '06 #29

P: n/a

we******@gmail.com wrote:
C++ obviously goes a long way to addressing resources and error
handling in a useful way (RAII and real exception handling) however it
is not a garbage collecting language and thus it will always take a
little more effort to program in it properly.
RAII is not possible in a garbage collected language. Garbage
collection can, in many real world cases, add more complexity than it
is meant to solve.
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.

Jun 2 '06 #30

P: n/a
On 2006-06-02, Noah Roberts <ro**********@gmail.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.
Jun 2 '06 #31

P: n/a

Andrew Poelstra wrote:
On 2006-06-02, Noah Roberts <ro**********@gmail.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?

Jun 2 '06 #32

P: n/a
On 2006-06-02, Noah Roberts <ro**********@gmail.com> wrote:

Andrew Poelstra wrote:
On 2006-06-02, Noah Roberts <ro**********@gmail.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.
Jun 2 '06 #33

P: n/a
Andrew Poelstra <ap*******@localhost.localdomain> wrote:
On 2006-06-02, Noah Roberts <ro**********@gmail.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
Jun 2 '06 #34

P: n/a

Chris Smith wrote:
Andrew Poelstra <ap*******@localhost.localdomain> wrote:
On 2006-06-02, Noah Roberts <ro**********@gmail.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.

Jun 2 '06 #35

P: n/a
"kwikius" <an**@servocomm.freeserve.co.uk> 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,str1);
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::string(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
Jun 3 '06 #36

P: n/a
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(unsigned const v)
{
return ( ( (v & 0x7F7F7F7F) + 0x7F7F7F7F ) | v ) | 0x7F7F7F7F;
}

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

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

char *cdest = reinterpret_cast<char*>(idest);
char *csource = reinterpret_cast<char*>(isource);

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
Jun 3 '06 #37

P: n/a
Malcolm wrote:
"kwikius" <an**@servocomm.freeserve.co.uk> 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::string(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

Jun 3 '06 #38

P: n/a
On Thu, 1 Jun 2006 21:31:58 +0100, "Malcolm"
<re*******@btinternet.com> wrote:
"kwikius" <an**@servocomm.freeserve.co.uk> 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,str1);
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;
}

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
Jun 3 '06 #39

P: n/a
In article <5u********************************@4ax.com>,
sc******@doezl.net says...

[ ... ]
strcpy(result,str1);
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.
Jun 3 '06 #40

P: n/a
On Sat, 3 Jun 2006 10:15:50 -0600, Jerry Coffin <jc*****@taeus.com>
wrote:
In article <5u********************************@4ax.com>,
sc******@doezl.net says...

[ ... ]
>> strcpy(result,str1);
>> 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.


True, but some machines, like IBM mainframe I work on, have
specialized string instructions and can perform the "strcpy" and the
first part of the "strcat" faster than manually stepping through each
char can do just the "strcpy".
Remove del for email
Jun 3 '06 #41

P: n/a
> 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?


It is interesting to note, that you can implement + style string
concenation with c++ strings and templates _very_ efficiently.

Here's the input:

foo::string x = a + b + c;

For simplicity, I omit the foo namespace from this point forward. We
need to state what *we* think is the optimal result (well optimal is
that nothing is done but let's say, with minimum number of operations
which still achieve something, let's not consider lazy evaluation and
similiar for this exercise).

What would be, in my humble opinion, efficient would be in pseudo code:

allocate a.length() + b.length() + c.length() bytes of memory in x, and
copy the a, b and c into the x.

This is possible using the proposed syntax. We need to implement a
string expression class, which encapsulates the expresion which is
being assigned into a string object, in this case x.

a + b is when we look at the types: string + string, result type is
string. Here comes the twist, we implement operator + which instead
returns a new type, which only encapsulates the parameters of the +
operation.

The new type, let's call it, "expr" so the above becomes:

expr operator + (string,string)

The next + operator with rhv of c will be of form:

expr operator + (expr,string)

And last, the assignment to x will be of form:

expr operator = (expr)

(references et cetera omitted for clarity)

When we implement this with templates, the expr object will be a type,
encapsulating a lot of information about the expression on the right
side of the assignment.

At this stage, we can compute a sum of the type tree on the right
(using the length of the string objects), this works so that the expr
object sums both left and right arguments lengths - recursively.
Because this "recursion" is done at code generation time, the recursion
is flattened (we are assuming the c++ implementation isn't braindead,
it could be but that is another matter, then there are bigger things to
worry, I think).

Next thing the operator = does is, that it just concatenates the text
as it best sees fit. Whatever is "optimal", efficient whatever. It's
actually pretty trivial to write, too. :)

Jun 3 '06 #42

P: n/a
"Barry Schwarz" <sc******@doezl.net> wrote
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?

Ultimately you do have to go to assembly to squeeze every last bit of
efficiency out of the code.
You shouldn't assume that library functions are always optimally written -
memcpy is often a simple byte copying loop.
If there is a copy asciiz assembly instruction then it will be faster to
call it. The code gets rid of memory management overhead, and performs only
one scan of the string. It cannot be speeded up algorithmically, only by
micro-optimisation.
--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $7.20 paper, available www.lulu.com/bgy1mm
Jun 3 '06 #43

P: n/a

Chris Smith wrote:
Andrew Poelstra <ap*******@localhost.localdomain> wrote:
On 2006-06-02, Noah Roberts <ro**********@gmail.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.


Indeed, I have again made the mistake of calling C++ what I mean to
call C++ but not using the C subset/paradigms. Of course you can do
this in C++ because you can just do it using the C-like subset (where
the resulting data types are still considered "objects".) My point was
just that C++ does not have a blanket advantage over C, since falling
back to ordinary C may still be the best way to do things.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Jun 3 '06 #44

P: n/a
On Thu, 1 Jun 2006 21:31:58 +0100, I waved a wand and this message
magically appeared from Malcolm:
void fastconcat(char *out, char *str1, char *str2)
{
while(*str1)
*out++ = *str1++;
while(*str2)
*out++ = *str2++;
*out = 0;
}


If you want this even faster, and the architecture can support it, copy
the largest size per loop, i.e. 32 bits at a time. Or even 64 bits.
--
http://www.munted.org.uk

Take a nap, it saves lives.
Jun 3 '06 #45

P: n/a
persenaama wrote:
It is interesting to note, that you can implement + style string
concenation with c++ strings and templates _very_ efficiently.

Here's the input:

foo::string x = a + b + c;


Please stop this crap. There seems to be a concerted effort by assholes
from <news:comp.lang.c++> to crosspost their obscurities to
<news.comp.lang.c>, and in more than one thread. You have been told,
more than once and by more than one poster, that this shit does not
belong in clc, yet you keep it up. The only possible excuses for this
are (a) you are inexcusably stupid or (b) you are inexcusably trying to
start flame wars. Neither is acceptable. Please go away.
Jun 3 '06 #46

P: n/a

we******@gmail.com wrote:
Indeed, I have again made the mistake of calling C++ what I mean to
call C++ but not using the C subset/paradigms. Of course you can do
this in C++ because you can just do it using the C-like subset (where
the resulting data types are still considered "objects".) My point was
just that C++ does not have a blanket advantage over C, since falling
back to ordinary C may still be the best way to do things.


typedef ? XType;

int main()
{
X stackX;
}
No matter what ? is above stackX is an automatic variable allocated on
the stack.

I still don't know where you're getting these wield ideas of yours.

Jun 3 '06 #47

P: n/a
Noah Roberts wrote:
we******@gmail.com wrote:
Indeed, I have again made the mistake of calling C++ what I mean to
call C++ but not using the C subset/paradigms. Of course you can do
this in C++ because you can just do it using the C-like subset (where
the resulting data types are still considered "objects".) My point was
just that C++ does not have a blanket advantage over C, since falling
back to ordinary C may still be the best way to do things.


typedef ? XType;

int main()
{
X stackX;
}
No matter what ? is above stackX is an automatic variable allocated on
the stack.

I still don't know where you're getting these wield ideas of yours.


/* In C: */

int catHi (bstring b) {
static struct tagbstring hi = bsStatic ("hi"); /* init-time */
bconcat (b, &hi); /* Essentially an addition and a memcpy */
}

// in C++:

void catHi (CBString &b) {
b += "hi"; // Requires implicit construction of CBString("hi") or
some
// sort of strlen() being called on "hi" before
appending.
}

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Jun 3 '06 #48

P: n/a
On 2006-06-03, Noah Roberts <ro**********@gmail.com> wrote:

we******@gmail.com wrote:
Indeed, I have again made the mistake of calling C++ what I mean to
call C++ but not using the C subset/paradigms. Of course you can do
this in C++ because you can just do it using the C-like subset (where
the resulting data types are still considered "objects".) My point was
just that C++ does not have a blanket advantage over C, since falling
back to ordinary C may still be the best way to do things.


typedef ? XType;

int main()
{
X stackX;
}
No matter what ? is above stackX is an automatic variable allocated on
the stack.


That isn't true; the C standard has no concept of a stack and I don't
see any stack libraries included in this code. Not everyone has a Wintel,
you know.

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
If we would just let the poachers into the zoo, we'd
have less squashed people and more fancy pianos!
Jun 3 '06 #49

P: n/a
Malcolm wrote:
"Barry Schwarz" <sc******@doezl.net> wrote
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?


Ultimately you do have to go to assembly to squeeze every last bit of
efficiency out of the code.
You shouldn't assume that library functions are always optimally written -
memcpy is often a simple byte copying loop.


Profile, don't speculate. Many CPUs have block copy/move instructions
that the library might use.

Profile, don't speculate.

--
Ian Collins.
Jun 3 '06 #50

89 Replies

This discussion thread is closed

Replies have been disabled for this discussion.