new without delete => bad ?

Reading what you're all saying makes sense. I feel stupid for thinking it was a good idea. I'm looking into those links ChaosEngine. The reason I wanted to delete the non-heap variable was to save me having to add in an extra assignment and conditional but I suppose that's just OTT efficiency. I can't help myself, despite not even knowing how to pull it off properly.

that was a typo I think ancient dragon, or a copio maybe. What I have now may not be much better:

Code:

void	CGI::accept_post()
{
	if( getenv("CONTENT_LENGTH") ){
		char *endptr;
		env_cl = (int)strtol(getenv("CONTENT_LENGTH"), &endptr, 10);
	}
	if( env_cl > 1 && env_cl <= MAX_BUF_SIZE ){	// leave in the '1'
		env_qs = new char[env_cl+1];		// FREE-STORE VARIABLE
		for( int i=0; i< env_cl && env_qs[i] != EOF; i++ ) {
			env_qs[i] = std::cin.get();
		}
		env_qs[env_cl] = 0x00;
		this->unencode( env_qs );
	}else{
		this->header();
		std::cout<< "Don't do that.";
	}
}

env_qs is a char * at class scope. ~CGI() deletes it.

Daved, you've almost convinced me to use strings, but I don't like either how the c-string functions don't work on them - I'm guessing calling c_str() and casting to a char * every time you need one is highly inefficient (guessing being the key word) - or how few people seem to use them. It makes me a bit wary. Shaky knees and all.

Originally Posted by drrngrvy

Reading what you're all saying makes sense. I feel stupid for thinking it was a good idea.

don't. we all gotta learn sometime.

Originally Posted by drrngrvy

I'm looking into those links ChaosEngine.

good, they'll save you much pain and suffering!

Originally Posted by drrngrvy

Daved, you've almost convinced me to use strings, but I don't like either how the c-string functions don't work on them - I'm guessing calling c_str() and casting to a char * every time you need one is highly inefficient (guessing being the key word) - or how few people seem to use them. It makes me a bit wary. Shaky knees and all.

first, if you do use strings (and you should) don't use the c-string functions with them (unless you really need a c-string for a 3rd party lib or something). Use the std::string methods, which replace the str* functionality
example

Code:

std::string s1 = "hello, world!";
std::string s2 = s1; // instead of strcpy
if (s1 == s2) doSomething(); // instead of strcmp
size_t len = s1.size() // instead of strlen

second, calling c_str() is pretty efficient. It's usually inline and optimised away.

and those "few people" that use them? they're known as "good C++ programmers"!!!

>> how few people seem to use them

I'm not sure what makes it seem as though few people use them. My company tends to be a bit behind the times but everybody here uses the string class or MFC's CString, and nearly every experienced C++ programmer I've seen on forums and newsgroups uses and recommends the string class. I think a lot of books, tutorials and teachers simply use outdated examples and designs, and there are tons of converted C programmers out there who haven't dived into C++ completely. But that doesn't mean there aren't tons of C++ programmers that use these tools every day.

Originally Posted by drrngrvy

or how few people seem to use them.

Those are mostly people in academic environment where they try to teach both C and C++ strings. It only takes a few minutes to learn std::string class, and after that you will probably rarely, if ever, revert to C strings. Same goes for arrays -- normally would use std::vector instead of C arrays because they are just sooo damned convient and prevent many common errors with c arrays.

Originally Posted by Ancient Dragon

Those are mostly people in academic environment where they try to teach both C and C++ strings. It only takes a few minutes to learn std::string class, and after that you will probably rarely, if ever, revert to C strings. Same goes for arrays -- normally would use std::vector instead of C arrays because they are just sooo damned convient and prevent many common errors with c arrays.

Totally on target about std::string Love them so much compared to old-style char arrays . Obviously there are things that are not perfect about std::string, but that applies to pretty much everything else as well

I'm not really sure why I got that impression from; I don't study Comp Sci or anything. Although I had noticed that books seem to always use std::strings, I thought that might have been just for simplicity, since the same books always use namespace std, which I gather is a bit silly.

I know this question isn't strictly on topic anymore, but I'm still a wee bit wary and I don't want to start off too deluded. From what I've seen - since I've looked into the string class functions now - I've realised how damn simple/intuitive strings are, but surely that implies that they aren't quite as efficient as c-style strings. Maybe they are for complex string manipulations, but surely generality has to imply some compromise?

example:

Code:

void cStyle( char *cptr )
{
std::cout<< "blah blah wombat" << cptr << std::endl;
}
// compared to
void stdStr( std::string str )
{
std::cout<< "blah blah wombat" << str << std::endl;
}

Ok, so I was going to ask if those two would be different, for the sake of arguement, but in the eyes of progress, I tried it myself. It turns out that the two are actually different and, on MSVC at least, the pass-by-string function was (suprisingly) faster. The difference was consistently about 3 seconds per 100,000 calls to the function.

Gah! I suppose I'll have to admit it soon...
!(std::string < char *);

The reason strings can be faster is that they employ advanced optimizations that you normal wouldn't take advantage of with your character arrays. However, in many instances the string class will be slower because of its genericity. The idea is to use the clearest, simplest tool unless you test your application and find that string processing is slowing it down.

BTW, if you have any concerns about performance you'd normally want to pass that std::string by (const) reference to avoid a copy. MSVC might have optimized away the copy or used reference counting, but you shouldn't count on it and it is a simple change.