[fpc-devel] Macro Processing

[ik]

On Mon, May 16, 2011 at 12:23, Joerg Schuelke <joerg.schuelke at gmx.de> wrote:

> Am Mon, 16 May 2011 11:16:39 +0300
> schrieb ik <idokan at gmail.com>:
>
> > 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.
>
> An macro represents the concept of automated text changing. Nothing
> else!!
>

On current FPC yes, on C it's more complicated then that.


>
> The answer was to use a logging facility? Maybe some kind of log
> server, where a pascal import unit is avail?
>
> Thats really very high level for that low level problem ;-(
>

It's not high level, it's the same level as you suggested, but already
existed and
not required to implement a new feature. You want to write your own logging
system,
then ok, please do, but why do I have to use Macro for that ? your example
of the
whole new logging system is very complicated and prune to have a lot of
problems
inside.




>
> This way you restrict the programmer!
>
> My debug system gives me what I want:
> - FILE info from build-in macro
> - FUNC info from build-in macro (patched by myself)
> - LINE info from build-in macro
> - the additional info I request
>

You can have the entire calling stack of an exception as well (without using
a macro) on FPC and I think also on Delphi.

However the FILE, can be used with TObject.UnitName and no Macro.
FUNC, You can get that information (including it's memory address) using
RTTI.
LINE, well using exception that you capture you can get that (remember the
calling stack feature ?).


>
> And now it is time to say that a real discussion is not possible if you
> always say: Yeah, you should not do that! Sounds like religion for me.
>

I was at Ruby IRC once and someone told people that they wish to use
Hungarian notation with Ruby.
Ruby's variables are all inherited from Kernel class, but can be changed
like Pascal's variant on run-time.
It's silly to use Hungarian notation on such type of variables, even if you
make them immutable.
If that person would recommend that the usage of that notation as a
programming guideline, then it will
have the same reaction like with the Macro discussion. I still do not
understand what are the benefits that
I will have, however I do understand what are the problems I can have (not
all).
Your example is not good enough to make me understand the need for Macro.



>
> I remember:
>                            **********
> An macro represents the concept of automated text changing. Nothing
> else!!
>                            **********
>
> If you want to criticize it, do it. And I do that to.
> Did you see that your argument of macros are a hack to do things which
> else not can be done in C, is easily turned around? Some things you do
> the only-true-pascal-way are only dirty hacks, to prevent the use of an
> macro. Because you do not have one.


In C you can create a callback and any type structure except of records and
unions
inside a function.
It's very unreadable and hard to to maintain or use.
because you are using the include system, you also have a lot of IFDEF that
allow things
to be included only once.
A lot of IFDEF are unmaintainable hacks btw. Not only on C but also with
Pascal.
The way you suggested to create a Macro is not so readable imho.

Why not to create something like:

*macro* Macro_Name(Param)
*begin*
*end*;

The Pascal way ? It's more readable. But then what do you gain with that
Macro ?


>
> For example the statement: Use a logging facility instead. If that
> would be true, the compiler would use one. You would use one. Everybody
> would use one, everytime.


There are unit tests tools, there are BDD based testing tools and more,
however
most of the time, I prefer to write my own tests that check if things are
what they should
or should not have.
I used to use a lot of asserts 10 years ago, now I prefer not to use them.
I used to like Exceptions, now I prefer to return error codes
The thing is that I have a choice. I can do things as I want. but even my
"hacks" are
maintainable and readable, you just need to understand the logic of the
library and
things are easy to use. With Macro you do not have that. Each macro have
it's own
logic, and it's own idea, and it's own style. See remember the list above ?
you can
have the line, unit etc name without using a Macro.
You can have logging system that you prefer to have without Macro. Even the
one
you suggested.


> But no, we mess around with that writeln thing and comments. Do not say
> you did not, you did never.
>

Sure I do, and I use many time something like this:

procedure toLog(const S : String);
{$IFDEF DEBUG}
   ....
{$ENDIF}
end;

It's not a hack but a choice to insert things to log.
I can also create something like this:

procedure toLog(debug_level : TDebugLevel; const S : String);
{$IFDEF DEBUG}
   if debug_level <= current_debug_level then
    writeln(debug_to_str(debug_level), ' [', DateTimeToStr(now) ,'] ', s);
{$ENDIF}
end;

There are so many ways to implement what you ask for without macro.
So again, why do I need a macro for ?
What are the Pro's that makes it better to be used then the cons ?



> Regards
>        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/8d46c0de/attachment.html>