Davion: I'm not trying to set their description for them, I'm just displaying for them a generic description that tells them what appearance options the code generated for them. And give them the opportunity to accept them and play and go hack and slashing, or they can customize for an increased RP benefit. A bit later on, I'll be adding in support for players to visit a barber and be able to change their hair color, length, style, add highlights, and change their facial hair where applicable.

Justice:Thanks for the clarification. :)

That's fine. Set the description, if they accept, don't do anything, if they don't accept, simply discard their description and start new. It eliminates the worry of static buffers and decreases the risk of memory leakage ;)

Well, then I might just have to take that route, I'd like to avoid the use of static anything if I can for right now, if only for lack of understanding, I really should do a little digging and get better at the use of C/C++ strings.

If you want to avoid using a static buffer, you can always write a version of the function that takes the buffer (and for safety, it's size) as parameters.

This is actually just basic memory management and pointers that happen to be using strings.

Jutice: I might look into that at a later time, but for now, I think Davion's idea will work. I'm just tired of working on character creation. And as soon as I get it all working without a hitch, I'll not come back to it for a while. :P

Davion: Yeah, but this thread came about because I don't know enough about strings in either of them :P

It's also a mistake to think of C "strings" and C++ std::strings as being the same. They're very different: the former is just a pointer to a block of memory, the second is an object that manages its own memory and so forth.

String handling in C is probably one of the biggest gripes I have with the language… it's probably the single most frequent cause of error for new programmers. That and not understanding pointers, which is sort of the same thing, actually.

Well, that's blatantly false. A C string is a null terminated char array. A pointer is a reference to a location of memory. It just so happens that most strings are referenced as a pointer, but most pointers are not strings. In short, they're entirely different concepts.

Umm. Ok… An array reference is a pointer to the first element of the array, is it not? You manipulate strings by pointers to the first block of the array, do you not?

We saw here a case where string handling was misunderstood because it was not clear that strings were actually pointers to a block of memory that is shared. I'm not sure why these are all so different. If you don't understand pointers at a basic level, you will have trouble with strings.

I wouldn't say that C-strings and pointers are entirely different concepts, for the above reasons. Yes, clearly, a pointer is a super-concept of strings, but my argument was that if you can't understand the sub-concept, you will be hopeless for the super-concept. And if you understand the super-concept, you will understand the sub-concept.

It seems to me that you chose the interpretation of my words that made them the most stupid possible. :wink:

Obviously, I'm a perfect example of Justice's case, as I understand pointers perfectly fine, but I don't understand strings, because aside from the occasional use of functions that send a string to a player, I don't typically work with strings, and I've certainly never actively pursued the concept of managing something I don't use. But I use pointers all the time. But, to further clarify this static stuff.

In the following chunk, will the capitalize() function produce the same result as my use of strlower?

send_to_desc_color( "\r\n&wYou may choose from the following skin tones:&D\r\n", d );
	buf[0] = '\0';
	for( iSkin = 0; iSkin < MAX_SKTONE; iSkin++ )
	{
		if( get_skin_tone( ch, iSkin ) && get_skin_tone( ch, iSkin )[0] != '\0' )
		{
         	    if( iSkin > 0 )
	  	   {
			if( strlen( buf ) + strlen( get_skin_tone( ch, iSkin ) ) > 77 )
			{
				mudstrlcat( buf, "\r\n", MAX_STRING_LENGTH );
				send_to_desc_color( buf, d );
				buf[0] = '\0';
			}
			else
				mudstrlcat( buf, " ", MAX_STRING_LENGTH );
		    }
		    snprintf( buf2, MSL, "&R[&z %s &R]&D", capitalize( get_skin_tone( ch, iSkin ) ) );
		    mudstrlcat( buf, buf2, MAX_STRING_LENGTH );
	        }
        }
        mudstrlcat( buf, "\r\n&w: ", MAX_STRING_LENGTH );
	send_to_desc_color( buf, d );
	d->connected = CON_GET_SKIN_TONE;

Yes. As it exists in Smaug, capitalize() also returns a static char value, so it's subject to the same problems as strlower().

I'm also in the same boat you are. I understand pointers well enough, even if it's not a "proper" technical understanding of it. But C strings throw me for a loop ( ACK a pun! ) every time I need to do something more complicated than print it somewhere.

Well, apparently this is just me, but I draw a sharp line between just using pointers a lot and truly understanding the mechanics under the hood. For example, if you truly understand pointers, you should always wonder what is happening when you call a function that returns a char*: did that block of memory just get allocated? Do I have to free it? Is it returning a pointer to the argument I sent in? Is it a pointer to a static buffer? Having a deep understanding of pointers will prevent you from getting confused by this precisely kind of issue. Strings to me are nothing but a special case of pointers where the block of memory happens to contain a more or less interesting sequence of characters terminated by a null.

Given context that some people are aware of, I feel the need to specify that that was not meant as a personal jab. I was just trying to say that for me the concepts are really very similar and the issues (of which memory management is the most common) are often the same.

I guess by that line of reasoning my understanding of what's going on is sound enough. I don't know if my understanding of pointers could be considered "deep" in the sense you mean but I don't run into a lot of trouble with memory allocation problems.

[link=C_Pointers:_The_Basics]there is this article[/link] which brushes over the basics of pointers, maybe everyone should give it a read (and possibly improve this article)! To most people pointers seem to be a pretty hard concept to grasp and they try to learn as little as they need to get by, but when string manipulation turns into pointer arithmetic, things can get complicated.



Heh, this should be the case for everyone considering that's exactly what C strings are.

The introduction to that article – where it is said that to understand pointers, you need to think about computer memory layout and how compilers refer to integers – reminds me of something I saw on Samson's quote list: "To understand recursion, you must first understand recursion". I think that's the big difficulty with pointers: to understand them in depth, you really do need to understand memory layout (and its division into code, data and runtime segments), how compilers refer to variables, how compilers create stack frames, how the heap is managed, and so forth. So to understand pointers, you kind of have to understand everything about pointers except for the actual pointing and dereferencing. :smile:

It's funny, because I do remember when pointers were a mystery to me, and I knew you had to do 'new', you called methods with '->', and you had to delete using 'delete', but that was really a superficial understanding. (Does copying the object copy the memory? Oh wait… it's a pointer to the object??) Then at some point I had an epiphany of sorts; I don't remember exactly when that was or what triggered it, but I definitely had ~3 years of using pointers without really understanding them at more than a superficial level. Classes like compilers and operating systems really hammered in the message, though…

I'll have to read the rest of that article sometime and see how they explain it. ("They" because I couldn't find an author listed on it?) I'm also curious to go to the intro class websites here and see how they explain pointers. (All of their handouts are online, which is pretty nifty…)

It's an article. Our article section here works a lot like a wiki. If you check out the revisions you'll see Luriel of Shadowlands originally posted the content… then edited it many times. You can do that too! I wrote up two articles about the section, [link=navigating articles]here[/link] and [link=add article]here[/link]. They pretty much sum up how it works.

Oh. I figured an article was like an upload, except that it's mostly text. Nifty that it's more like a wiki. :smile: Thanks for clearing that up.

Well, I understood that it returns a static buffer, but my main question was, is it going to return the same thing over and over because I used it, or will it actually return what it's supposed to because it only calls it once per iteration over the loop?

The answer to your question lies in understanding how pointers to static buffers work. :smile: Basically, you cannot "queue up" results from the function unless you're copying it into a local buffer. So if you are calling it once per iteration, and not needing to store its results through a second call, then you are fine.