14 Aug, 2009, JohnnyStarr wrote in the 61st comment:
Votes: 0
Davion said:
This is why when we wrote it, it passed the variable it was setting, but! You can put a fix in, and change
To a static variable
static char rev_buf[MAX_STRING_LENGTH];

Is this how you would return a local char* variable every time?
14 Aug, 2009, David Haley wrote in the 62nd comment:
Votes: 0
staryavsky said:
Is this how you would return a local char* variable every time?

"Every time" is a big word, but generally speaking, there are two ways to return a string:
1- Return a pointer to a static buffer on the stack, i.e. a buffer to memory that exists even after the function exits.
2- Return a pointer to the heap, i.e. memory that has been allocated dynamically (and that somebody must therefore free, at some point).

The second method is "more correct" most of the time for various reasons (there are some issues with static buffers) but the first method is very convenient in those cases where you can get away with it.

All these issues disappear with things like std::string, though.

The idea is that you should never return pointers to locally-scoped, non-static memory (e.g., char abc[123]) because that memory will be destroyed at function exit.
15 Aug, 2009, JohnnyStarr wrote in the 63rd comment:
Votes: 0
David Haley said:
All these issues disappear with things like std::string, though.

The idea is that you should never return pointers to locally-scoped, non-static memory (e.g., char abc[123]) because that memory will be destroyed at function exit.


With std::string, what would be a work around for concatenating with char pointers:
std::string both;
std::string first = "Johnny";
char *last = "Starr";

both = first + last; <- error


hopefully this has a work around, its really annoying to have to use strcat all the time. Plus with my project, all new strings are going
to be std::string, so this would be a great fix, I suppose in light of the whole static buffer issue, this would be yet another
reason to use std::string.
15 Aug, 2009, Kline wrote in the 64th comment:
Votes: 0
string first = "Johnny";  first += "Starr";
^– Works fine, do that :P
15 Aug, 2009, JohnnyStarr wrote in the 65th comment:
Votes: 0
Kline said:
string first = "Johnny";  first += "Starr";
^– Works fine, do that :P


Thanks, but my question wasn't can i concatenate a string literal, it was can i take an existing char *pointer and blend it in with an std::string? :biggrin:
15 Aug, 2009, Rendelven wrote in the 66th comment:
Votes: 0
std::string first;
char * last = "Starr"

first = "Johnny";

first.append(last);
15 Aug, 2009, David Haley wrote in the 67th comment:
Votes: 0
Or, both = first + std::string(last);
16 Aug, 2009, boblinski wrote in the 68th comment:
Votes: 0
Anyone have any ideas for fixing the problems though? :redface:
16 Aug, 2009, David Haley wrote in the 69th comment:
Votes: 0
You'll have to give line endings special treatment. In other words, you don't want to be reversing a whole string, but one line at a time.
24 Oct, 2009, Mudder wrote in the 70th comment:
Votes: 0
This seems to be the most appropriate place to ask this question since there seems to have been a lot of focus on std::string

Is there any reason all of the code I have been seeing lately is "std::string" instead of putting "using namespace std;" doesn't that remove the need to have "std::" before string ?
24 Oct, 2009, KaVir wrote in the 71st comment:
Votes: 0
Mudder said:
Is there any reason all of the code I have been seeing lately is "std::string" instead of putting "using namespace std;" doesn't that remove the need to have "std::" before string ?


Yes, you can use the using-directive if you want to avoid the advantages of namespaces.

http://www.parashift.com/c++-faq-lite/co...
24 Oct, 2009, Davion wrote in the 72nd comment:
Votes: 0
Mudder said:
This seems to be the most appropriate place to ask this question since there seems to have been a lot of focus on std::string

Is there any reason all of the code I have been seeing lately is "std::string" instead of putting "using namespace std;" doesn't that remove the need to have "std::" before string ?


It may remove the need, but you can run into some crazy problems when you use 'using'. Check out the actual std:: namespace and checkout all the globals it uses. I'd say, get over it and use the std::. It just removes a lot of ambiguity from your code. If you have some crazy code eg.

std::map<std::string,std::vector>::iterator i


You can scope 'using' to be local to a function.

int main()
{ using namespace std;
map<string,vector>:: i;
}


That way, you wont poison the entire source file. Again, I'd only use it if by chance one function contains a lot of references to the std namespace.

ninja'd. :P
24 Oct, 2009, Mudder wrote in the 73rd comment:
Votes: 0
Thanks you guys. I just wasn't aware there were benefits of avoiding the namespace.
24 Oct, 2009, Davion wrote in the 74th comment:
Votes: 0
Mudder said:
Thanks you guys. I just wasn't aware there were benefits of avoiding the namespace.


The benefits aren't in avoiding the namespace, they're in utilizing them to your advantage! I'd suggest reading up on them and all they can do for ya!
24 Oct, 2009, David Haley wrote in the 75th comment:
Votes: 0
As a rule, I don't ever put 'using namespace' in header files, and don't put it in the .cpp file unless it would be too annoying not to. This is more important for the header file, because I don't expect to get a whole lot of extra pollution just by importing a header: I expect to get what that header provides.
24 Oct, 2009, Mudder wrote in the 76th comment:
Votes: 0
I'm glad I joined this forum. You all know too much!

At the moment I finished my C++ book and would buy another but I'm going to wait until I return to America(I'm overseas currently). The books here are about double the price (currency conversion is definitely not double) and it'll just be problematic on my return flights to have extra things. So I'm trying to further my knowledge by screwing around with a codebase copy and asking questions on the forum.

@Davion, I'll do a google on namespace std and see what I can find.

Another question I've been wondering about. C-string and C++ string. From what I can tell, it's an easy decision that the C++ string is better. But when my book covered these, it didn't go into detail about which to use when and why. It just went over how.

So my question is… Why is C++ string better? How does it solve ROM memory issues? Is there ever a situation in where C-string is better?

If my questions end up requiring a lengthy response feel free to summarize the crap out of it if you don't want to go into detail. I'm more than happy to search for answers on the internet, but I'd rather be pointed in the right direction since I feel a broad search would give very few results to the MUD usage. :)
24 Oct, 2009, Runter wrote in the 77th comment:
Votes: 0
Mudder said:
I'm glad I joined this forum. You all know too much!

At the moment I finished my C++ book and would buy another but I'm going to wait until I return to America(I'm overseas currently). The books here are about double the price (currency conversion is definitely not double) and it'll just be problematic on my return flights to have extra things. So I'm trying to further my knowledge by screwing around with a codebase copy and asking questions on the forum.

@Davion, I'll do a google on namespace std and see what I can find.

Another question I've been wondering about. C-string and C++ string. From what I can tell, it's an easy decision that the C++ string is better. But when my book covered these, it didn't go into detail about which to use when and why. It just went over how.

So my question is… Why is C++ string better? How does it solve ROM memory issues? Is there ever a situation in where C-string is better?

If my questions end up requiring a lengthy response feel free to summarize the crap out of it if you don't want to go into detail. I'm more than happy to search for answers on the internet, but I'd rather be pointed in the right direction since I feel a broad search would give very few results to the MUD usage. :)


I think you already answered the question. C++ strings are "better". Better as in they have more functionality and you can get more out of them with less code. That's really the gold standard for better. When is C strings better? When you're using C. :P

But seriously, probably a few uses for C strings to be more light weight for very niche purposes, but 99.9% of all applictions should use a real string library instead of c-strings. A lot of times the reason C strings are used is because of reverse compatibility with C in muds. Once upgraded to C++ they often continue to use C strings.

Oh, and there are other string libraries out there that aren't standard that a lot of people can recommend. Some of which may be better or do things internally a little different.

Additionally, I hope this really doesn't turn into a C vs C++ thing. Seems like in the mudding community there's always a few people ready to fight that battle. :P
24 Oct, 2009, Mudder wrote in the 78th comment:
Votes: 0
Thank you. Time to see if I'm able to upgrade the C-strings to C++.
24 Oct, 2009, KaVir wrote in the 79th comment:
Votes: 0
Mudder said:
Thank you. Time to see if I'm able to upgrade the C-strings to C++.

Most Diku muds have their own shared string handling. Replacing it with std::string would require quite a lot of work, could result in some seriously nasty bugs if you get it wrong, and would actually increase the memory overhead of the mud.

If you're just tinkering with the code to learn, then try converting a few bits here and there - don't bother converting the whole lot. If you want to create an actual mud then honestly I would leave it as it is - it's a lot of work changing something that isn't broken, time that could be better spent improving the game.
24 Oct, 2009, Runter wrote in the 80th comment:
Votes: 0
Yes. I wouldn't advise overhauling an existing codebase using C strings to use std::string. Well, not unless you're a glutton for punishment.

I think there's lessons to learn by familiarizing yourself with C-strings anyways. I would advise in the future on new projects checking out std::string.

And like KaVir said. There's better places to spend your time if your goal is an actual playable product you can be proud of.
60.0/89