Compiler problem

[bigsofty]

Not really a bug but a real problem for mixing C types with GLB types...

Hi,

There is a small problem with GLB that stops you using custom C types within glbasics own types. The compiler does not seem to copy across in-line type definitions into its own header.

May I suggest that any inline code that is in a GLB type, that is between the TYPE and the first FUNCTION or ENDTYPE command be copied into the gpc_temp.h with the rest of the vars? Not too worried about operator support as C would be used to deal with these C types anyways.

This would allow for C types to be used in GLB types, making it much more flexible when trying to import types/headers.

This is just an example using the standard INT type...


-------------------------------------------------------------------------------

Example GLB code of the problem...

Code (glbasic) Select Expand

TYPE myType
x%
INLINE
int y;
ENDINLINE

FUNCTION blah:
self.x% = 1
INLINE
this->y = 2;
ENDINLINE 
ENDFUNCTION
ENDTYPE


-------------------------------------------------------------------------------

Error:

Code (glbasic) Select Expand

C:\Users\Dad\AppData\Local\Temp\glbasic\gpc_tempg.cpp: In member function `DGInt __GLBASIC__::myType::blah()':
C:\Users\Dad\AppData\Local\Temp\glbasic\gpc_tempg.cpp:87: error: 'class __GLBASIC__::myType' has no member named 'y'

-------------------------------------------------------------------------------

Above produces "gpc_tempg.cpp"

Code (glbasic) Select Expand

/* ---- INLINE ---- */

int y; <<<-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*   y has been left in the CPP file


/* ---- ENDINLINE ---- */
// ------------------------ //
DGInt myType::blah()
{
   __PPRegisterFunction
self.x = 1;

/* ---- INLINE ---- */

this->y = 2;


/* ---- ENDINLINE ---- */
return 0;
}


-------------------------------------------------------------------------------

Also "gpc_temp.h"

Code (glbasic) Select Expand

public:
DGNat x;
DGInt blah();
myType()
{
x= 0; <<<-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*    is here but my "y" int type is not :(
}
myType(const myType& _in_)
{*this = _in_;}
myType& operator=(const myType& _in_)
{
this->x = _in_.x;
return *this;
}
bool operator <(const myType& _in_)const
{
if(this->x < _in_.x) return true;
return false;
}
bool operator >(const myType& _in_)const
{
if(this->x > _in_.x) return true;
return false;
}
bool operator==(const myType& _in_)const
{
return (1
&& x == _in_.x
)?true:false;
}

};

[MrTAToad]

I believe Gernot has said that INLINE shouldn't be used within a TYPE - in which case the compiler should report an error.

[bigsofty]

Ah, I never spotted that one. Thanks for the info.

[Kitty Hello]

The problem is: You must also fix it in the = operator and the < operator. First one is very essential.
So... inline is sort of a no-go in types.

What are you trying to do in detail? Maybe there's a better way.

[bigsofty]

Really just a bit nosey, but how does GLB handle operators when it comes to types?

[Slydog]

Ha, or how about giving us the ability to overload the operators for TYPES and program our own behavior!

In C#:

Code (glbasic) Select Expand

public struct CustomType  {
    public int real;
    public int imaginary;

    public static CustomType operator +(CustomType c1, CustomType c2)  {
        return new CustomType(c1.real + c2.real, c1.imaginary + c2.imaginary);
    }
}


In GLB:

Code (glbasic) Select Expand

TYPE CustomType
    real%
    imaginary%

    OPERATOR: '+', c1 AS CustomType, c2 AS CustomType
        LOCAL result AS CustomType
        result.real = c1.real + c2.real
        result.imaginary = c1.imaginary + c2.imaginary
        RETURN result
    ENDOPERATOR
ENDTYPE


Kind of only kidding!  If TYPES get converted to C classes when compiling, this may be doable, otherwise, wishful thinking!

[Edit] The return type would be implied to be the same as the TYPE, but it may be more proper to do this:

Code (glbasic) Select Expand

    OPERATOR AS CustomType: '+', c1 AS CustomType, c2 AS CustomType
Example:

Code (glbasic) Select Expand

LOCAL num1 AS CustomType
LOCAL num2 AS CustomType
LOCAL result AS CustomType
num1.real = 12; num1.imaginary = -11
num1.real = 10; num1.imaginary = -9
result = num1 + num2

[hardyx]

Operators in C++ are a nightmare, because they are prone to errors in complex programs. Newer languages like Java and C# don't have operator definition. You can use methods for this, like Add(a,b), easier to manage.
I want TYPEs inheritance much more than operators, but I know the Gernot answer ()

[Kitty Hello]

TYPEs get an automatic = and < operator. The < operator compares the member variables from top to botton of your implementation and thus effect the sorting order of SORTARRAY when you don't give a sorting function.

[bigsofty]

Interesting, I may have a play around with the type system but it sounds like quite a complex subject for a C++ noob like me!