I noticed that g++ is rather "free" in choice of what compiler settings to enable and what not. For example, the success of disabling RTTI with -fno-rtti does also depend on what's used in the sourcecode. I couldn't disable it with "virtual" keywords in it, just as test. Sometimes, it is convenient to force specific classes keep an interface for consistency reasons. This shouldn't be something too hurtful for the compiler to check whether a non-rtti class has defined some of it's interface methods. However, there doesn't seem to be a way to force the class bevahing so without including RTTI functions. Again, something annoying you need to manage by yourself. I like to use templates in a way most Java programmers I know like to use RTTI-based OOP. If you want to pass an object that can have a different implementations (take STL containers for example) but all of them use a single, always equal interface, you'd usually derive each implementation from a base class. You can't do this without RTTI, so since I rarely feel desire to change implementation during runtime or use them STL-like, I'm solving it by using a template parameter representing the class to use. This is a) statically know and does b) thus not use program-wide RTTI (elementary design principles ensured). The drawbacks: a) no obvious dynamic implementation possible (acceptable) and b) you can't specifiy an interface without using the virtual keyword.It's sad that they force you to do so, but I can't change it all. I need to find an alternative to OOP for my own language. As I already said, what you can do with OOP can always be done without, it's a question of much discipline you have and how comfortable it is to write an alternative in the language you've chosen. Personally, I believe it's a good way to explore template or macro-based programming in my own language.It probably results in more flexibility but also in more complex use of it. Anyway, programming more and more in C++ improves my concepts and builds a more and more clean vision of how and what to design with my own programming language. As I've seen in yesterday after a rather "forced" session of brainstorming combined with just too much anger about C++ inflexibility. I shouldn't try too hard to make it super multifunctional. I though too much about making an effecient bytecode instead of designing the language's specifications first. Don't optimize if it works great without, something I'm not always able to do. Usually cause I have too few goals to follow except elementary precepts. It's a bit of shame that I don't always direct my knowledge and abilities into something defined and set. Guess that'll happend later when I work a company or so, making the software they develop there. Maybe I'm just too strict with my personal projects. I can't really say this cause such high degree of effectivity is what I seek to archieve if I don't need to focus on deadlines, specifications or customer wishes. Nahh, fuck it. Everyone has it's kind of special personalities if it comes to personal projects. So there isn't much to worry about.

No comments: