Am Mon, 16 May 2011 13:01:39 +0300
schrieb ik ido...@gmail.com:
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 ?
-Doing it this way would not be acceptable by any developer,
Am Mon, 16 May 2011 15:35:24 +0100
schrieb Martin f...@mfriebe.de:
{$EXPAND ProcFoo(1)}
// the code in thr try finally block
{$EXPAND ProcFooEnd}
I can see that happen very easy?
And there we are, Pascal would be down to where C is now.
There is no answer for that, you know. But you can
Am Tue, 17 May 2011 12:59:57 +0100
schrieb Martin f...@mfriebe.de:
Based on this. The question is does the benefits really outweigh the
cost ?
Of course not. The much writing shows there is only Hans-Peter possibly
for a try. I thought that some of the reasons where only educational ;-)
Am Tue, 17 May 2011 13:38:35 +0100
schrieb Martin f...@mfriebe.de:
Going for educational.. or theoretical...
You understand, it is not even easy for someone to have a need ore a
valid use for an macro, after 30 years without? Then crutch macro
support that fpc has, makes that not better. It
Am Sun, 15 May 2011 13:26:03 +0200 (CEST)
schrieb Daniël Mantione daniel.manti...@freepascal.org:
Feel free to come up with examples and convince us. They need to be
examples of code that is much more awkward to write without macro's.
We extend the small enumeration example:
Think of it, as
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
Am Mon, 16 May 2011 11:16:39 +0300
schrieb ik ido...@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
Am Mon, 16 May 2011 08:37:12 +0200
schrieb Florian Klaempfl flor...@freepascal.org:
You still need to keep infoarr and callenum in sync so simple macros
are only half of a solution in this case.
Thats true, I hate macros too. So I did it not the hack way. It was not
my object to show how you
Am Mon, 16 May 2011 11:11:39 +0100
schrieb Martin f...@mfriebe.de:
Lots of code is written n teams. ...
...
Making the feature available, forces others to deal with it.
Yes, I agree. But if you really doing team work, the team should
find a common way of coding. Look at some piece of very
Am Mon, 16 May 2011 13:01:39 +0300
schrieb ik ido...@gmail.com:
procedure toLog(const S : String); --
{$IFDEF DEBUG} |
|
{$ENDIF} |
end; |
Am Mon, 16 May 2011 08:37:12 +0200
schrieb Florian Klaempfl flor...@freepascal.org:
You still need to keep infoarr and callenum in sync so simple macros
are only half of a solution in this case.
If it should be done, maybe this way:
But, I have no clue about macro writing
Thats a
Am Mon, 16 May 2011 11:11:39 +0100
schrieb Martin f...@mfriebe.de:
2) But a macro also weakens the fundamental concept of how a language
is defined. A macro allows you do define a new syntax. To create
something, ...
I do prefer not to make it possible to extend the language, thats why
the
Am Mon, 16 May 2011 14:07:54 +0100
schrieb Martin f...@mfriebe.de:
{$MyProc (Name) := procedure %Name%; begin}
...
{$Expand MyProc(Foo)} writeln(1); end;
Thats a point worth thinking about, but you say that it even can be done
today, do you think there is more harm extending the
Am Mon, 16 May 2011 14:36:29 +0100
schrieb Martin f...@mfriebe.de:
I have seen that in C, macros generating macros.
As the result, even if you knew you where looking at a macro, you had
no way to find where it was declared. Because the declaration did not
contain it's name (but
Am Mon, 16 May 2011 14:41:35 +0100
schrieb Martin f...@mfriebe.de:
The more support there is for macros, the more likely people will
start whole libraries of macros.
first just a lort of small harmless helpers. Then combinations there
of... it grows, and then it becomes cancer (grows to
Am Sat, 14 May 2011 20:46:30 +0200 (CEST)
schrieb Daniël Mantione daniel.manti...@freepascal.org:
Inlining is better that doing the same with macro's, so is the use of
str/val better than macro tricks.
Wherever you can!
If I do some low level system work, it is possibly better to do it with
a
Am Sun, 15 May 2011 13:26:03 +0200 (CEST)
schrieb Daniël Mantione daniel.manti...@freepascal.org:
Feel free to come up with examples and convince us. They need to be
examples of code that is much more awkward to write without macro's.
There are no examples. For one reason. If you program
Am Sun, 15 May 2011 00:30:38 +0200
schrieb Hans-Peter Diettrich drdiettri...@aol.com:
I see this point and it is one reason for me to think very careful
about: Is it possible to do it without touching the scanner?
Is the rest interesting enough to make it worth a further thinking.
If not,
Am Sat, 14 May 2011 01:23:08 +0200
schrieb Joerg Schuelke joerg.schue...@gmx.de:
A third one.
It is a further single and isolated solution to prevent the use of a
macro. How many of them are there around? A hundert, a thousand in 5
years?
I will explain what is the problem with this. If I
Am Sat, 14 May 2011 12:14:52 +0200
schrieb Florian Klämpfl flor...@freepascal.org:
Because a lot of code in the compiler is very old (remember, it was
started in 1993 using TP) and writestr for enums is new compare with
this time span. Nobody rewrote the code yet.
And it should not been
Am Sat, 14 May 2011 15:12:46 +0200
schrieb Florian Klaempfl flor...@freepascal.org:
Since the compiler uses classes, it uses rtti already heavily so I
miss the point.
OK, you need the RTTI for simple storing and recovering the informations
to ppu files or whatever, thats a point to use it.
Am Sat, 14 May 2011 14:36:33 +0200
schrieb Florian Klämpfl flor...@freepascal.org:
so any new feature
makes this worse without more people doing the dirty work of bug
fixing.
That's why I'am currently very carefull with new featuers.
I see this point and it is one reason for me to think
Am Sat, 14 May 2011 16:29:15 +0200 (CEST)
schrieb Daniël Mantione daniel.manti...@freepascal.org:
... will cause 52 bytes of RTTI data to be inserted in your
executable. Any do-it-yourself solution will consume more space.
Therefore the RTTI not only helps to keep the source code compact and
Am Sat, 14 May 2011 17:04:45 +0200
schrieb Joerg Schuelke joerg.schue...@gmx.de:
I repeat, I have really nothing against RTTI, but I state that it
comes from a high level language extension.
By the way this RTTI thing comes from the argument: Do not use a
macro, instead do it this way
Am Sat, 14 May 2011 17:38:27 +0200
schrieb Florian Klämpfl flor...@freepascal.org:
Am 14.05.2011 17:30, schrieb Joerg Schuelke:
Am Sat, 14 May 2011 17:04:45 +0200
schrieb Joerg Schuelke joerg.schue...@gmx.de:
I repeat, I have really nothing against RTTI, but I state that it
comes
The thoughts about further improvement of the macro capabilities of the
compiler are now so far along that I can post this paper. But it is not
that short, about three pages.
Why doing it? There are IDE Macros.
People do not use all the same IDE, some do not use any. The
IDE
Am Fri, 13 May 2011 11:25:36 +0200 (CEST)
schrieb Michael Van Canneyt mich...@freepascal.org:
In short: No, it is better to keep that particular box of pandora
closed.
None of the more modern languages implement macros, and this is for
good reason.
Pascal has always existed without
Am Fri, 13 May 2011 11:47:54 +0200
schrieb Florian Klaempfl flor...@freepascal.org:
procedure dp(const x : string;y : array of const);inline;
begin
dbgstr(x,y);
end;
Nothing is wrong with that. Except:
- the code will never vanish from the object file. I like it, to have
my
Am Fri, 13 May 2011 13:43:52 +0200 (CEST)
schrieb Michael Van Canneyt mich...@freepascal.org:
If I had my way, I would remove the existing ones alltogether.
The one use case they have in FPC sources could easily be remedied.
Thats a clear position. If there is no macro support at all, I would
Am Fri, 13 May 2011 12:11:06 +0200 (CEST)
schrieb Mattias Gaertner nc-gaert...@netcologne.de:
Compiler errors in macros are often confusing/misleading, because
the user does not see the expanded code. Same for debugger positions
and handling.
Macros can confuse other parsers. For example
Am Fri, 13 May 2011 14:05:43 +0200
schrieb Florian Klaempfl flor...@freepascal.org:
Extending dump_stack is imo a much better approach, it even doesn't
duplicated information already available in debugging info.
Thats a unit? I`m a small man voting for a small solution. If some kind
of macro
Am Fri, 13 May 2011 12:18:48 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
I'm with Michael with this. While I see some valid usecases, I think
the way to introduce a solution (macros) is worse than the problem.
Also I want to stress again what Florian said, namely that macro
Am Thu, 12 May 2011 09:32:28 +0200
schrieb Michael Schnell mschn...@lumino.de:
I would introduce a macro expansion trough a compiler directive.
What a bout a compiler directive to optionally call the gnu C
preprocessor ? I would have wanted used this some time ago for a very
special
Am Fri, 13 May 2011 15:00:26 +0200
schrieb Hans-Peter Diettrich drdiettri...@aol.com:
A general decision is required: do we *want* explicit or implicit
macro expansion?
Yes, I see this point too, i thought it is better to have a restricted
form of macro processing introduced by means of an
Am Fri, 13 May 2011 20:29:32 +0200
schrieb Florian Klämpfl flor...@freepascal.org:
Or just use an inline function with ifdef as mentioned previously. An
inline function with an empty procedure body shouldn't cause any
additional code.
- I believe to remember that the compiler complains about
Am Fri, 13 May 2011 18:19:24 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
We often have enumerated types, with arrays of strings or other
associated information, that must be kept in sync (array dimension
and content). Macros with parameters would allow to create these
Am Sat, 14 May 2011 00:36:17 +0200
schrieb Jonas Maebe jonas.ma...@elis.ugent.be:
1) the compiler automatically makes you keep them in sync, because
adding/removing an element form the enumeration will cause a
compilation error for the array if it's not updated
2) the array can actually be
Am Sat, 14 May 2011 00:36:17 +0200
schrieb Jonas Maebe jonas.ma...@elis.ugent.be:
(via str(), write() and writestr())
Sorry, a misunderstanding, they deliver compile time information to me.
Jörg
___
fpc-devel maillist -
A third one.
It is a further single and isolated solution to prevent the use of a
macro. How many of them are there around? A hundert, a thousand in 5
years?
Jörg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Am Thu, 12 May 2011 09:32:28 +0200
schrieb Michael Schnell mschn...@lumino.de:
What a bout a compiler directive to optionally call the gnu C
preprocessor ? I would have wanted used this some time ago for a very
special project.
Thats a merrily idea: This would mean writing macro definitions
Am Wed, 11 May 2011 09:30:21 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
I always thought the main reason was because C did it that way, and
C++ is C backwards compat.
And C did it because it wanted to save stack space in the minis of
the early seventies. The rest is IMHO
Am Wed, 11 May 2011 09:30:21 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
In our previous episode, Joerg Schuelke said:
The reason for C++ to say a declaration is a statement is coding
security.
But all that was not the question, implementing the desired feature is
in my
Am Wed, 11 May 2011 10:21:45 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
FPC is much lighter on that, and never runs
constructors automatically. It only initializes some pointer values
to NIL.
So you'll have to explain that remark in more detail.
_
Yes, today.
What I mean
Am Wed, 11 May 2011 12:26:09 +0200
schrieb Michael Schnell mschn...@lumino.de:
Readability problems might arise regarding the scope of equally named
variables. Pascal ovoid much of this.
I agree,
and somebody will then come and suggest:
Lets do it this way.
var a:integer;
begin
some code
Am Wed, 11 May 2011 13:12:22 +0200
schrieb Hans-Peter Diettrich drdiettri...@aol.com:
FPC macros don't have parameters, for
this and other reasons. That's not a hard restriction, because inline
procedures can be used instead, in many cases.
Hmmm, I think about macros for pascal with
Am Wed, 11 May 2011 12:28:29 +0200
schrieb Hans-Peter Diettrich drdiettri...@aol.com:
Otherwise a declaration list is accepted only at the
*begin* of a compound statement, not inside a statement list:
compound_stat: '{' [decl_list] [stat_list] '}' ;
I thought that statement =
Am Wed, 11 May 2011 14:52:13 +0200
schrieb Jonas Maebe jonas.ma...@elis.ugent.be:
but I'm
personally not missing anything as far as compiler development is
concerned.
You use an IDE? But what without? The language is the one and the IDE
is the other. There are plenty of users who do not
Am Wed, 11 May 2011 15:08:45 +0200
schrieb Jonas Maebe jonas.ma...@elis.ugent.be:
I don't use any kind of automatic code generation/writing
functionality of any IDE or editor (and I edit the FPC compiler
sources with Lazarus, Text Wrangler, vim and nano depending on what
I'm doing or
Am Wed, 11 May 2011 16:56:38 +0200
schrieb Florian Klaempfl flor...@freepascal.org:
to get a node tree at a particular place. Having this in macros
everywhere makes imo no sense because one would gets an incredible
amount of data.
OK, to make it concrete, I refer to an level driven debug
Am Wed, 11 May 2011 17:56:39 +0200
schrieb Jonas Maebe jonas.ma...@elis.ugent.be:
For the compiler itself such things are toggled via command line
switches (-vc, -vt, -vu, -vd, -vp, ...).
That must be some kind of misunderstanding I know the compiler
switches, I spoke about runtime debugging
Am Wed, 11 May 2011 19:11:40 +0200
schrieb Hans-Peter Diettrich drdiettri...@aol.com:
Since that time I don't wonder any more, why a C compiler
spends 50% of its time in scanning (and preprocessing) the input.
I would introduce a macro expansion trough a compiler directive. Then
there is no
Am Tue, 10 May 2011 11:11:22 -0300
schrieb Marcos Douglas m...@delfire.net:
PS: BTW, what the difference (at least on Win) to use option install
in 'make'?
Thats not windows related, make works the same way on all platforms.
The arguments for make are:
- options for make himself
- targets
Am Tue, 10 May 2011 13:26:59 -0300
schrieb kingbiz...@gmail.com kingbiz...@gmail.com:
*Good:* fast algorithm testings, code creating
*Bad?:* not a standard of the pascal language
Thats a bad idea. It is completely against the basic structure of
pascal. Other Languages have other paradigms.
This third revision with additional %FUNC% macro and 'unknown' strings
changed to internalerror.
Regards
Jörg
Index: scanner.pas
===
--- scanner.pas (Revision 17417)
+++ scanner.pas (Arbeitskopie)
@@ -237,7 +237,7 @@
Am Tue, 10 May 2011 23:50:29 +0200
schrieb Hans-Peter Diettrich drdiettri...@aol.com:
The syntax would look like:
Block = BEGIN [Declarations] {Statement} END .
Yea, it looks like C, but it is not. The difference in C like languages
is that an declaration is just a kind of statement. Without
Am Tue, 10 May 2011 18:41:35 -0300
schrieb kingbiz...@gmail.com kingbiz...@gmail.com:
Some small details can also increase
the community.
Lets see the OOP, its very helpful and speedup a lot the work and has
been added to the Pascal. Same for generics.
To decide that a declaration is a
Am Tue, 10 May 2011 18:41:35 -0300
schrieb kingbiz...@gmail.com kingbiz...@gmail.com:
Lets see the OOP, its very helpful and speedup a lot the work and has
been added to the Pascal. Same for generics.
OOP is an concept. Nobody would say that it would not be helpful if
pascal has templates -an
Am Wed, 11 May 2011 00:23:13 +0200
schrieb Vinzent Höfler jellyfish.softw...@gmx.net:
I would. FPC already has interfaces.
There are good reasons why most languages didn't adopt the C++-way
of doing MI.
I think we have two concepts
- inheritance
- interface
You can decide for one ore
Some days ago I stated that the build-in macros %LINE% and %FILE%, used
inside a macro, expand to the wrong (in my opinion) info from the
defining context and not to those from the expanding context.
That makes them nearly useless, because using them inside a macro for
debugging purposes is their
A little further changing is needed to let it work as suspected. Even
if the macro is included via include file. In my first writing I didn't
recognize that the calling of insertmacro for _ID token is done with
mac.fileinfo.line and .fileindex, which is the point of definition.
Changed to
Am Mon, 9 May 2011 17:23:30 -0300
schrieb Marcos Douglas m...@delfire.net:
I use /fixes_2_4 but I could not to compile (error in first mail).
So, I took a look in sources from /trunk. I compared this files
(odbcsql) and saw this difference between them (the patch).
Did you understand?
Am Fri, 29 Apr 2011 09:58:08 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
I use an IDE macro to insert a predefined line, and then I just
change the constants I will log. The advantage of that way is that
you have full intellisense to specify the vars to dump, something
that is
First i will note that what i state is not an error or bug in free
pascal, but it is somehow unclean implemented.
The decision for modifiers like cvar or cdecl to be an identifier
token or an modifier token relies on context information. But what is
that context? An example:
type
Best regards to all developers,
is it somehow possible to access the line number and file information
during the compilation? This would be nice for debugging purposes.
I do not write about the compiled in debug information for gdb.
ASSERT can - i read it in the documentation - access this
Am Thu, 28 Apr 2011 18:23:10 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
Look in the manual under preprocessor $i (include)
thx, hard to find there. I thought i did read them all, but ...
___
fpc-devel maillist -
Am Thu, 28 Apr 2011 18:22:38 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
In our previous episode, Marco van de Voort said:
No, since modifiers can be in any order, it could be a lot more than
two tokens.
I think if the compiler reeds the cdecl token he needs a lookup of
only
Am Thu, 28 Apr 2011 18:23:10 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
Look in the manual under preprocessor $i (include)
Thats better then nothing, but if you want to include this information
in debugging information, and you won't write it again and again you
will need an
Am Thu, 28 Apr 2011 20:09:59 +0200
schrieb Joerg Schuelke joerg.schue...@gmx.de:
No further explanation needed. Nested comments do it.
I did not know that {$define mx:= ... (*$%LINE%*)} works.
Best regards to Marco
Jörg
___
fpc-devel maillist
Am Thu, 28 Apr 2011 23:39:35 +0200
schrieb Hans-Peter Diettrich drdiettri...@aol.com:
The bug resides in the dirty Delphi OPL definition.
Is it a bug or unspecified behavior? I think it is implemented in the
hope it works good enough.
If you consume a modifier token as modifier or identifier
There is one problem with {$I %LINE%} and his friends, which restricts
the use of these directives. They are expanded even inside a macro
immediately, so, if you define a macro for debugging purposes, you
get the line and file info for the place of the definition and not
for the place of the
70 matches
Mail list logo
