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 16.05.2011 02:30, schrieb Joerg Schuelke:
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
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
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
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
On Mon, May 16, 2011 at 12:23, Joerg Schuelke joerg.schue...@gmx.de wrote:
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
On 16/05/2011 10:23, Joerg Schuelke wrote:
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
And now it is time to say that a real discussion is not possible
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
On 16/05/2011 13:53, Joerg Schuelke wrote:
Am Mon, 16 May 2011 11:11:39 +0100
schrieb Martinf...@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
On 16/05/2011 11:37, Joerg Schuelke wrote:
Yes. If it is used. But most true-pascalian say, it would never be used,
because it is useless ;-)
I think it is not that tragic, the real use cases you will find in
bigger projects are rare.
If use case are so rare, then it raises the bigger
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
On 16/05/2011 01:30, Joerg Schuelke wrote:
const
infoarr:array[callenum] of inforec={
{id:proc1;name:'proc1';address:@cb_proc1},
{id:proc2;name:'proc2';address:@cb_proc2},
{id:proc3;name:'proc3';address:@cb_proc3},
{id:proc4;name:'proc4';address:@cb_proc4},
On 16/05/2011 14:30, Joerg Schuelke wrote:
Am Mon, 16 May 2011 14:07:54 +0100
schrieb Martinf...@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
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
On 16/05/2011 15:18, Joerg Schuelke wrote:
It is not only
the weakness, it is the power too. Will think about.
weakness and power are not necessary opposites, or exclusive.
and btw, allow me the rhetoric (though not as the means of an argument,
since it isn't good style):
you know what
20 matches
Mail list logo
