Writing Scalabe Software in C++

[Skybuck Flying]

Hello,

This morning I had an idea how to write Scalable Software in general.
Unfortunately with Delphi 2007 it can't be done because it does not support
operating overloading for classes, or record inheritance (records do have
operator overloading)

The idea is to write a generic integer class with derived integer classess
for 8 bit, 16 bit, 32 bit, 64 bit and 64 bit emulated.

Then at runtime the computer program can determine which derived integer
class is needed to perform the necessary calculations.

The necessary integer class is instantiated and assigned to a generic
integer class variable/reference and the generic references/variables are
used to write the actual code that performs the calculations.

Below is a demonstration program, it's not yet completely compiling, but
it's getting close.

// TestWritingScal ableSoftware.cp p : Defines the entry point for the console
application.
//
#include "stdafx.h"

class TSkybuckGeneric Integer
{
};
class TSkybuckInt32 : public TSkybuckGeneric Integer
{
private:
int mInteger;

public:

// constructor with initializer parameter
TSkybuckInt32( int ParaValue );

// add operator overloader
TSkybuckInt32& operator+( const TSkybuckInt32& ParaSkybuckInt3 2 );

void Display();
};

class TSkybuckInt64 : TSkybuckGeneric Integer
{
private:
long long mInteger;

public:
// constructor with initializer parameter
TSkybuckInt64( long long ParaValue );

// add operator overloader
TSkybuckInt64& operator+( const TSkybuckInt64& ParaSkybuckInt6 4 );

void Display();
};

//
// TSkybuckInt32

// constructor
TSkybuckInt32:: TSkybuckInt32( int ParaValue )
{
mInteger = ParaValue;
}

// add operator overloader
TSkybuckInt32& TSkybuckInt32:: operator+ ( const TSkybuckInt32&
ParaSkybuckInt3 2 )
{
mInteger = mInteger + ParaSkybuckInt3 2.mInteger;
return *this;
}

void TSkybuckInt32:: Display()
{
printf( "%d \n", mInteger );
}

//
// TSkybuckInt64
//
// constructor
TSkybuckInt64:: TSkybuckInt64( long long ParaValue )
{
mInteger = ParaValue;
}

// add operator overloader
TSkybuckInt64& TSkybuckInt64:: operator+ ( const TSkybuckInt64&
ParaSkybuckInt6 4 )
{
mInteger = mInteger + ParaSkybuckInt6 4.mInteger;
return *this;
}

void TSkybuckInt64:: Display()
{
printf( "%lu \n", mInteger );
}

int _tmain(int argc, _TCHAR* argv[])
{
long long FileSize;
long long MaxFileSize32bi t;

// must write code like this to use constructor ? can't just declare
a,b,c ?
TSkybuckInt32 A32 = TSkybuckInt32( 30 );
TSkybuckInt32 B32 = TSkybuckInt32( 70 );
TSkybuckInt32 C32 = TSkybuckInt32( 0 );
C32 = A32 + B32;
C32.Display();

TSkybuckInt64 A64 = TSkybuckInt64( 30 );
TSkybuckInt64 B64 = TSkybuckInt64( 70 );
TSkybuckInt64 C64 = TSkybuckInt64( 0 );
C64 = A64 + B64;
C64.Display();

FileSize = 1024; // kilobyte
FileSize = FileSize * 1024; // megabyte
FileSize = FileSize * 1024; // gigabyte
FileSize = FileSize * 1024; // terrabyte

MaxFileSize32bi t = 1024; // kilobyte
MaxFileSize32bi t = MaxFileSize32bi t * 1024; // megabyte
MaxFileSize32bi t = MaxFileSize32bi t * 1024; // gigabyte
MaxFileSize32bi t = MaxFileSize32bi t * 4; // 4 gigabyte
if (FileSize < MaxFileSize32bi t)
{
TSkybuckGeneric Integer AGeneric = TSkybuckInt32( 30 );
TSkybuckGeneric Integer BGeneric = TSkybuckInt32( 70 );
TSkybuckGeneric Integer CGeneric = TSkybuckInt32( 0 );
} else
{
TSkybuckGeneric Integer AGeneric = TSkybuckInt64( 30 );
TSkybuckGeneric Integer BGeneric = TSkybuckInt64( 70 );
TSkybuckGeneric Integer CGeneric = TSkybuckInt64( 0 );
}

CGeneric = AGeneric + BGeneric;
CGeneric.Displa y();

while (1)
{
}

return 0;
}

Probably minor compile issue's remain:

Error 1 error C2243: 'type cast' : conversion from 'TSkybuckInt64 *__w64 '
to 'const TSkybuckGeneric Integer &' exists, but is inaccessible
y:\cpp\tests\te st writing scalable software generic math\version
0.01\testwritin gscalablesoftwa re\testwritings calablesoftware \testwritingsca lablesoftware.c pp
152

Error 2 error C2243: 'type cast' : conversion from 'TSkybuckInt64 *__w64 '
to 'const TSkybuckGeneric Integer &' exists, but is inaccessible
y:\cpp\tests\te st writing scalable software generic math\version
0.01\testwritin gscalablesoftwa re\testwritings calablesoftware \testwritingsca lablesoftware.c pp
153

Error 3 error C2243: 'type cast' : conversion from 'TSkybuckInt64 *__w64 '
to 'const TSkybuckGeneric Integer &' exists, but is inaccessible
y:\cpp\tests\te st writing scalable software generic math\version
0.01\testwritin gscalablesoftwa re\testwritings calablesoftware \testwritingsca lablesoftware.c pp
154

Error 4 error C2065: 'CGeneric' : undeclared identifier y:\cpp\tests\te st
writing scalable software generic math\version
0.01\testwritin gscalablesoftwa re\testwritings calablesoftware \testwritingsca lablesoftware.c pp
157

Error 5 error C2065: 'AGeneric' : undeclared identifier y:\cpp\tests\te st
writing scalable software generic math\version
0.01\testwritin gscalablesoftwa re\testwritings calablesoftware \testwritingsca lablesoftware.c pp
157

Error 6 error C2065: 'BGeneric' : undeclared identifier y:\cpp\tests\te st
writing scalable software generic math\version
0.01\testwritin gscalablesoftwa re\testwritings calablesoftware \testwritingsca lablesoftware.c pp
157

How to solve the remaining issue's ?

Bye,
Skybuck.

[Ron Natalie]

MooseFET wrote:

On Aug 30, 6:02 am, Ron Natalie <r...@spamcop.n etwrote:

>MooseFET wrote:

>>This statement is incorrect. C, C++, Borland Pascal and it
decendants, and just about every other language I can think of allow
you to declare a new type to be the same as a simple type, allow
conditional compiles, and allow include files. You don't need to have
two copies of the source code.

Incorrect. C and C++ certainly do not.

You claim the above and then go on to say the below:

> You can #define or typedef
something that appears to be a type but they aren't distinct types.

The "typedef" declares a new type.

No it does not. It makes an alias for an existing type. You can't
distinguish between the typedef and the original type either through
overloading or typeid or anything else.

[MooseFET]

On Aug 31, 3:13 pm, Ron Natalie <r...@spamcop.n etwrote:

MooseFET wrote:

On Aug 30, 6:02 am, Ron Natalie <r...@spamcop.n etwrote:

MooseFET wrote:

>This statement is incorrect. C, C++, Borland Pascal and it
decendants, and just about every other language I can think of allow
you to declare a new type to be the same as a simple type, allow
conditional compiles, and allow include files. You don't need to have
two copies of the source code.
Incorrect. C and C++ certainly do not.

You claim the above and then go on to say the below:

You can #define or typedef
something that appears to be a type but they aren't distinct types.

The "typedef" declares a new type.

No it does not.

Yes it does in all the ways tha matter to the argument with Skybuck.
It causes a new name to be associated with a type. This makes it a
declaration of a type. Just because C doesn't do as strict of type
checking as some other languages doesn't make it not a declare of a
type. After the typedef has been done there is a new symbol that is a
type.

[Frithiof Andreas Jensen]

"David Brown" <da***@westcont rol.removethisb it.comskrev i en meddelelse
news:46******** **************@ news.wineasy.se ...

If you learn to use Usenet properly before trying to post this stuff, it
would be a lot easier to get you back on the path of sane software
development. It's not worth spending time answering you if you can't
write questions or comments that make sense.

It's this particular troll's mode of operation. News2020 was more fun.

>

[Frithiof Andreas Jensen]

"Frederick Williams" <"Frederick Williams"@antis pamhotmail.co.u k.invalid>
skrev i en meddelelse
news:46******** *******@antispa mhotmail.co.uk. invalid...

Skybuck Flying wrote:

>>
Hello,

This morning I had an idea ...

I hope that this doesn't sound impolite, but why are you posting to
sci.electronics .design and alt.math?

....because he knows that there are always a few people in
'sci.electronic s.design' that will take the bait!

[Bo Persson]

MooseFET wrote:
:: On Aug 31, 3:13 pm, Ron Natalie <r...@spamcop.n etwrote:
::: MooseFET wrote:
:::: On Aug 30, 6:02 am, Ron Natalie <r...@spamcop.n etwrote:
::::: MooseFET wrote:
:::
:::::: This statement is incorrect. C, C++, Borland Pascal and it
:::::: decendants, and just about every other language I can think of
:::::: allow you to declare a new type to be the same as a simple
:::::: type, allow conditional compiles, and allow include files.
:::::: You don't need to have two copies of the source code.
::::: Incorrect. C and C++ certainly do not.
:::
:::: You claim the above and then go on to say the below:
:::
::::: You can #define or typedef
::::: something that appears to be a type but they aren't distinct
::::: types.
:::
:::: The "typedef" declares a new type.
:::
::: No it does not.
::
:: Yes it does in all the ways tha matter to the argument with
:: Skybuck. It causes a new name to be associated with a type. This
:: makes it a declaration of a type. Just because C doesn't do as
:: strict of type checking as some other languages doesn't make it
:: not a declare of a type. After the typedef has been done there is
:: a new symbol that is a type.

We don't care much about how Skybuck defines a "new type".

After the typedef there is a new symbol that is the name of the type.
The type, however, is exactly the same as it was before the typedef.
It has just got a "nickname", or an alias.
typedef Skybuck Bucky;

doesn't create a new person!

Bo Persson

[JosephKK]

Skybuck Flying sp**@hotmail.co m posted to sci.electronics .design:

>
"David Brown" <da***@westcont rol.removethisb it.comwrote in message
news:46******** **************@ news.wineasy.se ...

>Skybuck Flying wrote:

>>"David Brown" <da***@westcont rol.removethisb it.comwrote in
message news:46******** *************** @news.wineasy.s e...
Skybuck Flying wrote:
There is definetly a speed difference especially for mul and div
for the modes I described.
>
Why do I have to choose the data type ?
>
Why can't the program choose the data type at runtime ?
>
If *you* are writing the program, *you* should know what sort of
data is
stored in each variable. *You* can then tell the compiler by
choosing
an appropriate data type. Is that so hard to grasp? It is up to
*you* to figure out that what limits there will be on the size of
the data you are using, and therefore pick 32-bit or 64-bit (or
whatever) integers
for your program. If you think there could be large variations
in the sizes, then either use a data type that will certainly be
big enough, or pick one with no arbitrary limit (there are
multiple precision integer libraries available for most
languages) , or use a dynamically typed language.

Well that clearly sucks.

The world is not completely 64 bit, The world is not statis it
fluctuates.

Sometimes the program only needs 32 bits, sometimes 64 bits.

Always choosing 64 bits would hurt performance LOL.

So if your program needs 32 bits, use 32 bits. If it needs 64
bits, use 64 bits.

Yes very simply statement.

Achieving this in a scalable way is what this thread is all about.

Re-writing code, or writing double code, or even using multiple
libraries is not really what this is about.

It's nearly impossible to achieve without hurting performance. Only
solutions might be c++ templates or generics, not even sure how easy
it would be to switch between two generated class at runtime.

Bye,
Skybuck.

Can't speak for other libraries but the integer and floating point
routines GCC C++ libraries are written as templates. Just don't
expect to change the CPU ALU mode on the fly. (at least not on
x86_64, PPC, MIPS or SPARC architectures.)

[JosephKK]

Skybuck Flying sp**@hotmail.co m posted to sci.electronics .design:

>
"Stephen Sprunk" <st*****@sprunk .orgwrote in message
news:46******** *************** @free.teranews. com...

>"Skybuck Flying" <sp**@hotmail.c omwrote in message
news:fb******* ***@news5.zwoll 1.ov.home.nl...

>>The world is not completely 64 bit, The world is not statis it
fluctuates.

Sometimes the program only needs 32 bits, sometimes 64 bits.

Always choosing 64 bits would hurt performance LOL.

Not if you have a 64-bit machine; even if you're using a 32-bit
machine, emulating 64-bit operations s will hurts performance less
than trying to detect the appropriate choice and then act on that
information.

For addition and subtraction probably.

For multiple and division some performance could be reduced for 32
bits but would still be faster than simulating it.

Whatever the case maybe.

The point is the detection is the overhead if cpu can do the
detection that overhead might disappear ! ;) :)

Bye,
Skybuck.

Precisely why we use typing and let the compiler do it. It moves the
overhead of the detection clear out of the running program.

[Skybuck Flying]

You have valid points.

Just because an if statement/switch to 32 bit code proved faster on my
system and the simple test program doesn't have to mean it will always be
faster, or always be faster on other chips.

I am pretty much done investigating this issue.

I am now convinced extending the code with int64's is ok.

And I will do it only at those places where it's absolutely necessary, the
rest will remain 32 bits.

So current code base is being converted/upgrade to a mix of 32 bit and 64
bit numbers.

Haven't look at the compare statements for 64 bits and copy statements,
there some more overhead.

Some new algorithm parts to cope with 64 bits as well, so program will
probably be a bit slower anyway.

It's the price to pay lol ;)

Bye,
Skybuck.

[Skybuck Flying]

Good get lost.

Bye,
Skybuck.

"Frank Birbacher" <bl************ @gmx.netwrote in message
news:5j******** ***@mid.dfncis. de...

Skybuck Flying schrieb:

>Give me wings bitch ! =D

Time to ban you.

Frank

[Miguel Guedes]

ChairmanOfTheBo red wrote:

Gee... Look! The SkyTard is back, and he even answered his own post
seven times!

What are you on? He wouldn't be the SkyTard otherwise!