ed/gencpp
1
0
Fork 0
mirror of https://github.com/Ed94/gencpp.git synced 2024-11-10 02:54:53 -08:00
Code Issues Packages Projects Releases Wiki Activity

Didn't push everything.

Browse Source
This commit is contained in:
Edward R. Gonzalez 2023-04-08 01:43:37 -04:00
parent 5bdebee404
commit 1ba187e3d5
1 changed files with 10 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
Readme.md
View File

@ -458,7 +458,16 @@ The drawback naturally is generation functions, at face value, are harder to gra
Thus a rule of thumb is if its a simple definition you can get away with just the preprocessor `#define`, or if the templates being used don't break the debugger or your compile times, this is most likely not needed. Thus a rule of thumb is if its a simple definition you can get away with just the preprocessor `#define`, or if the templates being used don't break the debugger or your compile times, this is most likely not needed.
However, if the code being generated becomes complex, or from a datatable or database, this will be easier to deal with. However, if:
* The code being generated becomes complex
* You enjoy actually *seeing* the generated code instead of just the error symbols or the pdb symbols.
* You value your debugging expereince, and would like to debug your metaprogram, without having to step through the debug version of the compiler (if you even can)
* You want to roll your own runtime reflection system
* You want to maintain a series of libraries for internal use, but don't want to deal with manaual merging as often when they update.
* Want to create tailored headers for your code or for your libraries since you usually don't need the majority of the code within them.
Then this might help you boostrap a toolset todo so.
# TODO: # TODO: