Thread: Need help with a main function test

Originally Posted by whiteflags

Haven't read the standard lately?

size_t is unsigned.

Nope. The standard isn't something you read every day :P
And besides, I forget things too.

Now my examples may or may not compile, but not for the reasons you suggest.

What reasons? The first will fail to compile on 64-bit systems with Visual C++. I tested.
All other loop variants will compile, but may cause compiler warnings.

ULL should be a workable suffix for 64-bit systems.

But again, we want something that is system agnostic. We don't want to choose
unsigned int i = 0U or unsigned long long i = 0ULL.
We want to match the type to the type of the size. That way, the compiler does the work for us.

And besides, I forget things too.

O_o

Is a "ctrl+f" too complicated?

Wait.

Have you just stopped pretending that you don't rely on me to complain? ^_^v

What reasons?

In fairness, you aren't doing a great job explaining the source of the error.

Code:

for (size_t size = arr.size(), i = 0U; i < size; i++)

The example should compile without error even when `size_t' and the literal `0U' are different types thanks to implicit conversions.

Code:

for (auto size = arr.size(), i = 0U; i < size; i++)

The `auto' doesn't allow for the implicit conversion because the type isn't fixed forcing the compiler to complain about the inability to decide the appropriate type.

Soma

Originally Posted by whiteflags

You should be sure when you correct me, unless you believe you are entitled to your own facts.

We make mistakes. I figured I remembered that size_t was not specified, but I was wrong. It happens. No one is perfect.

Originally Posted by whiteflags

The product will promote the bald 0 for you, but I am not annoyed by suffixes. YMMV.

I'm not annoyed by suffixes either, but what is the suffix for size_t? To my knowledge, there isn't one. So that means you'd have to rely on integral suffixes, but then you run into trouble that size_t's definition can change on different compilers, platforms, etc.

Originally Posted by whiteflags

And to be clear, I'm glad I got you to explain your reasoning for the initialization. You just said it was "better" and then proceeded to write code. To me, it was strange. However, for will not allow you to initialize more than one kind of thing, so you can use that fact in the future.

That's great, though initially I meant that using std::array was the "better" approach. The initialization part was just how I write code nowadays that to a tip a found on Sutter's blog.

Originally Posted by phantomotap

O_o

Is a "ctrl+f" too complicated?

Wait.

Have you just stopped pretending that you don't rely on me to complain? ^_^v

Well, you know... it takes time. Unless I'm really in the mood, I don't want to bother with the standard, so eh... I don't check all facts before posting, but I try to not post things I absolutely know is wrong.
And sometimes I post things I remember wrong. It happens. So yeah, sorry about that.

Originally Posted by whiteflags

It's just weird, because I did compile those snippets in a program and they were clean. Sorry folks.

Well, it's not really that weird. You made the assumption that size_t is an unsigned int. Which is true sometimes. Yeah, Visual C++ also happily accepts your code on 32-bit builds, so it might be easy to assume it's correct.
But if size_t is really not an unsigned int, the first one will fail to compile due to the reasons phantom mentioned.

Originally Posted by whiteflags

To be perfectly clear, I don't need these kinds of replies from you. I expect you to be reasonably correct, and when you aren't, and I can prove it, I will.

That's great. This is one of the advantages of a forum with multiple experts. If one makes a mistake, someone else may correct it. That's a great thing and it is someone I welcome. If I say something wrong and someone else proves it wrong, then I will gladly accept my mistake.

I think there would always be one. If you can't express a literal size_t then what good is size_t? It would always be unsigned something. Unsigned long, unsigned long long... as many bits as you need.

To me, this is the same as asking, what good is a typedef? Just because you can't express it with a literal (if you really, really wanted to, though, you could always use a user-defined literal for that) doesn't mean it's no good. You could always just do (size_t)0.

Integer promotion, auto use... choices, choices...

>_<

You two are again talking about arrays and indices when the correct approach remains iterators.

Code:

#include <array>

int main()
{
    using namespace std;
    array<int, 4> s;
    //int s[4];
    for(auto cC(begin(s)), cT(end(s)); cC < cT; ++cC)
    {
        // *cC
    }
}

We don't need to worry about a bizarre signed `size_t', integer promotion, implicit conversions, casts, or ambiguous `auto' resolution.

Go. Team. Iterator!

Soma