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

[kwikius]

persenaama wrote:

[snip Expression Templates ]

Sounds cool. I hadnt thought of using expression templates for this
task but it fits rather well. I am not sure the implementation would be
totally trivial, but certainly worth investigating.
Note that there is one downside IIRC, that you either need an
assignment or a conversion to prompt the evaluation, which can be
inconvenient in use. There is also the issue of tracking the data which
may causes problems, or maybe not.

Overall though... cool idea!

regards
Andy Little

[Noah Roberts]

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

/* 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.
}

The only difference between the two code slices is syntax; they mean
the same thing. Of course, to be truely certain of that we would have
to know what bsStatic() does, what bconcat does, what CBString(const
char*) does and what CBString::opera tor += does. What I think they all
mean just looking at the above would result in exactly the same
operations. Of course there is nothing requiring that CBString be
implemented so that += does not accept a const char* directly.

Even at that.... your code example does not prove your point at all.
It does not illustrate any difference between C and C++ with regard to
stack variables.

[Malcolm]

"Ian Collins" <ia******@hotma il.com> wrote

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.

That's wonderful advice, as long as your code is always running on the same
platform. My programs have to run on anything with reasonable efficiency.

--
Buy my book 12 Common Atheist Arguments (refuted)
$1.25 download or $7.20 paper, available www.lulu.com/bgy1mm

[Ian Collins]

Malcolm wrote:

"Ian Collins" <ia******@hotma il.com> wrote

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.

That's wonderful advice, as long as your code is always running on the same
platform. My programs have to run on anything with reasonable efficiency.

Then you can't use assembly and have to code to the lowest common
denominator.

When I've faced this problem, I included optimisations for known targets
or types (32/16/8 bit) of target and a fall back byte copying loop.

The specific optimisations did result from thorough profiling on those
targets.

--
Ian Collins.

[Phlip]

Ian Collins wrote:

Malcolm wrote:

Profile, don't speculate.

That's wonderful advice, as long as your code is always running on the
same
platform. My programs have to run on anything with reasonable efficiency.

Then you can't use assembly and have to code to the lowest common
denominator.

Profiling isn't just about determining which low-level bits to split.

Profiling is also about detecting where to use brute-force, and where to
work hard to install a good high-level algorithm.

For most of your code, brute-force will not cause a bottleneck under high
load.

This is why "premature optimization is the root of all evil". Brute-force is
most likely the easiest code to read, unit test, and maintain. The
high-level algorithms cost more in programming time, so only put them in
when profiling reveals they will have a benefit.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Ian Collins]

Phlip wrote:

Ian Collins wrote:

Malcolm wrote:

Profile, don't speculate.
That's wonderful advice, as long as your code is always running on the
same
platform. My programs have to run on anything with reasonable efficiency.

Then you can't use assembly and have to code to the lowest common
denominator .

Profiling isn't just about determining which low-level bits to split.

Who said it was?

--
Ian Collins.

[Phlip]

Ian Collins wrote:

Profiling isn't just about determining which low-level bits to split.

Who said it was?

Take a cleansing breath, Ian. Sometimes when a post contains a quote, the
next line doesn't contradict but reinforces it. I'm aware this is the
exception with USENET, but it happens.

In this case, the mark you replied to took the position "optimizati on is
about opcodes, so profiling won't work for portability".

Optimize opcodes only as a last resort. You knew that too, but forgot to
bring the point up.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Ian Collins]

Phlip wrote:

Ian Collins wrote:

Profiling isn't just about determining which low-level bits to split.

Who said it was?

Take a cleansing breath, Ian. Sometimes when a post contains a quote, the
next line doesn't contradict but reinforces it. I'm aware this is the
exception with USENET, but it happens.

In this case, the mark you replied to took the position "optimizati on is
about opcodes, so profiling won't work for portability".

Optimize opcodes only as a last resort. You knew that too, but forgot to
bring the point up.

Ah :)

--
Ian Collins.

[persenaama]

> 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.

You are wrong, is it possible? Yes. Bye. *plonk*

[persenaama]

> 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.

Problem with that is that both source and destination have to be
aligned (for correctness, performance or both depending on the
architechture). Strings are commonly short so the overhead of detecting
this situation might degrade the performance on average use case.