#include <math.h>

Previous topic - Next topic

bigsofty

Importing a small C header to GLB, the REQUIRE for this header works fine but the c header contains a #include for maths.h. ("Z:\Projects\GLBasic\map_test\Vector.h:131: error: `sin' was not declared in this scope")

My question is this, do I simply grab any old math.h from a GCC distro and stick it in GLB's Include directory(or beside the parent .h)?
Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)

MrTAToad

You could try :

Code (glbasic) Select
IMPORT "C" __stdcall double sin(double);

or inline :

Code (glbasic) Select
extern "C" __stdcall double sin(double);

bigsofty

#2
That's a good idea for a few commands but that was just one error unfortunately, there are lots of errors, GLB/GCC is complaining about other missing functions (sin, cos, atan etc). Math.h will only be used a child header for Vector.h too, in-line only at most.
Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)

XanthorXIII

Is this a linking issue? Technically Math.h only contains the headers and not the actual functions, those reside in libm.a. May require -lm flag when compiling.
Although my assumption is probably 99% wrong.

Owlcat has wise

bigsofty

Nope.. ("Z:\Projects\GLBasic\test\Vector.h:2:18: math.h: No such file or directory")

I could grab a math.h from GCC as there are no headers supplied with GLB?
Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)

Kitty Hello

search the forum for "headerpack". That's the headers I use.

XanthorXIII

Owlcat has wise

bigsofty

Many thanks all, that's (inline)compiled fine now, all I have to do now is interface the C with GLB!  :S

As a matter of interest, is this collection of headers kept up do date, with the current compiler version that GLB uses?
Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)

Kitty Hello

I update that eventually, yes.

bigsofty

Quote from: Kitty Hello on 2011-Jun-08
I update that eventually, yes.
I am sure this will do fine till then Gernot, thanks!  :good:
Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)

bigsofty

#10
Strange problem, when I compiled a function, within it using in-lined C, with my Vector.h defined C types it worked fine(#include was at top of listing) but when I copied the function into a type, it did not. I got scope errors and undefined types etc... just like the header was missing.

I then realised, when a function is placed within a type GLB takes all the types and puts them into a separate header file, away from my #include as part of the compilation process.

I needed a method for GLB to copy the in-lined #include with of the type (or "types", as I use the header with other types too) into GLBs own temp C header file, at compilation time.

I used this...

Code (glbasic) Select
TYPE dummy_header
INLINE
#include "vector.h";
ENDINLINE
ENDTYPE


...this forces a copy of #include into GLBs temp header C file. Its a bit uncomfortable but it works. You only need to define this once for multiple extended types too.

My question is this, not being a native C programmer, is there a single way to instruct C to use a header across all source files that I can in-line easily?
Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)

Kitty Hello

Um. No?
I mean - dude, now you're really making complicated stuff. Usually INLINE is used to wrap a bunch of functions to GLB and done. If you want your whole project in C++, why not write that and export a "int cpp_main()" function, only?

bigsofty

LOL, sry, I am really trying to get the one header (and all its types) to work within GLB but the closer I get the more C seems to appear.  :noggin:

I will probably hit a point where its simply not worth it though, its getting close now.

One thing, this is kinda your fault Gernot, now I can load C files into GLB projects, its a lot easier to mess around with C!  :D
Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)

MrTAToad

Problem is headers usually call other headers, which in turn define structures and whatnot...

You could, of course, write all your C stuff as a library and include it in a GLBasic program :)

bigsofty

#14
Yep, that's definitely a good option. The only annoying thing is, is that its 99.9999% working fine. If I stick to the old fashioned lib (no extended types) it should be OK for my needs. This is one of those 'handy' techniques that, if working, can prove to be very productive later. Something I wanted to achieve.

P.S. For anyone trying something similar, using the above hack you can use C types within GLB extended  types (only within functions though)...

E.G.

Code (glbasic) Select
TYPE myType
  x#
FUNCTION tst:
INLINE
Vec2 s = Vec2(10,20); // Vec2 is from Vector.h
ENDINLINE
ENDFUNCTION
ENDTYPE


...is fine.
Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)