Thread: AnsiString versus char *

Well, Prelude (among others which I thx) helped me with some code, and he pointed out for me that using String, AnsiString or others predefined clases was better then using an pointer to an array of chars on the heap, which you make larger as text side develops.
His explenation was that it wasn't that error prone, and that's were i got a ask, isn't it sometimes a good idea to make your own clases insted of using the predefined?

A few weeks ago i maid a program designed to go through an unkown amount of files with and unkown amount of txt in a submenu or disk, searching for 1 to an unkown number of strings.
I maid it work though there was all these unkowns, and then you got a work because the arrays have to expand as they are needed larger. First i maid it work with AnsiString, but since it should go through literaly thousands of files, all with atleast 2000 lines, it took a LONG time. Then i redesigned the code so that it worked with char, and suddenly it was MUCH faster (actually it was done in a matter of seconds). So my argument is that if it have to be really fast you should use char. Ofcouse only if the program have to compute through allot (else you wont notice the difference though it's still there).
Now tel me, am I just totally wrong on this one?

>isn't it sometimes a good idea to make your own clases insted of using the predefined?
Of course. The standard classes cannot solve all of your problems, but they should be the first thing you turn to for a solution because you don't have to worry about debugging them, you only have to concentrate on using them, which is far more productive.

If it turns out that you need a real speed gain and the standard classes don't cut it then you can write your own. Of course, the STL is written with speed in mind, so a lot of the time homegrown code with equivalent features would be hard pressed just to match the speed of the STL.

The best option is to solve the problem in the simplest way possible, then improve performance only if you really need to.

>His explenation was that it wasn't that error prone
If you're good enough to write solid code then this isn't a problem, but you waste time writing something that already exists.

-Prelude

Zahl,

>His explenation was that it wasn't that error prone

Actually, it was her explanation.

(You weren't the first. Trust me. )

-Skipper

>(You weren't the first. Trust me. )
Nor will you be the last.

-Prelude

>Nor will you be the last.
True, but why make the same mistake twice? I found it embarassing enough the first time.

-Skipper

I've been looking through those classes the compiler offers for handling an arrays of chars.

AnsiString I know is a Borland class, and string I know is a ANSI standard class. So what I think is that Borland probably have maid the AnsiString more advanced because it had to be compatible with all those advanced functions Borlands offers with it's visual and none visual classes. What I'm saying is that the String class is probably faster then the AnsiString class.
Just an observation that might be wrong (as usual ).
If that is, I'll go with String.

>isn't it sometimes a good idea to make your own clases insted of using the predefined?
Of course. The standard classes cannot solve all of your problems, but they should be the first thing you turn to for a solution because you don't have to worry about debugging them, you only have to concentrate on using them, which is far more productive.

Really? I thought that problem-solving was the fun part

If it turns out that you need a real speed gain and the standard classes don't cut it then you can write your own. Of course, the STL is written with speed in mind, so a lot of the time homegrown code with equivalent features would be hard pressed just to match the speed of the STL.

Code:

int main() {

char *winner = "neither";
time_t start, stop, finish, stl_finish, amount = 0;
int i;

start = clock();

do{
String a = "A rose is a rose is a rose is a rose is a rose is a rose is a rose is a rose is a rose is a rose is a rose is a rose is a rose is a rose...";
//a.FindAndReplace("rose", "tulip");
}while(i++ < 1000000);


stop = clock();

finish = (stop-start)/1000;

i = 0;

start = clock();

do{
string b = "A rose is a rose is a rose is a rose is a rose is a rose is a rose is a rose is a rose is a rose is a rose is a rose is a rose is a rose...";
//b.FindAndReplace("rose", "tulip");
}while(i++ < 1000000);


stop = clock();

stl_finish = (stop-start)/1000;


if(stl_finish > finish)
 winner = "Sebastian's",
 amount = stl_finish - finish;
else
if(stl_finish < finish)
winner = "the stl",
 amount = finish - stl_finish;

/* 
...on my machine, this prints: 
"The winner is Sebastian's library, by 3 whole seconds." 
*/
printf("The winner is %s library, by %i whole seconds.\n", winner, amount);
getch();
return 0;
}

That was just assignment. Had I been able to find the string::find_and_replace() function, the results might've been even more devastating!


String please = "The best option is to solve the problem in the simplest way possible, then improve performance only if you really need to."

please.FindAndReplace("only if you really need to.", "as soon as you can, especially if you're using the STL!!");

-Sebastian

Let's not forget the cost of development, or the potential for loss when a project isn't brought in on time.

I know of one instance that would leave you banging your head on your keyboard, in part, because a C/C++ programmer - a "hotshot", but not the only one responsible - couldn't seem to bring himself to understand business considerations over his own obsession with "faster and more efficient".

The end result? A major corporation is using second-rate software to handle its production/quality control, necessitating additional, i.e. expensive, measures to ensure the same level of production/QC that the original process would have afforded them for less cost.

Many variables involved, but the program code, or rather the lack of it, was the element that ultimately torpedoed the deal.

A sad situation...

-Skipper

You're missing my point.

1) The STL is bloatware.
2) I wrote my string class in less than two hours. How is that "wasting time being obsessed with faster and more efficient"? I don't obsess over such things. I just wanted to counter Prelude's remark that the STL was built for speed.
3) I read somewhere that the average programmer produces 16 lines of bug-free code per day. What a standard! I can write several hundred! But yes, at that rate (16 lines ), you would have production problems.

Whoa, Sebastiani! I'm not questioning your knowledge or skill here, nor that of a number of other highly competent programmers.

My point was that there are, sometimes, serious consequences to ignoring pre-written code in favor of satisfying one's individual desire to do it faster and better, particularly when the time-consumption in that endeavor is counter-productive to the required goal.

That's not a blanket condemnation of writing improved classes of code, which would be an utterly foolish thing to suggest. But, a programmer does need to keep his/her sights on what the job involves and whether, or not, expediency in getting code into production is a greater issue than saving a couple of seconds in run-time.

P.S. Sounds like my brother needed you on his team rather than who he had.

-Skipper

>1) The STL is bloatware.
I think it is very efficiently designed, it can be bloatware if you aren't careful when using it, but that is due to the programmer in question, not the library. If you think you can rewrite the STL in such a way that it is faster, not bloatware, and still as generic then everyone would be glad if you did. Improvement is always good if it can be managed.

>2) I wrote my string class in less than two hours.
Is it bug-free? Are you sure? Does it do everything that the STL string class does? Is is generic? I'm not criticizing you, but speed is not the only concern for a library, they are very difficult to get right.

>What a standard! I can write several hundred!
If you can write several hundred lines of bug-free code then you aren't finding all of the bugs. No offense, but claiming even 16 lines of bug-free code takes a lot of arrogance. You would be better off assuming you wrote buggy code and working to find things you've missed.

As for your example, I find it to be quite contrived and evasive. Perhaps you should instead give me an example of your version of one of the more difficult algorithms or containers in the STL, keep the current generality of the container and make it faster. This is what I meant by speed, not creating and destroying a single string one million times or using an inherently slow find and replace algorithm to prove that it's slow. Once you try it, you'll find that meeting the requirements for the STL while still maintaining the time complexities it requires is no small feat. Don't be so quick to judge something as inferior, however, you have your opinion and I respect that. I don't expect you to try and prove me wrong, we've both made our points so there's no point in taking this any further.

I'd like to note here that avoiding the tone of this post while still expressing my opinion was impossible, I appologize if you were offended, it wasn't intentional...for the most part.

-Prelude

Aw, Prelude, you know you could never offend me. You're more than just a code goddess to me

No offense, but claiming even 16 lines of bug-free code takes a lot of arrogance.

And we all know I have plenty of that!

Is it bug-free? Are you sure? Does it do everything that the STL string class does?

Save for a small handful of functions, yes, yes, and yes.

Concatenation, extraction, searching, replacing, comparison, etc...

Code:

int main() {

std::string stl = "rose";
char c = '!';
String s = "A rose is a";

s += stl;  //...generic, no?
s += c;
s += c;

cout << s <<endl;  //...cout knows a String, too...

s.FindAndReplace(stl, "lily"); //...more generics, no?

while(s -= '!')  //...god I love operator overloading...
/*   */;

return 0;
}

Perhaps you should instead give me an example of your version of one of the more difficult algorithms or containers in the STL, keep the current generality of the container and make it faster.

Sure, just give me an example of what sort of algorithm you are referring to. (I thought find and replace was a good start [by the way, would you mind supplying me with the code to do that using an std::string? ])