s32, u32, npos?

[Nox]

For setter functions which use negative values to reset we would have to make explicit reset/clear functions when going that way.

Why no just changing the setter so they use the npos as clear signal?

especially on the trouble which it could cause for the language bindings (which I also didn't think about yet when we discussed it on IRC).

I not really used to writing bindings but cant they define internally the npos just as -1 for a signedonly language?

[CuteAlien]

For setter functions which use negative values to reset we would have to make explicit reset/clear functions when going that way.

Why no just changing the setter so they use the npos as clear signal?

Sorry, that answer was only about strong99's idea. For solution 2 npos would be used as you wrote.

especially on the trouble which it could cause for the language bindings (which I also didn't think about yet when we discussed it on IRC).

I not really used to writing bindings but cant they define internally the npos just as -1 for a signedonly language?

Yeah - that is the question.

[CuteAlien]

Sorry, but none of the other 3 propositions are even likeable to me. I maintain 2 and to date, it's not only the most popular here, but the accepted standard, so...

To my knowledge that is not the case. I checked some other gui libraries this week because I was also interested in finding out how other libs cared about that. And all I checked so far used signed datatypes for classes with items except cegui which works with exceptions instead (and I really dislike using exceptions as return values!). It is standard for core classes wrapping data-structures which access items unchecked - like arrays, strings - which is why I still recommend using it there. So to my info - with solution 4 we would be as conforming to current standards as we could be - as well in core classes as in the higher level classes.

And yeah it's popular - but then again I also liked solution 2 just a week ago and was eager to start coding... before I started looking deeper into it. Which is why I want the discussion now before wrecking it accidentally :-) And please don't think I don't care about popular - if people still prefer solution 2 despite me arguing otherwise I will implement solution 2.

[Dorth]

Yeah, ok, I think exceptions are a pretty big no, unless someone got the best case ever for it, but considering someone can compile without exception, no code should ever depend on it.

[Jookia]

Clean code is good code.

[BlindSide]

I don't mind the signed thing too much even though I have an unexplainable bias against signed types (Because people use them too much where it's not needed).

Option 2 looks ok too, only problem is that the concept may be a little harder to understand for newbies. I think everyone is forgetting our niche market a little here. I agree that returning something like NOT_FOUND rather than NPOS may offset this issue a little though.

[MasterGod]

I like option #2.
1. I like irr::npos.
2.

...I have an unexplainable bias against signed types (Because people use them too much where it's not needed).

Same..
3.

Option 2 looks ok too, only problem is that the concept may be a little harder to understand for newbies. I think everyone is forgetting our niche market a little here. I agree that returning something like NOT_FOUND rather than NPOS may offset this issue a little though.

This would make them used to npos concept. I don't agree using another name.
4. Following STL standard is good.
5. Breaking code may be a serious thing but every war has its casualties.

That's about it..

[CuteAlien]

Sort of my last try arguing for solution 4:

I like option #2.
1. I like irr::npos.

Well, option #4 also uses irr::npos - just not all over the place.

2.

...I have an unexplainable bias against signed types (Because people use them too much where it's not needed).

Same..

Sure, everytime you can't use the sign it looks like a waste - and programmers hate wasting a bit. And it is cleaner in c++ to use unsigned if the number-range consist only of unsigned values. What makes the situation here different for me is that the functions should also accept non-indices are also valid inputs. And that means it's no longer a matter of correctness or cleaness but one of encoding the no-index values. Note that this is not the same in the core-classes which do only accept index value in the access functions.

3.

Option 2 looks ok too, only problem is that the concept may be a little harder to understand for newbies. I think everyone is forgetting our niche market a little here. I agree that returning something like NOT_FOUND rather than NPOS may offset this issue a little though.

This would make them used to npos concept. I don't agree using another name.

Yeah, this is some argument for npos. Though not necessarly a good for anything but the core-classes as basically no other common library seems to use it outside of core-classes.

4. Following STL standard is good.

That would be solution 4. STL is only about core structures and algorithms. As I found out all the big c++ GUI libraries use signed types.

5. Breaking code may be a serious thing but every war has its casualties.

I am not necessarly against breaking code, but I prefer to prevent it until it is necessary. But this time it's really badly breaking code - unless users care about signed/unsigned warnings (and I am sure many won't) this break will actually change the program-flow rather unexpected in many places (and the bad thing is that that code will still look correct on first view). While all what happens when breaking the interface again the other way round will be a few warnings to fix for people who have enabled that warning and nothing at all happens for the rest. And well, I have a real bad feeling doing that for something which looks to me by now just like the second best solution anyway.

Still - if I can't persuade you guys - I'm going to do at least one thing in next time: I will try to find out how much it will affect the language bindings and if libs like Jirr would be able to cope with this change at all. Unless anyone with actual experience in writing language wrappers saves me that time by commenting on it...

In the meantime you can propose a few more name-replacements for irr::npos. I would prefer using npos , but irr::no_idx would be my alternative. I don't like irr::not_found as it doesn't really describe the value correct (this isn't just used in the context of finding).

[CuteAlien]

I just found out another thing about npos. STL doesn't use it as much as I thought - actually there only seems to be string::npos. The container classes and algorithms work throughout with iterators for stuff like searching.

[alexionne]

I tend to use signed types as much as possible, and use unsigned types only where it is really neccessary or natural (like bitflags).

What I dislike is misuse of unsigned types, so I try to distinguish two types of unsigned values:
a) values which are not really numbers - like bitflags
b) values which domain is [0, oo) - like screen coordinates

As of a), unsigned types are more practical because of right shift and some other operations.

As of b), I often see (mis)use of unsigned types (even STL does it!) where signed type are perfectly natural and easier to use. Having a value which domain is [0, oo) doesn't imply its type should be unsigned, because domain for most of variables is usually [0, N], so values [N+1, oo) are still invalid for that domain.

Of-by-one values (like, -1 and 4294967295) are invalid and should both be check for correctness. Having type of some variable declared as signed doesn't imply its value will be correctly positive during runtime - you still have to assert/check it not only for -1/4294967295, but also for true valid range of that values. Having that in mind, I prefer to have functions like:
bool is_valid_value(<some-type> value)

So, my vote is for use of s32 as much as possible.

EDIT: ... meaning, +1 for CuteAlien's #4

[MasterGod]

You know what CuteAlien? You've persuaded me .
I have switched to option #4.

That is after reading your reply and the first post again.

Oh and mainly because of this:

I am not necessarly against breaking code, but I prefer to prevent it until it is necessary. But this time it's really badly breaking code - unless users care about signed/unsigned warnings (and I am sure many won't) this break will actually change the program-flow rather unexpected in many places (and the bad thing is that that code will still look correct on first view). While all what happens when breaking the interface again the other way round will be a few warnings to fix for people who have enabled that warning and nothing at all happens for the rest. And well, I have a real bad feeling doing that for something which looks to me by now just like the second best solution anyway.

P.S
alexionne - which option do you go for? as in number..

[Nox]

i thought a little about this issue and then started laughing because i realised that this is a selfmade developersonly problem. Why? Because if you ask a "normal" guy 'hey if you have a list, how would you address the first item?`'. I guess he will answer: 'well, the first gets the number one the second the number two and so on'. Then you may ask whats about the null. His answer my be 'this will address the place before the first or none at all'.

So the issue is complitly selfmade by our counting convention. The bad thing is that we can not change the counting convention because the user will get no warnings. Maybe marking the old getter/setter/finder as deprecated and adding new unsigned methods with a comment can be a option. But this is a really massive interfacechange .

[Halifax]

I know people don't like to deviate from the STL standard, but many people and even industry companies agree that npos is a black mark. Instead return the end/size, or something along those lines, just as iterators do.

I agree with option #4 the most, but I would eliminate the use of npos where the above is applicable.

There's one more solution I was thinking of that could solve the interfacing to other languages as well. You could just implement npos as the maximum signed integral instead of the maximum unsigned integral. At least you could do this where it is applicable, such as places where the value won't exceed 2 million. That alleviates the need to change everything back to s32, still allows you to interface with other languages that have no unsigned integral types, and gives a nice homogeneous API.

It is a little bit of trickery, but I don't believe it would cause any side effects.