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...
TYPE myType
x%
INLINE
int y;
ENDINLINE
FUNCTION blah:
self.x% = 1
INLINE
this->y = 2;
ENDINLINE
ENDFUNCTION
ENDTYPE
-------------------------------------------------------------------------------
Error:
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"
/* ---- 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"
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;
}
};
I believe Gernot has said that INLINE shouldn't be used within a TYPE - in which case the compiler should report an error.
Ah, I never spotted that one. Thanks for the info.
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.
Really just a bit nosey, but how does GLB handle operators when it comes to types?
Ha, or how about giving us the ability to overload the operators for TYPES and program our own behavior!
In C#:
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:
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:
OPERATOR AS CustomType: '+', c1 AS CustomType, c2 AS CustomType
Example:
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
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 (:noggin:)
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.
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! :noggin: