Need a C++ guru

[Kobaz]

When comparing an int with an unsigned int, are both promoted to a long by the compiler?

[Shendare]

According to the assembly generated, my Visual C++ 2008 appears to treat both as unsigned ints.

Different compilers may implement such things in their own way, however.

[KLS]

Depends, MSC++ 32 bit compiler treats long and int essentially the same, however you can't rely on this being the case on other platforms or software configurations.

[Kobaz]

So in the following code snippet:

int a = -1;

unsigned int b = 3000000000; // 3 billion

if ( a > b) { "true" >> cout } else { "false" >> cout };

what comes out in Visual C++?

[Shendare]

My compiler outputs "true" in the presented situation.

Microsoft Visual C++ 2008 Standard on WinXP Pro 32-bit.

[Kobaz]

What about:

int a = -1;

unsigned int b = 3000000000; // 3 billion

if ( long(a) > long(b)) { "true" >> cout } else { "false" >> cout };

?

[Shendare]

Still true. In 32-bit, long is the same as int, so they're both being cast as signed ints at that point, changing b from 3000000000 to -1294967296, which is less than -1.

[Kobaz]

Sigh. To an old Smalltalk programmer like me, I have to wonder why C++ is called "Object Oriented". I try to understand the language, but it seems to be quite unintuitive.

I'm struggling to understand the emu code - I keep expecting fundamental data types to "do the right thing, with no surprises". How do people write robust correct code in C++ without going mad?

Thanks for your time, I'll just keep away from the code, as I seem to break things due to my Smalltalkness. Perhaps I'm just too old..... everything got hard after about 1986. And don't get me started on Java....

[Shendare]

Well, object-oriented has more to do with classes and inheritance and derivation than anything else.

If things are being done properly, you should practically never be in a situation where you're comparing a signed type with an unsigned type anyway.

The fundamental piece of data that's being tracked by a particular integer variable should be conceptualized as either allowing negative values or not, and should then always be stored in an appropriately typed variable.

Is there a particular piece of code in the Emu source that's causing you this grief?

[Kobaz]

This thread is about to go way off topic....

I was thinking of modifying the game to make it far more friendly for my kids (the youngest is only 7), so I wanted to add easier corpse recovery, and commands that would be richer macros to make it more fun for them, whilst requiring them to think and read more. So I was digging around in the code, trying to make sense of it. I was getting confused by the compiler warnings.

The problem seems to be that I read an expression like "a > b" as "the message > is sent to the instance a with the argument instance b", but it seems that a doesn't know that it's being asked to compare itself to b, because it isn't! This seems to me to be a pure procedural language with classes, and not an OOL as I understand it, which is objects being sent messages, even classes are just objects (Smalltalk background - I haven't done procedural programming for many many years). int is not an object in C++, indeed it seems that only things that are explicitly called with new are objects, which is not what I'm used to!

In Smalltalk everything in the code is either a reference or a message to a reference to an instance. If an Integer is asked to compare itself to another class, it sends a message to that class to create a new instance of the other class from itself (the Integer), and passes the message and argument to the new reference, and returns the result (this is polymorphism). This is clearly not how C++ works. I'm not sure that I have the time to learn another language, especially one that has some features that look a bit OOL but work completely differently, given my very busy life. It's the subtleties that will stymie me, as I have worked with C a long time ago, but the emu code is sufficiently different (and far more sophisticated) than any C I ever wrote that I seem to spend more time trying to work out what the language is doing than actually implementing anything.

[Shendare]

Ah, I'm starting to get the picture.

C++ would allow you to create a new class based on an int in order to add functions and override operators for enhanced functionality, but at its core C++ is based on C, which is itself an abstraction of assembly and pure native machine code.

This means that the foundation of C++ consists of the fundamental data types that can be directly worked with by the CPU... just different sizes of integers and floating points.

Anything beyond the numbers is implemented programmatically via classes, functions, and operators.

[Yeormom]

Originally Posted by Kobaz

When comparing an int with an unsigned int, are both promoted to a long by the compiler?

You should get in the habbit of casting the variables to the degree of precision you are actually trying to get. By doing so, you never need to smoke test that procedure as you know exactly what will happen every time. It's good programming practice that unfortunately rarely makes it to the hobbyist world.

[Kobaz]

Ok, that makes sense. Since (as was pointed out above) on a 32 bit system a long is the same precision as an int, what should I be casting to in order to get the scenario I started with, and how? And is casting 32 bit signed to 64 bit signed expensive?

[Shendare]

It isn't generally expensive at all. Most compilers and processors can work with 64-bit numbers inherently.

However, different compilers do use different terms for explicit 64-bit terminology. In MS C++ the internal type name is '__int64', as all of their integer types are actually aliases for __intXX precision-defining monikers (char is __int8, short is __int16, WORD would be 'unsigned __int16', etc.)

LONGLONG (all caps) is a common typedef defined in Windows.h for MS C++ as well, which maps to __int64.