"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in news:fm8urf$2j9$1
@news.datemas.de:
OK. Fine. You talk about absence of conversion, yet you yourself
introduce the conversion mechanism. It's called 'GetItem'. Instead
of writing
DoSomethingWithItem(5);
I _would_ (if I were to use your library) write
DoSomethingWithItem(GetItem(5));
Just to avoid using a local object which I don't need for anything
else. So, what's the point?
It's a little hard to explain this without going into a long-winded
explanation of how the code works, but I'll try give a simplified
version.
* Let's say we have 4 items.
* Let's say we have 3 combinations, where each combination consists of a
series of items.
* The first combination consists of items 0 and 1.
* The second comination consists of items 0 and 2.
* The third cominations consists of item 0, 1 and 2.
When you query which items are contained in the third combination, you
get back a pointer to the first element of an array; this array contains
the indices of the items, i.e. {0,1,2}.
The indices of the combinations are very distinct from the indices of
the items but it's quite easy to mix them up by accident.
(Sorry I know that that's a poor explanation, but it would probably take
me an hour to explain the code if we were sitting across a table from
each other... let alone over the written word)
Suffice to say though, I want the index of a combination to be totally
incompatible with the index for a item, such that they can never be
mixed up. So instead of having:
unsigned combo, item;
, I have:
struct HandleCombo { unsigned i; } combo;
struct HandleItem { unsigned i; } item;
Now they can never be mixed up.
That's my solution to the problem, and it works. I only posted here
because I figured people may have encountered this problem before and
perhaps come up with a more elegant solution than I did.
It appears though that the struct way is the way to go.
them, creating new types are done using class, struct, or enum. An