[fpc-devel] Macro Processing

[ik]

On Sun, May 15, 2011 at 21:22, Joerg Schuelke <joerg.schuelke at gmx.de> wrote:

> Am Sun, 15 May 2011 20:06:02 +0200
> schrieb Jonas Maebe <jonas.maebe at 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 at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20110516/4850baba/attachment.html>