On Sun, May 15, 2011 at 21:22, Joerg Schuelke <joerg.schue...@gmx.de> wrote:
> Am Sun, 15 May 2011 20:06:02 +0200 > schrieb Jonas Maebe <jonas.ma...@elis.ugent.be>: > > > Those three ways also have data overhead, because you have to store > > the string representation somewhere. Whether this initialised data is > > part of a predefined format called "RTTI" or not does not change that. > > Good point, but sorry, this is an proof that the macro approach is more > general! > > The RTTI feature can the data only give in one format, say it delivers > them as pchar to you. And I have shortstrings in my list. > The format the data is retrieved by the rtti decides how I have to > store it if you want to prevent the double storage of the data. > Using Macro or even RTTI for the debug example is actually not a good idea or example. Most programming libraries that offer logging tools, provide you with several type of section to log things, and only display the level you wish to display. You can easily create a TEventLog decedent with more debug sections and tell what level of that debug (if any at all) to be saved. One of the thing that I really hate about C is that it's way too low level. You have to take care of so many irrelevant things, that instead of fixing the ideas, you have so many features to help you hack them. C does not support returning content of a variable, so they passes the whole variable content instead. They do not have strings, so you have pointers of char, or array of chars. You can not know if the declaration of char is for "bytes" or for literal (as real) chars. You do not have "inline" support, or override of functions, so macros are the way they do it. You can take a symbol in C and make it part of a macro. That's an ugly hack that makes more problems then solve them. I'm unfortunately wrie also in C when I need (and try not to need to do it), and I find it hard to work on code that others create. You find many callbacks decelerations inside the function that use them instead of typeof deceleration and you find a lot of hacks to do stuff. I also program in languages such as PHP, and Ruby, and I find that the Pascal way of variable deceleration much better in understanding, because I know that the variable is declared. On Ruby for example, even if you created the variable inside an if statement, it will be viewable to the entire function unlike C and others. Why do I mention it ? because on C and PHP you see many bugs because of that "inline variable" feature. On PHP if you write once "tomatow" and once "tomato" they both valid, even though that the original variable is tomatow, so you will have null content for it and a big headack on it. On C, the preprocessor will stop you at time. On Ruby, it will be like with Pascal and C, the interpretor will not allow you to work. The Go language of Google for example decided that the Pascal way is more safe then the C way on this. So what that I'm trying to say is that Macro in C and C++ are there as a hack to do things you can not do properly in any other way. And I can not find any real reason for using it in Pascal. Remember that it's way too easy to missus a feature, you see it all of the time on most programming languages. Pascal is better because it takes readability over hacks. You can still create unreadable with Pascal, but it's harder to do it. > > Jörg > Ido > _______________________________________________ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel >
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel