Pure C code in QB64?

[SpriggsySpriggs]

I was curious if we could get an implementation in QB64 that would allow for pure C code in QB64 that would receive little to no translation. For instance:
$C
'insert pure c code here
$END C
If we could have C code that would be enclosed in quotes to allow for execution of pure code and bypass some of the issues that arise with QB64's translation into C then that would be amazing.
It might not be feasible. If so, then I understand. Might be something for QB64 v1.5 or 1.6 if it can be done? I'm not sure if anyone else has had this idea. I only thought of it because of @Unseen Machine 's post here https://www.qb64.org/forum/index.php?topic=2737.0 where he mentioned he was having compilation issues using asm from C. It looked like the translation from QB64 caused the issue.

[FellippeHeitor]

It has been under discussion for a good while, with the founding father of QB64 explicitly standing against it.

I was recently asked for guidelines about the process for contributing to QB64's source code/core functionality.

I am supportive of ANY change to QB64 which:
1) Will not break existing functionality in any way
2) Is multi-platform compatible
3) Does not grossly/negatively interfere with the QB64 programming experience
4) Does not contain any known bugs
5) Is/Will be clearly documented so others can use it (either on the forum or in the WIKI)
6) Does not allow mixed language/CPU specific command integration (such as inline C++ code, assembly, etc)
7) Is not malicious in any way

Does your idea meet all of the above criteria? If so your next steps are...
1) Code it! (make sure you note any files you change and where for your own reference)
2) Submit it.
i) If you are a QB64 repository contributor, grab the latest version of the repository, make your changes and push them (I and the community will test the next dirty build [which is automatically created from the repository] and as long as it works, job done!) or...
ii) Become a repository contributor by asking me on the Q&A forum

Everybody has a different opinion about what QB64 can/should be. But unless we make it what the individuals in our community want it to be then we all lose. So even if we personally don't want/need things like...
- Path finding
- Sorting
- A suite of string commands
- University-degree level math operations
- A circle fill command
- ODBC functionality
- OOP
- Name spaces
- Option explicit
- Web server interoperability
- Nullable/Reference types
...someone does.

My new philosophy is to let QB64 be what the community want it to be. Even if we end up with 1000s of commands that barely get used by the majority, it is better than QB64 not being used at all. And if someone implements something incredibly stupid/unnecessary (such as a _HELLOWORLD command) the beauty of a repository is that it can always be rolled back later. Because of this philosophy, you won't see me standing in the way of any changes.

Personally, I lack the ability. Let's hear from the community and my fellow developers.

[Unseen Machine]

Does not allow mixed language/CPU specific command integration (such as inline C++ code, assembly, etc)

With the advent of declare library this was made null and void...but if we have a set of variables that matched the ones that C++ (is it gcc?) uses so Declare Library is actually usable without have to make wrappers then i'd support that as it negates the need to write in two languages...

As for me i'd rather see type definitions that support arrays (i'm using _MEM to substitute this but it's a pain in the bum!) and the linking to external libraries bug fixed way before we even get to this C/C++ stuff...

Unseen

[SpriggsySpriggs]

As for me i'd rather see type definitions that support arrays

That would be quite awesome.

[bplus]

@FellippeHeitor Interesting quote from Galleon, thanks :)

Personally, I lack the ability. Let's hear from the community and my fellow developers.

I wonder who would be more helpful (or is this just dumb) a C coder or a C++ coder?

I might know a C coder who might help...

[TempodiBasic]

@Fellippe
Thanks to remember me that! Now I remember that I had read this post some times ago!

about

Everybody has a different opinion about what QB64 can/should be. But unless we make it what the individuals in our community want it to be then we all lose. So even if we personally don't want/need things like...
- Path finding
- Sorting
- A suite of string commands
- University-degree level math operations
- A circle fill command
- ODBC functionality
- OOP
- Name spaces
- Option explicit
- Web server interoperability
- Nullable/Reference types
...someone does.

My new philosophy is to let QB64 be what the community want it to be. Even if we end up with 1000s of commands that barely get used by the majority, it is better than QB64 not being used at all.

LOL there are many requests that are deprecated by the point of view of  Galleon. Maybe  he thought that there are not only the professional coders as user of QB64 but more beginners that find useful such implementation into QB64 because it is not simple for beginner do these stuff byself!
And yes I am the first of those beginners!

PS to be impartial I can affirm that no ASM inline, no C/C++ inline,  no C# inline, YES BASIC inline. :-))

[_vince]

I think a $C...END $C being officially part of the language would really spice up the 'Programs' section ;-)

[TempodiBasic]

I have of experience of mixed language of programming,
so please be gentle with my dummy questions.

What is written in the C section (or ASM section or C++ section) is at all own risk of coder or IDE  that must support syntax check?

Is it possible to use an include file with the stranger code (C/C++/ASM)?

Thanks to read

[Unseen Machine]

Well, i figured i'd see what it looked like and even at a most simple level I hate the way it looks! I've got no problem keeping my C/C++ code in .h files (once the linking problem is fixed i'll be a happy bunny).

Here's what i threw together (if we had the cross comaptabilty this would render a sphere...)

'// Pure C Code allowed inside a Qb64 program would look like this and I am not a fan!

SCREEN _NEWIMAGE(800, 600, 32)


DO
 _LIMIT 30

 _DISPLAY
LOOP UNTIL INKEY$ = CHR$(27) '// Loop until ESC is pressed


SUB _GL

   gdk_gl_sphere 100,50,50,false
END SUB



$CStart

#include <glu.h> // Include GL Utilities library

inline void GDK_GL_SPHERE(double Rad, int Slices, int Stacks, int Texture)
{
 GLUquadricObj *x = gluNewQuadric();
 if (Texture == 1 || Texture == -1)
  gluQuadricTexture(x, GL_TRUE);
 gluSphere(x, Rad, Slices, Stacks);
}

$CEnd

Unseen

[SMcNeill]

Well, i figured i'd see what it looked like and even at a most simple level I hate the way it looks! I've got no problem keeping my C/C++ code in .h files (once the linking problem is fixed i'll be a happy bunny).

Here's what i threw together (if we had the cross comaptabilty this would render a sphere...)

Unseen

Only thing I think which might be an issue with that approach is matching variable types.  Even with streamline C, you'd probably need a DECLARE LIBRARY to set the types in QB64.

DECLARE LIBRARY
    SUB GDK_GK_SPHERE (BYVAL Rad AS DOUBLE, BYVAL Slices AS LONG, BYVAL Stacks AS LONG, BYVAL Texture AS LONG)
END DECLARE

[Unseen Machine]

Only thing I think which might be an issue with that approach is matching variable types.  Even with streamline C, you'd probably need a DECLARE LIBRARY to set the types in QB64.

Thats almost exactly how i implemented it (great minds think alike eh!?) . It's the function i use for sky sphere's in GDK_GL so i know it works when it's in a .h file.

Code: QB64: [Select]

1. SUB LIBRARY_DEC
2. DECLARE LIBRARY "GDK_GL\GDK_GL"
3. '// SHAPES LIBRARY - GLU_Quadrics
4.     SUB GDK_GL_SPHERE (BYVAL Radius#, BYVAL Slices&, BYVAL Stacks&, BYVAL Texture&)
5. END DECLARE
6. END SUB