mirror of
https://github.com/Ed94/gencpp.git
synced 2024-11-10 11:04:52 -08:00
Update gen.hpp and editor config
This commit is contained in:
parent
eb4f95b84e
commit
d93fd462e1
@ -18,3 +18,8 @@ indent_size = 4
|
|||||||
|
|
||||||
[*.hpp]
|
[*.hpp]
|
||||||
indent_style = tab
|
indent_style = tab
|
||||||
|
indent_size = 4
|
||||||
|
|
||||||
|
[*.ps1]
|
||||||
|
indent_style = tab
|
||||||
|
indent_size = 4
|
||||||
|
@ -6,31 +6,58 @@
|
|||||||
AST type checking supports only a small subset of c++.
|
AST type checking supports only a small subset of c++.
|
||||||
See the 'ECode' namespace and 'gen API' region to see what is supported.
|
See the 'ECode' namespace and 'gen API' region to see what is supported.
|
||||||
|
|
||||||
WHAT IS NOT PROVIDED:
|
### *WHAT IS NOT PROVIDED*
|
||||||
* Macro or template generation : This library is to avoid those, adding support for them
|
|
||||||
adds unnecessary complexity.
|
* Macro or template generation : This library is to avoid those, adding support for them adds unnecessary complexity.
|
||||||
If you desire define them outside the gen_time scopes.
|
If you desire define them outside the gen_time scopes.
|
||||||
|
|
||||||
* Modern c++ (STL library) features :
|
|
||||||
* Expression validation : Execution expressions are defined using the untyped string API.
|
* Expression validation : Execution expressions are defined using the untyped string API.
|
||||||
: There is no parse API for validating expression (possibly will add in the future)
|
There is no parse API for validating expression (possibly will add in the future)
|
||||||
|
|
||||||
* Complete file parser DSL : This isn't like the unreal header tool.
|
* Complete file parser DSL : This isn't like the unreal header tool.
|
||||||
Code injection to file or based off a file contents is not supported by the api.
|
Code injection to file or based off a file contents is not supported by the api.
|
||||||
However nothing is stopping you using the library for that purpose.
|
However nothing is stopping you using the library for that purpose.
|
||||||
|
* Modern c++ (STL library) features
|
||||||
|
|
||||||
|
As mentioned in [Usage](#Usage), the user is provided Code objects by calling the interface procedures to generate them or find existing matches.
|
||||||
|
|
||||||
There are four different of construction of Code ast's the library provides:
|
The AST is managed by the library and provided the user via its interface prodedures.
|
||||||
* Upfront construction
|
|
||||||
* Incremental construction
|
Notes:
|
||||||
* Parse construction
|
|
||||||
|
* The allocator definitions used are exposed to the user incase they want to dictate memory usage*
|
||||||
|
* ASTs are wrapped for the user in a Code struct which essentially a warpper for a AST* type.
|
||||||
|
* Both AST and Code have member symbols but their data layout is enforced to be POD types.
|
||||||
|
|
||||||
|
Data layout of AST struct:
|
||||||
|
|
||||||
|
CodeT Type;
|
||||||
|
bool Readonly;
|
||||||
|
AST* Parent;
|
||||||
|
string Name;
|
||||||
|
string Comment;
|
||||||
|
union {
|
||||||
|
array(AST*) Entries;
|
||||||
|
string Content;
|
||||||
|
};
|
||||||
|
|
||||||
|
*`CodeT` is a typedef for `ECode::Type` which is the type of the enum.*
|
||||||
|
|
||||||
|
ASTs can be set to readonly by calling Code's lock() member function.
|
||||||
|
Adding comments is always available even if the AST is set to readonly.
|
||||||
|
|
||||||
|
### There are four sets of interfaces for Code AST generation the library provides
|
||||||
|
|
||||||
|
* Upfront
|
||||||
|
* Incremental
|
||||||
|
* Parsing
|
||||||
* Untyped
|
* Untyped
|
||||||
|
|
||||||
Upfront Construction:
|
### Upfront Construction
|
||||||
|
|
||||||
All component ASTs must be previously constructed, and provided on creation of the code AST.
|
All component ASTs must be previously constructed, and provided on creation of the code AST.
|
||||||
The construction will fail and return InvalidCode otherwise.
|
The construction will fail and return InvalidCode otherwise.
|
||||||
|
|
||||||
API:
|
Interface :
|
||||||
|
|
||||||
* def_forward_decl
|
* def_forward_decl
|
||||||
* def_class
|
* def_class
|
||||||
* def_global_body
|
* def_global_body
|
||||||
@ -50,14 +77,19 @@
|
|||||||
* def_using
|
* def_using
|
||||||
* def_using_namespace
|
* def_using_namespace
|
||||||
|
|
||||||
Incremental construction:
|
### Incremental construction
|
||||||
|
|
||||||
A Code ast is provided but only completed upfront if all components are provided.
|
A Code ast is provided but only completed upfront if all components are provided.
|
||||||
Components are then added using the AST API for adding ASTs:
|
Components are then added using the AST API for adding ASTs:
|
||||||
|
|
||||||
* code.add( AST* ) // Adds AST with validation.
|
* code.add( AST* ) // Adds AST with validation.
|
||||||
* code.add_entry( AST* ) // Adds AST entry without validation.
|
* code.add_entry( AST* ) // Adds AST entry without validation.
|
||||||
* code.add_content( AST* ) // Adds AST string content without validation.
|
* code.add_content( AST* ) // Adds AST string content without validation.
|
||||||
|
|
||||||
API:
|
Code ASTs may be explictly validated at anytime using Code's check() member function.
|
||||||
|
|
||||||
|
Interface :
|
||||||
|
|
||||||
* make_forward_decl
|
* make_forward_decl
|
||||||
* make_class
|
* make_class
|
||||||
* make_global_body
|
* make_global_body
|
||||||
@ -72,10 +104,12 @@
|
|||||||
* make_using
|
* make_using
|
||||||
* make_using_namespace
|
* make_using_namespace
|
||||||
|
|
||||||
Parse construction:
|
### Parse construction
|
||||||
|
|
||||||
A string provided to the API is parsed for the intended language construct.
|
A string provided to the API is parsed for the intended language construct.
|
||||||
|
|
||||||
API:
|
Interface :
|
||||||
|
|
||||||
* parse_forward_decl
|
* parse_forward_decl
|
||||||
* parse_class
|
* parse_class
|
||||||
* parse_glboal_body
|
* parse_glboal_body
|
||||||
@ -93,10 +127,12 @@
|
|||||||
The parse API treats any execution scope definitions with no validation and are turned into untyped Code ASTs.
|
The parse API treats any execution scope definitions with no validation and are turned into untyped Code ASTs.
|
||||||
This includes the assignmetn of variables; due to the library not yet supporting c/c++ expression parsing.
|
This includes the assignmetn of variables; due to the library not yet supporting c/c++ expression parsing.
|
||||||
|
|
||||||
Untyped constructions:
|
### Untyped constructions
|
||||||
|
|
||||||
Code ASTs are constructed using unvalidated strings.
|
Code ASTs are constructed using unvalidated strings.
|
||||||
|
|
||||||
API:
|
Interface :
|
||||||
|
|
||||||
* untyped_str
|
* untyped_str
|
||||||
* untyped_fmt
|
* untyped_fmt
|
||||||
* untyped_token_fmt
|
* untyped_token_fmt
|
||||||
@ -105,8 +141,10 @@
|
|||||||
whatever context the content existed as an entry within.
|
whatever context the content existed as an entry within.
|
||||||
Even though thse are not validated from somewhat correct c/c++ syntax or components, it doesn't mean that
|
Even though thse are not validated from somewhat correct c/c++ syntax or components, it doesn't mean that
|
||||||
Untyped code can be added as any component of a Code AST:
|
Untyped code can be added as any component of a Code AST:
|
||||||
|
|
||||||
* Untyped code cannot have children, thus there cannot be recursive injection this way.
|
* Untyped code cannot have children, thus there cannot be recursive injection this way.
|
||||||
* Untyped code can only be a child of a parent of body AST, or for values of an assignment.
|
* Untyped code can only be a child of a parent of body AST, or for values of an assignment.
|
||||||
|
|
||||||
These restrictions help prevent abuse of untyped code to some extent.
|
These restrictions help prevent abuse of untyped code to some extent.
|
||||||
*/
|
*/
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user