Integer Emulation

In response to cpjust and King Mir and my own style, I fiddled with creating this class in response to fulfilling everyone's needs.
The goal was to get rid of get/set for every variable to make it easy to access and set and get, while still maintaining the advantages of a set/get.
Hence, here is a integer/floating emulation class.
All other operators are implemented, as well as a logging variable. I also created a thread-safe version (using Critical Sections) of the class.
I imagine there are quite a few bugs left in the implementation, though. And besides from the missing operator, there is no logging (though it is supported).

Now, those who wish can help to perfect this utility and all can be happy :D
There are two files:
CPPType.h -> contains the definition of the CCPPType (not thread safe) and CThreadCPPType (thread safe) class.
CPPTypeImpl.h -> contains the actual implementation.

I think you forgot about const-correctness and overloading operator>> and operator << for istream and ostream.

UPDATE:
Added const correctness.
Added filestream overloads.
Made operator T virtual, so polymorphism is now possible (required for filestream operators). Perhaps all other operators should be made virtual, as well.
Fixed bug in a CThreadClassType constructor (didn't initialize critical section).

UPDATE2:
Added 3 more operators.
Added (hopefully) complete const correctness.
Fixed a few bugs (compile warnings & errors).

All tests now pass except for

MyInt3 = MyInt2++;
MyInt3 = MyInt2--;

Where

MyInt2 = CClassType<int>
MyInt3 = CThreadClassType<int>

They give unambiguous errors. Not sure what to do about this.
Some more exotic syntax such as

MyInt = MyInt + 100;

May also fail with an unambiguous error.

New files uploaded.

Bug here:

Code:

TT CThreadClassType<T>::CThreadClassType(CClassType& Data) { InitializeCriticalSection(&m_Sync); // BUG!!!! EnterCriticalSection(&m_Sync); m_bLogging = Data.m_bLogging; m_Data = Data.m_Data; LeaveCriticalSection(&m_Sync); }

You're missing unary operator +.

I dislike your Lock and Lock2 macros.

I would perfer the two parameter friend function version of operators like binary + so that both sides are implicitly convertable.

If you want to prevent copying then your copy constructor and copy assignment operator need to take const references.

Spelling mistake: MinEqualThenData.
Actually, why do you give the parameter a different name each time? Why not just pick something like rhs and use that for all of them. Seems to me it would make your life a lot easier.

Operator << should take Data as a const reference.

#pragma once is less portable than propper include guards. Some use both.

Quote:

Originally Posted by iMalc

Bug here:

Code:

TT CThreadClassType<T>::CThreadClassType(CClassType& Data) { InitializeCriticalSection(&m_Sync); // BUG!!!! EnterCriticalSection(&m_Sync); m_bLogging = Data.m_bLogging; m_Data = Data.m_Data; LeaveCriticalSection(&m_Sync); }

Bug? How do you figure? It's a constructor, so it needs to initialize the critical section.

Quote:

Originally Posted by iMalc

I would perfer the two parameter friend function version of operators like binary + so that both sides are implicitly convertable.

You mean such as

Code:

operator + (T, const CDataType<T>& )

I think?

Quote:

Originally Posted by iMalc

Spelling mistake: MinEqualThenData.
Actually, why do you give the parameter a different name each time? Why not just pick something like rhs and use that for all of them. Seems to me it would make your life a lot easier.

Actually, no, it's not a mistake. There is a word "then" and there is a word "than". If this equals that, then do this. If this is less than that, do this.
Dunno. I just find making a little descriptive names better. Anyway, I changed them all to "Data" instead.

Quote:

Originally Posted by iMalc

You're missing unary operator +.

Quote:

Originally Posted by iMalc

If you want to prevent copying then your copy constructor and copy assignment operator need to take const references.

Quote:

Originally Posted by iMalc

Operator << should take Data as a const reference.

Missed those.

Uploaded new files with more fixes.

UPDATE: Proper include guard.
Got rid of macros.

UPDATE2:
Re-ordered operators a little.
Added global operators. All tests pass!
Yes, even this:

Code:

MyInt = MyInt + MyInt - MyInt * MyInt / MyInt % MyInt & MyInt << MyInt >> MyInt ^ MyInt | MyInt %= MyInt &= MyInt *= MyInt += MyInt -= MyInt /= MyInt <<= MyInt >>= MyInt ^= MyInt |= MyInt;

Quote:

Originally Posted by Elysia

UPDATE2:
Re-ordered operators a little.
Added global operators. All tests pass!
Yes, even this:

Code:

MyInt = MyInt + MyInt - MyInt * MyInt / MyInt % MyInt & MyInt << MyInt >> MyInt ^ MyInt | MyInt %= MyInt &= MyInt *= MyInt += MyInt -= MyInt /= MyInt <<= MyInt >>= MyInt ^= MyInt |= MyInt;

How would you know? ;)

--
Mats

It compiles at least, which it should! I tried it.
But there is more work to be done. I should template all the operators, too.

My point was more that the value is undefined in C or C++ for regular variables, so it's unlikely to expect a different implementation to be predictable. [As this is the same thing as the "i++ * i++ * i++" that we had a few days back - just because you use += or *= doesn't change it].

It's good that it compiles of course, but it's kind of meaningless.

--
Mats

Absolutely. I don't think the value is defined, but it should compile, because otherwise it breaks code, and destroys the "emulation," which it shouldn't.
It's not directly a "safe" class. You still have to have common knowledge and know the rules of the language.

This looks weird:

Code:

TT std::istream& operator >> (std::istream& Stream, const CClassType<T>& Data);

Logically, reading into an object changes it, so it cannot be passed by const reference, thus it should be:

Code:

TT std::istream& operator >> (std::istream& Stream, CClassType<T>& Data);

I don't think I tested that one. Assignment operator isn't const, so it should definitely give a compile error. I'll fix that.

UPDATE:
Templated all operators.
Added more global operators.
Renamed class to CCPPType and CThreadCPPType.
I'm having trouble with unambiguous operators, however. It conflicts with the class and global operators for some and some between two global operators. But without all of them (if you comment out one), it will give other ambiguous errors. I'm not sure how to proceed.

Mind attaching your test suite?

Sure, these ones are causing problems atm:

Code:

CThreadCPPType<int> MyInt; CCPPType<int> MyInt2; MyInt = 100; MyInt = MyInt + 100; MyInt = MyInt - 100; MyInt = MyInt * 2; MyInt = MyInt / 2; MyInt -= 100; MyInt += 100; MyInt *= 100; MyInt /= 100; CThreadCPPType<int> MyInt3 = MyInt++; CThreadCPPType<int> MyInt4 = ++MyInt; MyInt3 = MyInt--; MyInt4 = --MyInt; MyInt = MyInt & 0xFFFF; MyInt &= 0xFFF; MyInt = MyInt | 0xFFFF; MyInt |= 0xFFFFFFFF; MyInt = MyInt ^ 0xFFFF; MyInt ^= 0xF; MyInt = -MyInt; MyInt = !MyInt; MyInt = MyInt % 100; MyInt %= 2; MyInt = MyInt >> 10; MyInt = MyInt << 10; MyInt >>= 2; MyInt <<= 2; MyInt = ~MyInt; bool b1 = (MyInt == MyInt); bool b2 = (MyInt != MyInt); bool b3 = (MyInt > MyInt); bool b4 = (MyInt < MyInt); bool b5 = (MyInt <= MyInt); bool b6 = (MyInt >= MyInt); bool b7 = MyInt; int n = MyInt; int* p = &MyInt; MyInt = +MyInt; MyInt = MyInt + 100 / MyInt & MyInt + !MyInt; MyInt += MyInt += MyInt += MyInt; MyInt = MyInt + MyInt - MyInt * MyInt / MyInt % MyInt & MyInt << MyInt >> MyInt ^ MyInt | MyInt %= MyInt &= MyInt *= MyInt += MyInt -= MyInt /= MyInt <<= MyInt >>= MyInt ^= MyInt |= MyInt; MyInt2 = 100; MyInt2 = MyInt2 + 100; MyInt2 = MyInt2 - 100; MyInt2 = MyInt2 * 2; MyInt2 = MyInt2 / 2; MyInt2 -= 100; MyInt2 += 100; MyInt2 *= 100; MyInt2 /= 100; MyInt3 = MyInt2++; MyInt4 = ++MyInt2; MyInt3 = MyInt2--; MyInt4 = --MyInt2; MyInt2 = MyInt2 & 0xFFFF; MyInt2 &= 0xFFF; MyInt2 = MyInt2 | 0xFFFF; MyInt2 |= 0xFFFFFFFF; MyInt2 = MyInt2 ^ 0xFFFF; MyInt2 ^= 0xF; MyInt2 = -MyInt2; MyInt2 = !MyInt2; MyInt2 = MyInt2 % 100; MyInt2 %= 2; MyInt2 = MyInt2 >> 10; MyInt2 = MyInt2 << 10; MyInt2 >>= 2; MyInt2 <<= 2; MyInt2 = ~MyInt2; b1 = (MyInt2 == MyInt2); b2 = (MyInt2 != MyInt2); b3 = (MyInt2 > MyInt2); b4 = (MyInt2 < MyInt2); b5 = (MyInt2 <= MyInt2); b6 = (MyInt2 >= MyInt2); b7 = MyInt2; n = MyInt2; p = &MyInt2; MyInt2 = +MyInt2; MyInt2 = MyInt2 + MyInt2 - MyInt2 * MyInt2 / MyInt2 % MyInt2 & MyInt2 << MyInt2 >> MyInt2 ^ MyInt2 | MyInt2 %= MyInt2 &= MyInt2 *= MyInt2 += MyInt2 -= MyInt2 /= MyInt2 <<= MyInt2 >>= MyInt2 ^= MyInt2 |= MyInt2; CThreadCPPType<int> MyInt5 = MyInt2; MyInt5 = MyInt2; { std::ofstream MyOut("C:\\test.txt"); MyOut << MyInt << MyInt2; } { std::ifstream MyIn("C:\\test.txt"); MyIn >> MyInt >> MyInt2; }

Memmap can also be a trouble, the way it handles integers.
Btw, I also typedef'd standard typedefs such as uint64_t to the CPPType class, so MemMap now uses the CPPType class.

Code:

// 7.18.1.1 Exact-width integer types typedef CCPPType<__int8> int8_t; typedef CCPPType<__int16> int16_t; typedef CCPPType<__int32> int32_t; typedef CCPPType<__int64> int64_t; typedef CCPPType<unsigned __int8> uint8_t; typedef CCPPType<unsigned __int16> uint16_t; typedef CCPPType<unsigned __int32> uint32_t; typedef CCPPType<unsigned __int64> uint64_t; typedef CThreadCPPType<__int8> tint8_t; typedef CThreadCPPType<__int16> tint16_t; typedef CThreadCPPType<__int32> tint32_t; typedef CThreadCPPType<__int64> tint64_t; typedef CThreadCPPType<unsigned __int8> tuint8_t; typedef CThreadCPPType<unsigned __int16> tuint16_t; typedef CThreadCPPType<unsigned __int32> tuint32_t; typedef CThreadCPPType<unsigned __int64> tuint64_t;

My immediate concern is that the tests only test that "it compiles". There is no (automated) test to verify correct calculation.

--
Mats

That's a given to add, I agree with that. Unfortunately, the project won't link at the moment, due to template mismatch. I never liked how you make templates. They're powerful, I love them, but they're far too advanced to implement.
Figures. The compiler was screwing up. I did a rebuild and now I'm getting more errors. Yay :)
UPDATE: Hey! It compiles. It links. No errors. No warnings! No ambiguous errors! Now just to implement the rest.

Bah.
The compiler and I seem to be at odds. Implementation is done. Now it's the testing stage.
In the following,

Code:

TT TNewT CThreadCPPType<T> CThreadCPPType<T>::operator + (const NewT Data) const { Lock(); CThreadCPPType<T> Temp = CCPPType::operator + (Data); Unlock(); return Temp; }

The compiler should call CThreadCPPType(const CThreadCPPType<T>&) to construct a temporary object to return. However, this is also where the error lies. It generates a built-in constructor for it, which means it will not initialize the critical section and therefore crash.
But I seem to have added overloads for all necessary constructors:

Code:

CThreadCPPType(); explicit CThreadCPPType(bool bLogging); TNewT CThreadCPPType(NewT NewData, bool bLogging = false); TNewT CThreadCPPType(const CCPPType<NewT>& Data); TNewT CThreadCPPType(const CThreadCPPType<NewT>& Data);

Indeed, when looking at the assembly, I can clearly see that it's calling the function:

Code:

CThreadCPPType<int>::CThreadCPPType<int>(const CThreadCPPType<int> &)

Yet the compiler will not call my constructor.
I've also found that it will call one of these constructors if they exist:

Code:

CThreadCPPType(const CThreadCPPType<int>&) CThreadCPPType(const CThreadCPPType<T>&)

But it will never either of these constructors:

Code:

TNewT CThreadCPPType(const CCPPType<NewT>& Data); TNewT CThreadCPPType(const CThreadCPPType<NewT>& Data);

The error occurs at the line

Code:

MyInt = MyInt + 100;

In the test source code.
I don't know what the heck is going on right now, so I'll keep investigating. But if someone knows, it would spare some headache.

I'll upload latest source.

Heh, out of the 21 tests, some still fail:

Quote:

Test 1: Success!
Test 2: Success!
Test 3: Failure!
Test 4: Failure!
Test 5: Failure!
Test 6: Success!
Test 7: Success!
Test 8: Failure!
Test 9: Failure!
Test 10: Failure!
Test 11: Failure!
Test 12: Failure!
Test 13: Failure!
Test 14: Failure!
Test 15: Failure!
Test 16: Success!
Test 17: Failure!
Test 18: Failure!
Test 18: Failure!
Test 19: Failure!
Test 20: Success!
Test 21: Failure!

You'll have to specify what the (presumably) macros TT and TNewT actually do, and what the relationship is between CThreadCPPType and CCPPType.

My guess is that you are either supplying overloaded versions of the constructors (and one of the overloaded versions is being called, rather than the one you expect) or that you have forgotten to supply operator=()'s corresponding to each constructor. It's also possible you have defined some conversion operators, and one of those is being implicitly invoked.

Also, keep in mind the compiler is not obligated to create temporary objects (the standard explicitly allows a compiler to avoid creating them in some circumstances), so the compiler may be eliminating some of the copy constructor calls you are expecting.

Well, if you haven't looked at the source, they are macros defined as:

Code:

#define TNewT template<typename NewT> #define TT template<typename T>

And the relation between them is (again from the source), that CThreadCPPType is derived from CCPPType, and is supposed to be a thread-safe version of CCPPType.

As for the rest...
A constructor is being called. It's implicitly generated by the compiler because there's no source for it. I used disassembly to see it, and indeed, the compiler was calling a constructor.
I have some constructors, but for CCPPType and CThreadCPPType, there also matching assignment operators.
I do have some conversion operators, but again, the compiler isn't calling them because I would see.

I'm aware that the compiler can avoid temporaries, so long as it doesn't break the code. But as of yet, this is debug, so no ill effects (yet).

Again, the source is available, so if you feel like it, download it & compile it. I avoided this by providing an overloaded constructor for CThreadCPPType<T>, but it's not an ideal solution.

UPDATE:
Class now passes all 42 tests.
Uploading newest source.
Some overloads still needs to be made and perhaps more tests added to the testing suite, but I think the class is usable for now.

Uploading new source. Also uploading Help2.cpp - the test suite. I/O fails for some reason I don't know yet.

Operators, operators, operators...
No end in sight...

UPDATE:
Been working on that class a long time now. Updated test suite to hopefully do all possible sorts of combinations. All tests pass. So I think that would mean the CCPPType class is done.
I haven't updated the CThreadCPPType yet.
Also split both classes into their own files because they were growing too large.

UPDATE:
Aha! More missing operators! Add, add, add!

Quote:

Originally Posted by Elysia

Bug? How do you figure? It's a constructor, so it needs to initialize the critical section.

Yes, okay so if it is supposed to be a constructor (I hadn't noticed) then there's no point in using the critical section in there. I mean the object doesn't exist yet, so another thread sure as hell cant be trying to simultaneously access it. And since it's supposed to be a constructor, the argument should be a const reference.

Quote:

You mean such as

Code:

operator + (T, const CDataType<T>& )

I think?

Nope:

Code:

friend CDataType operator + (const CDataType<T>& , const CDataType<T>& )

Quote:

Actually, no, it's not a mistake. There is a word "then" and there is a word "than". If this equals that, then do this. If this is less than that, do this.
Dunno. I just find making a little descriptive names better. Anyway, I changed them all to "Data" instead.

Okay then I wont have to switch to talking about lack of constency instead:

Code:

bool operator < (const T MinThanData) const; bool operator > (const T BiggerThanData) const; bool operator <= (const T MinEqualThenData) const; // Odd one out bool operator >= (const T BiggerEqualThanData) const;

Quote:

Originally Posted by iMalc

Yes, okay so if it is supposed to be a constructor (I hadn't noticed) then there's no point in using the critical section in there. I mean the object doesn't exist yet, so another thread sure as hell cant be trying to simultaneously access it. And since it's supposed to be a constructor, the argument should be a const reference.

Alright, I guess I'll remove the locks from the constructors then. And all constructors do take a const reference now. Though I'm focusing on the non-thread safe for now. It's better to maintain one until it's finished and then update the thread-safe one.

Quote:

Originally Posted by iMalc

Nope:

Code:

friend CDataType operator + (const CDataType<T>& , const CDataType<T>& )

Hmmm. So all global operators should just be friend class operators then. It seems to work, as well.

Quote:

Originally Posted by iMalc

Okay then I wont have to switch to talking about lack of constency instead:

Code:

bool operator < (const T MinThanData) const; bool operator > (const T BiggerThanData) const; bool operator <= (const T MinEqualThenData) const; // Odd one out bool operator >= (const T BiggerEqualThanData) const;

Ah, typo!
But it's gone since long ago anyway :p

>> So all global operators should just be friend class operators then.
They don't need to be if they accomplish their work through the public interface, but there's nothing wrong with making them friends when necessary. You can often implement operator+ in terms of a copy constructor and operator+=, in which case making it a friend isn't necessary:

Code:

CDataType<T> operator + (const CDataType<T>& lhs, const CDataType<T>& rhs) { CDatatype<T> temp(lhs); temp += rhs; return temp; }

There's no real need for friends, then, though, seeing as the function can access the contents of the classes fine by utilizing the overloaded implicit conversion operator.
With the added bonus that if a thread-safe class is added to the non-safe one, it will still lock when returning the value.

If you're gonna go to the trouble of creating a numeric class, why not also include the lower & upper bounds for the number?
I was thinking something like this:

Code:

#include <iostream> #include <stdexcept> using namespace std; template <typename T, T TLowerBound, T TUpperBound> class Integer { public: Integer() : m_Num( TLowerBound ) {} Integer( const T& value ) : m_Num( value ) { if ( (value < TLowerBound) || (value > TUpperBound) ) { throw std::out_of_range( "Number is out of range!" ); } } T LowerBound() const { return TLowerBound; } T UpperBound() const { return TUpperBound; } T Get() const { return m_Num; } private: T m_Num; }; int main() { Integer<unsigned short, 0, 10> UShort; Integer<unsigned int, 1, 200> UInt; Integer<unsigned long, 3, 3000> ULong; Integer<short, -1, 40> Short; Integer<int, -2, 500> Int; Integer<long, -3, 6000> Long; cout << "UShort = " << UShort.Get() << endl << " Range = [" << UShort.LowerBound() << ", " << UShort.UpperBound() << "]" << endl << "UInt = " << UInt.Get() << endl << " Range = [" << UInt.LowerBound() << ", " << UInt.UpperBound() << "]" << endl << "ULong = " << ULong.Get() << endl << " Range = [" << ULong.LowerBound() << ", " << ULong.UpperBound() << "]" << endl << "Short = " << Short.Get() << endl << " Range = [" << Short.LowerBound() << ", " << Short.UpperBound() << "]" << endl << "Int = " << Int.Get() << endl << " Range = [" << Int.LowerBound() << ", " << Int.UpperBound() << "]" << endl << "Long = " << Long.Get() << endl << " Range = [" << Long.LowerBound() << ", " << Long.UpperBound() << "]" << endl; return 0; }

I don't have time to add all the operators you did, but you get the idea.
Unfortunately it won't compile for floating point numbers. :( I think you'd have to pass the Lower/Upper bounds through the constructor for float & double.

I don't really see any practical use of your attempt at thread safetey for this class.
Though x += 1; is fine, something simple like x = x + 1; is still not at all threadsafe. To get such a thing to be threadsafe you'd have to delve into expression templates I think.

The ambiguity problems you were having are generally caused by having and "implicit conversion operator". You'd be better off removing that and making an accessor method, such that you would then use friend binary operators. It's for exactly the same reasons std::string has a .c_str() method.

Quote:

Originally Posted by cpjust

If you're gonna go to the trouble of creating a numeric class, why not also include the lower & upper bounds for the number?

FWIW, I've written one of those already.

Quote:

I don't have time to add all the operators you did, but you get the idea.
Unfortunately it won't compile for floating point numbers. :( I think you'd have to pass the Lower/Upper bounds through the constructor for float & double.

You certainly can't use floating point numbers as template arguments. However you can provide integer numerator and denominator values for the upper and lower values with a similar thing for float types. It's not as nice to specify, but you can achieve the same compile-time effect.

Quote:

Originally Posted by cpjust

If you're gonna go to the trouble of creating a numeric class, why not also include the lower & upper bounds for the number?
I was thinking something like this:

Sure, I could do that. But I'm not really sure for what purpose there is to limit the range of a number?

Quote:

Originally Posted by iMalc

I don't really see any practical use of your attempt at thread safetey for this class.
Though x += 1; is fine, something simple like x = x + 1; is still not at all threadsafe. To get such a thing to be threadsafe you'd have to delve into expression templates I think.

I wouldn't say it isn't safe, since it will lock for operator +, adding one, and then lock for operator = when putting the number inside the class. Sure, it can be a lot of locking, but if you aren't worried about performance, I would think it's a lazy solution to thread safety. Otherwise you'd have to lock manually when reading/writing to the number.

Quote:

The ambiguity problems you were having are generally caused by having and "implicit conversion operator". You'd be better off removing that and making an accessor method, such that you would then use friend binary operators. It's for exactly the same reasons std::string has a .c_str() method.

Yes, they may cause some problems, but I like them. And the problem I was having was not related to the implicit conversion operator.
Seeing as it's supposed to be a shared class, I could add a method to get the number, and if you wanted to use the class, you could just comment out the implicit operator if you wanted. Some may like it, including me.

Quote:

Originally Posted by Elysia

Sure, I could do that. But I'm not really sure for what purpose there is to limit the range of a number?

Well most numbers begin and end on values that don't usually reflect real life situations.
0-255, 0-65535...

Some exaples would be:
Age cannot be negative; Speed cannot be negative and nothing can travel faster than the speed of light (yet); There are 60 seconds in a minute, 60 minutes in an hour, 24 hours in a day...

I see your point.

Quote:

Originally Posted by Elysia

I wouldn't say it isn't safe, since it will lock for operator +, adding one, and then lock for operator = when putting the number inside the class. Sure, it can be a lot of locking, but if you aren't worried about performance, I would think it's a lazy solution to thread safety. Otherwise you'd have to lock manually when reading/writing to the number.

Okay, well lets just say I wouldn't want to use it with return x = x - 1; instead of InterlockedDecrement for guarding the reference count of a smart pointer, or two threads may both try and free the object.
My point is that the operation isn't atomic, due to the fact that you lock and unlock twice. Once around the reading, and once around the writing, and it could get changed in between.

Ah, I see it now. Perhaps it might be an idea to derived from a CCriticalSection or such instead, then use a macro to lock, perform the expression, unlock.

Why not let the program do its own locking if it needs it? Numbers are used a lot, and opening/closing a lock for every single operation would be pretty expensive.
Locking as close to the resource as possible is easier and usually safer (less chance of missing something) than locking at a higher level, but it's much more resource intensive.

Hence the provided functions for locking/unlocking and a macro to do the dirt work so you don't have to bother writing your own code if you don't need it.
It could even work as a locking resource if the integer/float is going to be changed during the "update" or whatever it is the code is supposed to be doing.