(merging replies)
Originally posted by jorrit
C or C++ are not actually not THAT high-level languages. The core language features are on purpose put pretty close to the bare machine.
you\'re right, at least with C (I don\'t know if with C++ is on purpose or derived for relaying in C), but I think that you should only use that tricks for special cases (hardware issues, etc), not for trivial cases as this.
in fact -1 could be set in example to zero in some compiler, because it\'s the closest value in the unsigned range to -1.
Do you have a reference on this? I don\'t think this will ever happen and I doubt it is described in the C++ reference manual like this.
I don\'t, but I suppose that this is not described, and so it\'s up to each compiler to decide what to do when using wrong values. you were right: actually it works with GCC, and probably will continue to be valid in the future with this compiler, not sure about other compilers.
again, it\'s not semantically correct to asign -1 to an unsigned int/size_t value, but do as you wish: you\'ll do it anyway 
You misunderstood me. I never said it was correct. The only thing I said was that it would work. But working != correct. Semantically it is indeed not correct and it is best that it is fixed.
I\'m glad to read this, and my apologies for the confusion. I think that any of the developers are equal or more familiar with C++ than me, and much more familiar with PlaneShift code, so it\'s up to you to decide when and how to fix it, that function is quite complex for me at the moment.
Originally posted by jorrit
Originally posted by Ginga
then you can use \"char\" for most of the unsigned int purposes, since it\'s also standard C/C++, and it\'s implemented as an 8-bit unsigned int 
think about syntax and semantics..
I don\'t understand what you mean to say here. size_t is used as the standard index type for arrays in C++ (i.e. look at STL for example). Why should we use another type for this when C++ says it should be size_t? We can hardly use char here.
well, I missed some parts of the function, that values interact with Lenght() and the variable is used at the end of the functions as an array, so it makes sense size_t here -- my apologies again.
just to explain what I mean with the char example, I thought that size_t didn\'t make sense there, and so I mean that you can also use char as index (it works), but would be semantically incorrect as well:
[05:24]
/tmp $ g++ lala.cpp && cat lala.cpp && ./a.out
#include
int main ()
{
char lala;
int array[21];
for (lala = 0; lala < 21; lala++)
{
array[lala] = lala*lala;
std::cout << array[lala] << \" \";
}
std::cout << \"\\n\";
return 0;
}
Output: 0 1 4 9 16 25 36 49 64 81 100 121 144 169 196 225 256 289 324 361 400
well, so I hope that some of you pick up this and \"fix\" it some day
PS: is this the right place to report this bugs or not-quite-bugs? not sure about this.
