Thread: AnsiString versus char *

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

...

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

Weird,

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

Just hangs the program...

Damn that STL
(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

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

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;


}

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.

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

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


It was well aimed

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


It was well aimed

Nah...not really.....LOL

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

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