Quote:Original post by ToohrVyk
Besides, it's quite trivial to generate a string literal wrapper class to handle literals without creating temporaries, having pointer problems, or having ownership problems, and simply change "const literal &" to "const std::string &" when you need to work on something other than a literal.

class literal{  const char *value;  literal(const literal &);public:  literal(const char *value) : value(value) { assert (value); }  operator const char*() const { return this -> value; }  operator std::string() const { return this -> value; }};void frobnicate(const literal & work){  std::ifstream input(work); // 'work' is always a valid string.}void test(const std::string &str){  frobnicate("Hello");     // No temporary value required.  frobnicate(str.c_str()); // Lifetime of the literal is shorter than                           // lifetime of str, and it is noncopyable}

Quote:Original post by Spoonbender

Quote:Original post by exwonderEven if you solve the fragment, creating extra temporaries has the potential to bloat your code, so take a couple seconds to think about how your class interface can be designed to avoid it and you'll find yourself using const char*.

Or, you know, pass strings by reference. That way the problem with temporaries just... goes away. But of course, that'd be too easy, when we might otherwise have an excuse to shoot ourselves in the foot with lots and lots of pointers.

class NeedsToStoreAString{ std::string blah;public: //NeedsToStoreAString (std::string s) : blah(s) { } // passing by value is stupid! NeedsToStoreAString (const std::string& s) : blah (s) { } // leaps and bounds better if you're actually passing in std::strings. NeedsToStoreAString (const char* s) : blah(s) { } // lets you use literals without any problems.};

NeedsToStoreAString one ("one"); // no temporary created.NeedsToStoreAString two (std::string("two")); // this is what would happen without the extra constructorstd::string three ("three");NeedsToStoreAString (three); // works fine

Quote:Original post by ToohrVyk

Quote:Original post by exwonder
I'm on the border between calling this really good advice and not understanding the point. Would you please summarize for me the benefit of using the literal class over const char*? The usage seems the same to me...

There are several points:

Quote:Original post by exwonder
Making constructors that only take std::string is very very stupid if you ever pass in string literals. For every constructor or assignment function you make that takes std::string, make an identical one that takes const char*. You'll avoid a ton of useless temporaries and fragmentation this way

Quote:and it doesn't violate the "zomg const char* is so much harder to use than std::string" vibe that permeates these forums.

Quote:
I may sound bitter, but it's only because I've seen systems that were horribly bloated because of a stupid design choice to use a string class over const char*.

Quote:With hashes you can do fast comparisons and lookups that just aren't possible with strings.

Quote:in my home project I do this:

#define ConstID(a,b) a#ifdef NDEBUGinline hashID MakeID (hashID id, const char* pString) { return id; }#elseextern hashID MakeID (hashID id, const char* pString);#endif

In debug builds, MakeID will double check that the string and ID match.

Quote:Original post by Zahlman
I would be willing to bet that what you actually saw were systems that were horribly bloated because of stupid implementation choices to do far more string manipulation work than was actually necessary to solve the problem.

Quote:You're willing to risk hash collisions in release mode?!?

Quote:Original post by ToohrVyk
There are several points:

• It's a specific name used to represent a constant string represented as a C NUL-terminated character buffer, which always comes in handy when you need to look for all occurrences of that concept. Of course, this could also have been a typedef.
  
  
• Unlike const char*, it cannot be null. You don't want to have to assert your string literals whenever you use them, so the constructor takes care of that.
  
  
• It has no copy constructor, meaning that it will not allow storage of the literal beyond the lifetime which was granted to that literal by its creator. This comes in handy when you have code of the form:*** Source Snippet Removed ***
  
  Then, const char* becomes a notification of "I need ownership" (which you may represent with another type that asserts in its constructor, for further ease of use) and as such (non-third-party) functions of the form foo(const char*) will only safely be called when the argument is a true character literal.
  

class Literal {public:	Literal( const char* value ) : value(value) {}	operator const char*() const { return this -> value; }	operator std::string() const { return this -> value; }private:	Literal( const Literal& literal );	const char* value;};struct Data {	const char* data;};Data data;void assumes_string_literal( const Literal& literal ){	// store 'c' in a data structure somewhere.	data.data = literal;}void makes_no_assumptions( const Literal& literal ){	// Indirectly and opaquely calls 'assumes_string_literal(c)'	// The assumptions made there fail to "climb" back up the	// call tree and appear in this function's 	// signature.	assumes_string_literal( literal );}void mistaken(std::string s){	// This call 'feels safe' because the called function 	// does not explicitly assume anything about the lifetime	// of the pointer.	makes_no_assumptions(s.c_str());	// Here, the string dies and the value stored by	// 'assumes_string_literal' becomes invalid. Program	// dies a flashy death.}int main () {	using namespace std;	string str( "SomeString" );	mistaken( str );        // prints corrupted data	cout << data.data;	return 0;}