Pages: [1]
  Print  
Author Topic: Allow me to use C++ in EDL  (Read 2378 times)
Offline (Unknown gender) TheExDeus
Posted on: November 23, 2014, 06:06:05 AM

Developer
Joined: Apr 2008
Posts: 1886

View Profile
I kind of hate GM datastructures. They are slower, harder to use and harder for compiler to optimize, because they are a wrapper. I would want to use STL containers, like vectors and lists. Can we finally make it happen? It's probably a parser thing again, but could it be possible in the short term to just add a language syntax to allow C++, like "{C++} { }". I know Josh already though about something like it, but I want to know how complicated would it be? Basically I want everything inside {C++} to NOT be parsed and taken as valid C++. Then every variable inside that scope to be temporary to the script (it should happen by default), so I can access it. Like for example:
Code: (C) [Select]
{C++}{
#include <vector>
using std::vector;

class myClass{
 double value;
};

vector<myClass> myVector;
for (auto &cl : myVector){
  cl.value = 3.1415;
}
 
}

//This is parsed EDL
for (unsigned int i=0; i<{C++}{myVector.size();} ++i){
  ds_grid_set(grid, i, 0, {C++}{myVector.value});
}

This is very ugly, but the point is that I plan to make a very high performing part in pure C++ and then only copy the results back to EDL for drawing.
This way we don't need to wait for a new parser for 10 years, but get a "patch" that could potentially be easy to implement.
Any ideas?
« Last Edit: November 23, 2014, 06:07:48 AM by TheExDeus » Logged
Offline (Unknown gender) sorlok_reaves
Reply #1 Posted on: November 23, 2014, 10:23:23 AM
Contributor
Joined: Dec 2013
Posts: 261

View Profile
I don't have an exact answer on this, but I have put some thought into it in the past. My thought process went like this:
  • Making a single "file" parse as C++ is pretty easy. (By "file" I mean "event, script, or timeline moment"). We just turn the parser off for that file.
  • A bracketed syntax like you propose is harder, since we need to integrate it into the parser.
  • One of the main challenges of code like yours is organization. Where exactly would this go? In some object's create() method? It looks like the class definitions should go into their own "header-like" area, and the initialization and ds_grid_set() code would go into the actual code.

Despite the challenges, I really like the idea of mixing EDL and C++, because it allows us (me) to easily experiment with different parsers, or different game engine scripting languages.
Logged
Offline (Unknown gender) TheExDeus
Reply #2 Posted on: November 23, 2014, 12:51:56 PM

Developer
Joined: Apr 2008
Posts: 1886

View Profile
Yes, headers are the biggest problems. But you can put classes inside the .cpp file as well and it's valid. You wouldn't be able to use templates though (they are purely a header thing). My idea was that this is a script. So everything goes in one script resource, which I then call. The problem of not parsing a whole "file" is that you then can't actually access neither local or global variables (for which parser generates accessors). So you can't actually do anything in that code that can be used elsewhere in the program. That is why I suggest some syntax, that allows me to select which part is parsed and which is ignored. So I can run fast code in C++, then give result back to an instance via EDL.
Logged
Offline (Male) Josh @ Dreamland
Reply #3 Posted on: November 23, 2014, 01:35:56 PM

Prince of all Goldfish
Developer
Location: Ohio, United States
Joined: Feb 2008
Posts: 2934

View Profile Email
We used to do what you're suggesting, if you remember. There's no syntax checking that way. I can't even tell you if you've dropped a semicolon. But even then, including vector wasn't an option, because you're still writing code in an event function.

As far as "Making a single 'file' parse as C++," we still do that today! It's called "definitions," and you can modify it in the ENIGMA settings.  If you want a hot fix, how about helping me out and petitioning for a formal, instantiable definitions resource like I've been bugging Ism (and anyone else who enjoys doing Swing work) for since 2008? I have every intention of allowing raw C++ definitions by that mechanism even when EDL is actually a capable language. We'll also want EDL definitions, so  you have a place to put global EDL functions (kind of like a file full of static scripts).

So if the parser takes ten years, fine; do this now, have it just add C++ definitions, and when the parser's done, that's one less fucking thing I have to worry about.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) TheExDeus
Reply #4 Posted on: November 23, 2014, 03:16:30 PM

Developer
Joined: Apr 2008
Posts: 1886

View Profile
But if I put the code in C++ definitions, then how can I access local or global variables for instances? Like how exactly can I use C++ definitions together with EDL? I guess I can use ds_ functions in the definitions, so I can just make a function that returns a data structure. That is the only thing that comes to mind.

Quote
But even then, including vector wasn't an option, because you're still writing code in an event function.
You mean we can't use vectors is because #include would end up in the function? If so, then headers and "using namespace" stuff can be put in the current C++ definitions file. When that is done, then I don't see why the vector wouldn't work inside a script.
Logged
Offline (Male) Josh @ Dreamland
Reply #5 Posted on: November 23, 2014, 09:54:55 PM

Prince of all Goldfish
Developer
Location: Ohio, United States
Joined: Feb 2008
Posts: 2934

View Profile Email
I'm sorry, I couldn't hear you over how great the code in write_object_data.cpp is.

Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) DarkAceZ
Reply #6 Posted on: November 23, 2014, 09:59:50 PM

Member
Location: United States
Joined: Dec 2011
Posts: 76

View Profile
I'm sorry, I couldn't hear you over how great the code in write_object_data.cpp is.
How can you compete with that, Josh? Why are you still even here? (I bet it's to suggest new shitty site layouts)
Logged
My Goodness! Is it 4:30? I'm supposed to be having a back, sack and crack!

[edit]
Offline (Unknown gender) TheExDeus
Reply #7 Posted on: November 24, 2014, 06:20:15 AM

Developer
Joined: Apr 2008
Posts: 1886

View Profile
Josh wrote at least half of the code. Probably more.
Logged
Offline (Male) Goombert
Reply #8 Posted on: November 24, 2014, 02:55:00 PM

Contributor
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 2992

View Profile
Quote from: Dreamfag
I'm sorry, I couldn't hear you over how great the code in write_object_data.cpp is.
Quote from: Babybitch
How can you compete with that, Josh? Why are you still even here? (I bet it's to suggest new shitty site layouts)

In all fairness, mine at least works and does inheritance, Josh's doesn't even work yet.
https://github.com/enigma-dev/enigma-dev/pull/825
Logged
Welcome to ENIGMO, the game engine built by fucking aliens.

Offline (Unknown gender) Darkstar2
Reply #9 Posted on: December 01, 2014, 05:12:40 PM
Member
Joined: Jan 2014
Posts: 1213

View Profile Email
Very much agree with you Harri in fact I have a few posts here I made a while ago about some stuff I wanted to do but was told I could not because of the stl containers and certain things not possible in EDL.....  I love your idea to embed native C++ in EDL, bypassing parsing.
There are good uses to this for certain application/games where GM structure is just inefficient.....mind you it's probably efficient for most people using GM lol :P  but there are certain things I want to do that push the limits, and require optimal speed in file and data handling......and short of writing your own C++ function and integrating it into the ENIGMA engine, this would allow proprietary C++ code outside the engine....


Logged
Offline (Unknown gender) TheExDeus
Reply #10 Posted on: December 01, 2014, 06:13:13 PM

Developer
Joined: Apr 2008
Posts: 1886

View Profile
Clearly this feature is way to complicated for the current parser. There is also a possibility this might not work for some reason (something Josh spoke about, but was not willing to elaborate).
Logged
Offline (Male) Josh @ Dreamland
Reply #11 Posted on: December 02, 2014, 12:35:15 AM

Prince of all Goldfish
Developer
Location: Ohio, United States
Joined: Feb 2008
Posts: 2934

View Profile Email
You'd have to access those objects the same way you access them in other C++ functions. Ie, using instance_event_iterator.

The main reason you can't use vector with the current compiler is that it's terrible at coercing types. It was always bad at it, but it's actually gotten worse over time. Originally, you could access vector like an array, but couldn't call functions because the type resolution wasn't good enough to get accurate function information from template types, so I never bothered coding checks for member function calls. I fixed the template types issue in JDI, but in the meantime, someone broke it to the point that it doesn't even realize anything in the code is not a var, anymore. No idea why. Don't feel like investigating.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) TheExDeus
Reply #12 Posted on: December 02, 2014, 04:21:32 AM

Developer
Joined: Apr 2008
Posts: 1886

View Profile
Quote
You'd have to access those objects the same way you access them in other C++ functions. Ie, using instance_event_iterator.
That is why I proposed an inline operator which just ignores parsing. So if I need to access an instance variable, I allow the parser to generate it, like so:
Code: [Select]
ds_grid_set(grid, i, 0, {C++}{myVector.value});So grid will turn into the correct accessor, while myVector.value will not be parsed and be valid C++.
Logged
Offline (Unknown gender) sorlok_reaves
Reply #13 Posted on: December 02, 2014, 08:21:40 AM
Contributor
Joined: Dec 2013
Posts: 261

View Profile
I think you'd also need:

Code: [Select]
{C++_instance}{std::vector<int>myVector;}
...where "C++_instance" means "put this in the object declaration for this object type. But what if you declare an integer? Then you'd need:

Code: [Select]
{C++_ctor}{my_var = 10;}
...where "C++_ctor" means "put this in the object's constructor". If you allocate memory, there's a strong argument for "C++ dtor" as well. Oh, and possibly "C++_header", which goes at the top of IDE_EDIT_objectdeclaration.h.

This is one way to do it "without any parsing". We could also parse the code and extract #include<> statements, removing the need for "C++_header"  ...but now we've gotten into parsing C++.

I think this is why everyone is hesitating on the issue ---there's no easy way to hack it in, and (for now) there's no way that's clearly the "right way" to do it.
Logged
Offline (Unknown gender) TheExDeus
Reply #14 Posted on: December 02, 2014, 10:15:39 AM

Developer
Joined: Apr 2008
Posts: 1886

View Profile
Quote
...where "C++_instance" means "put this in the object declaration for this object type. But what if you declare an integer? Then you'd need:
That is if I want to use those classes or types in several code snippets. I only required the vector<> to be defined inside one function (e.g. a script) and it can be deleted when the function ends. I don't need to declare in create and use in step. So in my case only {C++} would probably work just fine. So the whole idea was that in performance critical script, I can use pure C++, then only copy back the results for local instances. Look at my original code snippet, the myVector is not used outside of that code. It gets deleted when when the script ends. That is why I copy the values back into ds_grid.

If you need something more longer lasting you could use a global variable, but I guess globals are also defined in some declaration and they are not just globally scoped.
« Last Edit: December 02, 2014, 10:17:10 AM by TheExDeus » Logged
Pages: [1]
  Print