User forums > Using Code::Blocks

Automaticlly building all files in folder without a custom makefile?

<< < (3/4) > >>

mirai:
So you're trying to attach some kind of RTTI to unmanaged code to access object fields by name (string parameter). Am I right?

Hmm... Why don't you #include generated .cpp into manually created .cpp corresponding to .h file?
Changing one file at a time won't turn into a complete rebuild of the project... however, forgetting a file is still possible :(

Eriond:
Yeah, creating some RTTI as well as some context about that particular class is the goal.

I'd like to avoid changing the actual .h files (or for that matter, any files that the user will generally be looking at) as much as possible; I'd like to make the system completely transparent to the programmer, though including things in the individual header files is one thing I hadn't considered. I suppose that would indeed be a very acceptable way of including the file with minimum fuss. I'll try it out, and see how I like the feel of it. Thanks!

mirai:
OK :D

By the way, I would suggest to try another really different approach as an alternative to scripting. Here's the idea: every manged field should be an object of a class which constructor registers it in a "database", performs initialization, connects all necessary pointers, tunes callbacks, etc.; managed field classes may be just envelope classes for basic types without any real overhead. A database then should be a static member of the base class or even a regular procedural interface providing named access to registered entities. This way you probably won't have to generate anything by scripts or macros at all. But if you already have a lot of working code... taking this approach may become a problem.

Eriond:
It's an interesting idea, but as you say, I've already got a ton of code that uses the system and supports it :P. Also, how would the managed fields get their stringified names, without the use of macros? I didn't think there was any way to actually get the name of any member without using macros or actually typing in the name of each and every single member variable twice. Plus, there's a bunch of other things that automatically get done in the class generation script that you can't really do (I think!) with the perl, like local enum transformations (forward and back) from strings to ints, etc..
 
Though, I will admit, for some reason, I never really considered using templates and classes like that to make the managed fields. It's definitely something to think about!  :D

mirai:
Hmm... macros might be inevitable :? However, some things can be resolved with initializers, I suppose. About typing names twice... those names may be different - internal and public name - internal name may have a prefix like "m_" (member) or be an abbreviation ("pos" for position, "dir" for direction) or contain some characters to look different to some other unmanaged field or comply with coding style, while public names may be longer and more self-descriptive and comply with configuration style. Registering a managed field in a database establishes certain mapping between internal (private) names with their style and external (public) names with their probably different style. Macros won't be very helpful in this case.


--- Quote from: Eriond on June 23, 2011, 04:47:04 am ---Plus, there's a bunch of other things that automatically get done in the class generation script that you can't really do (I think!) with the perl, like local enum transformations (forward and back) from strings to ints, etc..
--- End quote ---
Can you tell more about this part?

Navigation

[0] Message Index

[#] Next page

[*] Previous page