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? :confused:

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

Quote:

---

>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 :p).
If that is, I'll go with String.

Quote:

---

>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 :confused:

Quote:

---

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

'Zahl', how did you get past the 'Code Goddess' title that Prelude has and still think she was a bloke?

Before delving into the subject at hand I play it safe and never indicate the gender of a person that I don't know. Prelude--aside from the "Code Goddess" thing--has been a member of the boards at least as long as I have. But at least she and the other ladies can bare with the common mistake.

Anyways, the more pressing issue here is your initial question. It has been my experience that almost every time the standard C library, standard C++ classes, and the standard template library are almost always better than what you can come up with. Although a home-made class could be faster due to being slimmed down in size and functionality classes are usually not the best way to produce speed. I have found that for speed C functions work best. But there are always trade-offs. For instance, if you add a bunch of C functions into a prodominately C++ project you could find yourself getting lost in your own code. As always the main trade-off that is between readability and speed.

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

-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 :D

Quote:

---

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!

Quote:

---

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;
}

---

Quote:

---

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 :confused: [by the way, would you mind supplying me with the code to do that using an std::string? :rolleyes: ])

Provide us the String class details and in your first example try actually using the STL if you are going to compete against it.

For example, there is no FindAndReplace method of std::string. You might want to use insert() or replace(), or erase(). Here are the find operations:

find() Finds the first occurance of a value
rfind() Finds the last occurance of a value
find_first_of()
find_last_of()
find_first_not_of()
find_last_not_of()

So I'm saying, that if you are going to compete with the STL than use a real example.

Perhaps you could show me the equivalent std::string find_and_replace() implementation ?

As far as I can see there is not find_and_replace method. A std::string does support indexing with size_type indexes or iterators. If you want me to use what the std::string library has because you don't want to provide you String class details, than I can probably look it up and come up with something, but I'm leaving for work in 45 minutes and I'm currently busy reading about compiling multiple sources with gcc. I can probably come up with an algorithm tomorrow. In saying that, maybe one of the C++ algorithms support find and replace with a std::string argument. The C++ algorithms are not std::string methods however. I don't know, it's a big library.

Quote:

---

As far as I can see there is not find_and_replace method...

---

...:D

Code:

---




class String {

 protected:

char * memory;  //...I choose not to be const :)
int _length;
void Set(int this_length);

 public:


friend ostream& operator << ( ostream& out, String& This);
friend istream& operator >> ( istream& in, String& This );


char * c_str();
int length();

char * Data();
int Length();

char& operator [] (int index);
char * operator () (void);

String();
String(const char *str);
String(const char ch);
String(String& str);
String(const string& str);
~String();

void Resize(int new_length);
void ResizeIf(int this_length_longer);

/* the below are addidtionally defined for each of the following:
std::string, char, and String...*/

void Copy( const char *str );
void Add( const char *str );
char * Find( const char * str);
int FindPosition( const char * str );
char * FindNext( const char * str, char * next );
int FindNextPosition( const char * str, char * next );
char * Remove(const char * str );
void FindAndReplace(const char * instance, const char * replace_with);
char * operator -= (const char * str );
void operator += (const char * str);
void operator = (const char * str);
bool operator == (const char * str);
bool operator < (const char * str);
bool operator << (const char * str);
bool operator > (const char * str);
bool operator <= (const char * str);
bool operator >= (const char * str);
bool operator != (const char * str);
};

---

God knows if there is an algorithm to do it. The closest I care to come up with is the replace() algorithm, but it only deals with characters. I don't know the stl well enough so I'll leave it at that.

Code:

---

#include<iostream>
#include<string>
#include<algorithm>

using std::cout;
using std::endl;
using std::string;
using std::replace;

int main()
{
  string text = ("A rose is a rose is a rose is a rose");
  cout << "Before: " << text << endl;
  replace(text.begin(), text.end(),'r', 't');
  cout << "After: " << text << endl;
  return 0;
}

---

Weird,

replace(text.begin(), text.end(),'r', 't');

Just hangs the program...

Damn that STL
:p (O.K., damn my ignorance...)

...will update...

The first big difference between yours and the stl's string is that the latter is implemented as a template......therefore its not contained to type - char....

This means I can use different types of strings for different situations.......the first that comes to mind is UNICODE

Code:

---

#define UNICODE
#define _UNICODE
#include <iostream>
#include <string>
#include <windows.h>
#include <tchar.h>

namespace tstring{
#ifndef UNICODE
        typedef std::basic_string<char> string;

#else
        typedef std::basic_string<WCHAR> string;
#endif
}

int _tmain(){

        tstring::string str = _T("Hello World");

        MessageBox(NULL,str.c_str(),NULL,MB_OK);

        return 0;
}

---

Oh, I know. My sole point was that I dislike it :D

But yes, the STL is VERY generic, and it deserves credit for that...

template <class elemType>
class Mystring
{
...
};

You could make your class generic and also create a hierarchy for specialized versions of your string class. I don't know if a string class is a great idea because the stl already provides one, but than again you might want some specialized functionality that the stl does not provide. I think that the stl is good, however i'm not used to working with it. Yet at the same time, I would like to know about the additions in the new 2003 standard C++ and be able to work with them right away in gcc. Very cool.

Oh...and find & replace......

I did this for someone a few days ago

Code:

---

#include <iostream>
#include <string>


int main(){

using std::cout;
using std::endl;
using std::string;

        string one("Hello World This Is Encoded");//string to encode
        const string rep("%2B");//replacement token 
        string::size_type indxD = 0;//return of find...

        cout << "Unencoded " << one << endl;

        while(1){
                indxD = one.find_first_of (' ',0);//find a char....
                if(indxD == string::npos)break;//if -1 then end (not found!)
                else one.replace(indxD,1,rep.c_str(),rep.length());//replace with token
        }

        cout << "Encoded " << one << endl;


}

---

I didn't think that there was a one line solution, at least not with std::string.

Quote:

---

Originally posted by Fordy
The first big difference between yours and the stl's string is that the latter is implemented as a template......therefore its not contained to type - char....

---

templates don't make a class slower though. They only increase compilation time.

And I guess the speed all depends on which compiler and STL you are using. My std::string implementation is fast and is reference counting, which saves a lot of time and memory.

Quote:

---

Originally posted by Sang-drax
templates don't make a class slower though. They only increase compilation time.

And I guess the speed all depends on which compiler and STL you are using. My std::string implementation is fast and is reference counting, which saves a lot of time and memory.

---

I know, I agree and I wasnt commending him for it....that's why I went on to show how a template implementation of a string can work in other situations other than ANSI...

As I see it, I have a very fast, extensible, reliable, debugged, well documented implentation in the stl, so I can see no reason to build another string class.....and as for people trying to squeeze some insignificant bytes out of their exe.....well....enjoy :).......as I see it, if your that concerened; go do it in ASM!!!! ;)

Quote:

---

.....and as for people trying to squeeze some insignificant bytes out of their exe.....well....enjoy .......as I see it, if your that concerened; go do it in ASM!!!!

---

I'll take it that smartass remark was aimed at me, Fordy?


:D :D It was well aimed :D :D

Quote:

---

Originally posted by Sebastiani
I'll take it that smartass remark was aimed at me, Fordy?


:D :D It was well aimed :D :D

---

Nah...not really.....LOL :D

Its just that I dont see the point in disregarding something like the STL in C++ for any code size increases.......

C++ is there to make the coding experience better, quicker and less error prone....when you start stripping it away, and start concerning yourself with slight size increases and "cin is slower than scanf" then IMO its time to look at an alternative way of coding......sometimes the speed is nessasary (games etc...)....but for many things it isnt (How quick does text input need to be if the person using the app types with 1 finger!!??)

I was reading an article recently where someone was using assembler to create the smallest PE exe file they could for a certain task......they removed the need for .DATA and .DATA? sections by basically having no variables apart from the stack and what they could jiggle around in the registers...all consts were in the code section and the code jumped over them......then they were looking at the switches for the linker to squeeze the section size down....then they were looking at ways of only loading the import libs that were absolutely nessasary....Interesting, but not a nice way to code :D

Then I look at C++ and think, hell the size and efficiency of that isnt so worrying......hell its not as if we are using VB here is it :)

My concern isn't so much with speed. I have always disliked the stl and while some of it is from heresay (memory leaks, bloat, inefficiency, unecessary complication, etc...), mostly it has to do with my stubborness, and desire to write my own code. Hell, if I had it my way, I'd be using a class I developed to generate pure bytecode (...all in good time...):D

>And we all know I have plenty of that!
Indeed, but from what I've seen it's mostly well placed. ;)

>Save for a small handful of functions, yes, yes, and yes.
Talking about a string class, a small handful of functions could very easily be the entire implementation. I would very much like to see the source for your class including all of the details if you're willing to share. My email is always open.

>Sure, just give me an example of what sort of algorithm you are referring to.
I wasn't referring to the string class specifically, but merge would be a good start. :)

>[by the way, would you mind supplying me with the code to do that using an std::string? :rolleyes: ]
I'd be glad to:

Code:

---

void find_and_replace ( std::string& s, std::string& to_find, char *rep )
{
  std::string::size_type pos;
  std::string::size_type len = to_find.length();

  while ( ( pos = s.find ( to_find ) ) != std::string::npos )
    s.replace ( pos, len, rep );
}

---

The reason there isn't a find and replace member function for the string class is because it is so easy to write using existing member functions. I think std::string is poorly designed and is a bad example of the STL, but it serves its purpose quite nicely. ;)

>I have always disliked the stl and while some of it is from heresay (memory leaks, bloat, inefficiency, unecessary complication, etc...)
All of which are solely based on the fact that the STL implementations are still in their infancy. If this were the best it got then my opinion would be the same as yours.

>mostly it has to do with my stubborness, and desire to write my own code
I love getting my hands dirty in the low level areas too, but to not make use of higher level tools when the situation warrants it is foolish.

-Prelude

Does the '16 lines of code a day' fact not also include design, testing and distribution time.

Statistics are dodgy.

Brif

Quote:

---

Originally posted by brif

Statistics are dodgy.

Brif

---

Quote:

---

88.2 percent of all statistics are made up on the spot - Vic Reeves

---

:)

Quote:

---

Originally posted by Prelude
>

Code:

---

void find_and_replace ( std::string& s, std::string& to_find, char *rep )
{
  std::string::size_type pos;
  std::string::size_type len = to_find.length();

  while ( ( pos = s.find ( to_find ) ) != std::string::npos )
    s.replace ( pos, len, rep );
}

---

-Prelude

---

This is nice clean code. I like it. The STL is worth using if you take the time to research the STL types and their methods, as well as the global algorithms of the STL. There is nothing worse than non intuitive code in my opinion.

And after saying that, I believe that it is still possible to make a mess using the STL, so you have to be careful.