Commands not registering in 1.9?

Ok so I stripped the verison of lua from 1.8v1 thats about these forums got it to compile clean and then got into the mud and try to add the tasks command. However I get this...

Log: Admin: cedit task create do_task
Log: [*****] BUG: Error locating do_task in symbol table. ../src/smaug: undefined symbol: do_task

Yet in mud.h I have the declare_do_fun for it wont allow me to add the command? am i doing something wrong thats been changed in 1.9?

You need do_task in a .c file somewhere, not just .h -- do you have that?

Yea actually for some reason I didn't notice that all of the functions have const in them? So im assuming that in itself is something I need to figure out as to why its don that way... But once changing do_task to have the const in the arguments it worked just fine.

Ah, well, yes, the prototypes need to match exactly for it to find the function; the constness of an argument makes a difference when trying to find a function. But it's good that it's working now :-)

Yea I'm not really sure what a const is or why you'd use them. I just happened to see another command had it so I put that in and it worked. So I was trying to get afkmuds boards working and it complained about converison so kayle said I might want to ask you to explain it if possible

Which conversion are you talking about? In general, constness means that a function can't modify the parameter:


void foo(char* c) {
c[0] = 'a'; // <-- legal
}
void foo2(const char* c) {
c[0] = 'a'; // <-- illegal
}

Kind of a very brief explanation but at the moment I can't write more, but that's the basic idea.

No that makes a lot of sense. And in fact I had an error like that pop up. However most of the errors was something along the lines of.."Converting from a const char to a char"

David, I'm not sure that "constness" is a real word (it certainly isn't in the dictionary my copy of Firefox uses...), but I thought const was a C/C++ term for constant which would, in C/C++ tell the function that it can't modify that parameter because it's treating it as a constant just like you'd use in math functions. Perhaps the phrase you were looking for was "state of constance"?

For example, in physics, the speed of light is considered a constant so it can be used in equations as an understood predefined "variable". (Hopefully that helps clarify a little more, Metsuro, though basically I'm sure David is better at explaining programming terms and such... and was not wrong in what he said other than making up a word to help explain a term...)

Constness is indeed a made-up word but not by me... it's a fairly accepted term for abbreviating the much longer phrase "the state of having the 'const' keyword". If you'd prefer, we could use the term "immutability", but I feel that would just confuse matters more...

Don't think of constness as being used for "predefined variables" like the speed of light. A function's input arguments can be entirely dynamic, after all. Furthermore, a const char* doesn't mean that the pointer is constant, but that it's a pointer to characters that cannot be modified.

Metsuro:

Yes, that's basically the same error. It's telling you that you're trying to use something that shouldn't be changed as a variable that can be changed. Going the other way is fine -- it's ok to refuse to change something that's happy being changed -- but it's not ok to allow changing something that refuses to be changed.

I think Constance is a girl's name. :P

Bear in mind the language changes, as I heard recently the word "Web 2.0" is the millionth English word (personally I don't see how two words can be "a word" but never mind).

David may have invented the millionth-plus one word, right before your eyes!

As for the meaning, in C the const idea (which is not just for parameters per se) tells the compiler you aren't planning to modify the item, which firstly allows it to optimize its handling of it, and secondly report an error if you do attempt to modify it.

The message "Converting from a const char to a char" is raised when you attempt to store something which was a pointer to const to a pointer to not const. This is because the pointer to not const could then be passed to another function which might modify it. Thus the error is in attempting to strip off the const-ness, rather than the attempt to change the const field, right now.

For example:



If the error wasn't raised on the second line, we would incorrectly attempt to modify the data the const pointer points to.

I agree that it makes no sense to call two words the millionth word. I think that, while languages may very well be subject to change over time, the only real reason we have a million words in the english language at this point is because we have dictionary sites (and certain "societies") that struggle each year to find new words to add to the list rather than simply being authorities of the language. I don't think this is really a matter of people, in general, having dropped a given word from common usage, nor having changed it's common meaning, nor even having added a new word through common usage.

In the case above with David's use of "constness", perhaps it is a commonly accepted vernacular amongst programmers of C/C++ (not that I'd ever heard/seen that word before, anywhere) but it hardly seems a reasonable prospect for being a new word, if anything it'd qualify as jargon.

As for Constance being a girl's name, so is Christian. :P

So Conner's is the politically correct and David's is the street slangish quick answer... Gotcha

I'm not entirely sure why we're debating accepted jargon, but ok... :-)

David, we're not debating it. That would require that we both argue and present our sides and then engage in rebuttal, etc. In this case you used a term which I'd never heard before and I called you on it. You (and Nick) explained its origin and I accepted it. Which part of that qualifies as a debate?

Aww come on guys let's maintain ourselves and pull back a second to collect our thoughts. Now I've followed this so far and I believe I got a bit of a grasp on this to retry again when I get home from work. So I may have further questions and if we all get bother by the thread we won't come back for the other questions

Normally the FUSS 1.9 base is already const-safe, so you shouldn't have much trouble with the Lua patch -- I imagine that you'll only have to make changes to the Smaug<->Lua code that was probably written before the constness requirement was enforced. (like when we were compiling with gcc instead of g++ -- gcc is laxer than g++, even when the latter is run in C mode instead of C++)