std::min and 32/64 bits.

[Andrea Venturoli]

typedef std::vector<X> Xes;
Xes V;

Actually I had thought about "typedef"ing eithre
std::vector<X>::size_type or std::vector<X>.
So far I'm more inclined toward the second.

Xes::size_type const VLimit = 1000;
...
As result your problem is removed, the code works everywhere:

std::min( V.size(), VLimit );

This might be another good solution, actually.


Thanks
av.

 

[Tobias Müller]

I'm not speaking for the OP's case, but in a very general sense, you
may not know the exact set of possible target platforms in advance.

Sure. Generally, I try to produce portable code. But in that special case I
think it's too much

If you're committing the code to a public repository, you never know
who will use it on which platforms.

I was assuming that he is not working on a public repository, because he's
paid for it. But you're right it's possible.

Even you could upgrade the system
and see new warnings occur.

Warnings are not bad per se. They tell me there's a potential problem. I
analyze it, fix the problem, and the warning is gone.

Generally, it's more efficient to fix the problem when you see the warning
rather than beforehand:
- You don't have to search the code for potential problems because the
compiler tells you where they are.
- There are good chances that you actually never have to do it anyway.

Usually, persons that pay other persons for doing some work don't care
about such academic non-problems. If they pay someone to eliminate warnings
they do that because:
A) if it's a bug it, will cost money for support and bugfix and hurts the
reputation of the software, which drives away potential customers.
B) if it's no bug it distracts from real bugs and makes those more likely,
which costs money (see A).

But no warning -> no distraction and no bugs -> costs no money.

That's why I doubt that he is really meant to "fix" such special cases.

Tobi