Am Thu, 12 May 2011 09:32:28 +0200
schrieb Michael Schnell :
> > 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 project.
Yesterda
Michael Schnell schrieb:
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.
IMO you can do that with build macros. But note that you'll have to use
the C macro syntax (#define...), for such stuf
On Thu, 12 May 2011, Jonas Maebe wrote:
On 12 May 2011, at 10:21, Jonas Maebe wrote:
b) it inlines the constents of {$include xxx} statements (so the
compiler-inserted debug information would no longer be correct
This is actually a general problem with preprocessed source files: the line
On 12 May 2011, at 10:21, Jonas Maebe wrote:
b) it inlines the constents of {$include xxx} statements (so the
compiler-inserted debug information would no longer be correct
This is actually a general problem with preprocessed source files: the
line information inserted by the compiler will
Am Thu, 12 May 2011 09:32:28 +0200
schrieb Michael Schnell :
> 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 to a
temporary
On 12 May 2011, at 09:32, Michael Schnell wrote:
On 05/11/2011 06:48 PM, Joerg Schuelke wrote:
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
ve
On 12 May 2011, at 04:11, kingbiz...@gmail.com wrote:
> But something that has been pointed (by Joerg I belive) is the initialization
> of variables, what about it? This would be a nice thing and I don't see why
> not. I prefer to see:
>
> *var
> X: Integer = 0;
> Y: Integer = 100;*
This
On 05/11/2011 06:48 PM, Joerg Schuelke wrote:
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 project.
-Michael
___
Em 11/05/2011 17:01, Vinzent Höfler escreveu:
On Wed, 11 May 2011 12:07:31 +0200, Hans-Peter Diettrich
wrote:
kingbiz...@gmail.com schrieb:
I would like to be able this:
[ some code after begin ]
DoSomething;
var I: Integer;
for I := 0 to 1000 do
DoAnotherThing(I);
[ inside the code ]
Tha
In our previous episode, Joerg Schuelke said:
> That must be some kind of misunderstanding I know the compiler
> switches, I spoke about runtime debugging informations, not compile
> time. And most of the switches generate compile time ones. Am I wrong?
Well, that's the fun of compiler bootstrappi
On Wed, 11 May 2011 12:07:31 +0200, Hans-Peter Diettrich
wrote:
kingbiz...@gmail.com schrieb:
I would like to be able this:
[ some code after begin ]
DoSomething;
var I: Integer;
for I := 0 to 1000 do
DoAnotherThing(I);
[ inside the code ]
That's not good practice, in no programming langu
Am Wed, 11 May 2011 19:11:40 +0200
schrieb Hans-Peter Diettrich :
> 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 need to scan the who
On Tue, May 10, 2011 at 1:26 PM, kingbiz...@gmail.com
wrote:
> I have been playing on other languages sometimes and I see some features
> that speed-up a lot the code creating. I'm posting here one, I want to see
> what you think about it.
>
> Good: fast algorithm testings, code creating
> Bad?: n
Joerg Schuelke schrieb:
Hmmm, I think about macros for pascal with parameters for some time, and
ask you now: where is the debugging macro used inside the whole
compiler sources? Nowhere, because it is nearly impossible to write
some really useful.
The parameters are not the problem.
They are
Am Wed, 11 May 2011 17:56:39 +0200
schrieb Jonas Maebe :
> 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 informations, not compile
On 11 May 2011, at 17:50, Joerg Schuelke wrote:
> Switched by DBGLEV:=3 for example. Programming in C I usually have a
> stack of debug levels, so I can for example code:
>
> DBGPUSH(4);
> call to whatever;
> DBGPOP;
>
> and all that stuff vanishes with -dNODEBUG.
For the compiler itself such
Am Wed, 11 May 2011 16:56:38 +0200
schrieb Florian Klaempfl :
> 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 system
commonly used for
Am 11.05.2011 14:52, schrieb Jonas Maebe:
> but I'm personally not
> missing anything as far as compiler development is concerned.
>
Me neither. And if I really need output during compilation, I add the
needed code manually like
printnode(self);
to get a node tree at a particular place. Having
On 11 May 2011, at 15:22, Joerg Schuelke wrote:
Would not it be helpful to leave the debugging code in the source, and
let him vanish through a conditional define?
The compiler has such code, between {$ifdef EXTDEBUG}. Having full-
fledged macro support would not really make most of that cod
W dniu 2011-05-11 11:39, Joerg Schuelke pisze:
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
Am Wed, 11 May 2011 15:08:45 +0200
schrieb Jonas Maebe :
> 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 how I'm logged in). At l
On 05/11/2011 02:52 PM, Jonas Maebe wrote:
I wish I could do this with macro support, but unfortunately that's
not possible so I have to do it in another and less convenient way"
while working on the compiler.
Some of the stuff that in ANSI C needs to (and can) be done with macros
can be do
On 11 May 2011, at 14:59, Joerg Schuelke wrote:
Am Wed, 11 May 2011 14:52:13 +0200
schrieb Jonas Maebe :
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
Am Wed, 11 May 2011 14:52:13 +0200
schrieb Jonas Maebe :
> 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 use an IDE, or not
all t
On 11 May 2011, at 14:35, Joerg Schuelke wrote:
Hmmm, I think about macros for pascal with parameters for some time,
and
ask you now: where is the debugging macro used inside the whole
compiler sources? Nowhere, because it is nearly impossible to write
some really useful.
I think the answer
Am Wed, 11 May 2011 12:28:29 +0200
schrieb Hans-Peter Diettrich :
> 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 = | ...
And only the kind of which is
Am Wed, 11 May 2011 13:12:22 +0200
schrieb Hans-Peter Diettrich :
> 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 parameters for some time,
On 05/11/2011 12:35 PM, Hans-Peter Diettrich wrote:
It's a very bad idea to "think C, write Pascal", because such a
translation will fail for any number of subtle differences between C
and Pascal.
and what about "think Pascal write C" ? Is this not Java GDR :-P .
-Michael
On 05/11/2011 01:12 PM, Hans-Peter Diettrich wrote:
As the downside a macro can use variables without declarations, so
that the coder is responsible for providing according declarations for
every such macro expansion.
You need to be very silly to do this :-) .
-Michael
_
Joerg Schuelke schrieb:
Am Wed, 11 May 2011 00:23:13 +0200
schrieb Vinzent Höfler :
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 the
Joerg Schuelke schrieb:
Ok, not the reason. But coding security is the reason, you should do
so, if you can. Look at Stroustrup. The reason for pascal not to do so,
is what follows from that, a really complicated stack unwinding, for
example.
Stack unwinding is not an argument, IMO. C++ and OP
Michael Schnell schrieb:
IMHO the reason is reusing the variable name, which in C can be
essential with complex macro declarations. You can reintroduce any
variable name in a {-} block without harming the variable with the same
name declared outside and used before and after the block .
ACK.
Joerg Schuelke schrieb:
To decide that a declaration is a statement and can occur everywhere
where a statement is required, is not that small you think. This has
many consequences, influencing the whole code generation process.
Think about exceptions and stack rewinding.
Right, but a compiler
kingbiz...@gmail.com schrieb:
I don't see any disadvantage writting a code with /C-like with pascal
keywords/, shortcuts are always welcome in order to code faster (also
this is the objective of the High-Level Languages, isn't?). I like
Pascal and I don't see why to resist against some improve
Joerg Schuelke schrieb:
Am Tue, 10 May 2011 23:50:29 +0200
schrieb Hans-Peter Diettrich :
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.
kingbiz...@gmail.com schrieb:
I would like to be able this:
[ some code after begin ]
DoSomething;
var I: Integer;
for I := 0 to 1000 do
DoAnotherThing(I);
[ inside the code ]
That's not good practice, in no programming language.
Better move the loop into a local procedure, where you can decl
Am Wed, 11 May 2011 12:26:09 +0200
schrieb Michael Schnell :
> 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 using a;
var
On 05/11/2011 11:39 AM, Joerg Schuelke wrote:
1. You decide it is nice to declare variables where you need them.
Readability problems might arise regarding the scope of equally named
variables. Pascal ovoid much of this.
-Michael
___
fpc-devel mailli
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
In our previous episode, Joerg Schuelke said:
> > And C did it because it wanted to save stack space in the minis of
> > the early seventies. The rest is IMHO revisionism.
>
> Ok, not the reason. But coding security is the reason, you should do
> so, if you can. Look at Stroustrup. The reason for
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 m
On 05/11/2011 09:30 AM, Marco van de Voort wrote:
And C did it because it wanted to save stack space in the minis of the
early seventies.
Independently from the location a local variable has been declared, the
compiler can decide in what section of the code it reserves stack place
for it. IMHO
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
In our previous episode, Joerg Schuelke said:
> The reason for C++ to say a declaration is a statement is coding
> security.
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
Am Wed, 11 May 2011 00:23:13 +0200
schrieb Vinzent Höfler :
> 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 the other, or possibly
On Wed, 11 May 2011 00:15:12 +0200, Joerg Schuelke
wrote:
Nobody would say that it is not helpful if somebody implements multi
inherited objects for pascal.
I would. FPC already has interfaces.
There are good reasons why most languages didn't adopt the C++-way of
doing MI.
Vinzent.
__
Am Tue, 10 May 2011 18:41:35 -0300
schrieb "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 other very helpf
On Tue, 10 May 2011 23:48:30 +0200, Joerg Schuelke
wrote:
Am Tue, 10 May 2011 18:41:35 -0300
schrieb "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 generic
Am Tue, 10 May 2011 18:41:35 -0300
schrieb "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 statement and c
Em 10/05/2011 18:29, Joerg Schuelke escreveu:
Am Tue, 10 May 2011 23:50:29 +0200
schrieb Hans-Peter Diettrich:
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
Am Tue, 10 May 2011 23:50:29 +0200
schrieb Hans-Peter Diettrich :
> 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 this, I
think
Em 10/05/2011 18:50, Hans-Peter Diettrich escreveu:
kingbiz...@gmail.com schrieb:
*I have been playing on other languages sometimes and I see some
features that speed-up a lot the code creating. I'm posting here one,
I want to see what you think about it.
*
*Good:* fast algorithm testings, c
kingbiz...@gmail.com schrieb:
*I have been playing on other languages sometimes and I see some
features that speed-up a lot the code creating. I'm posting here one, I
want to see what you think about it.
*
*Good:* fast algorithm testings, code creating
*Bad?:* not a standard of the pascal lan
2011/5/10 kingbiz...@gmail.com :
> I have been playing on other languages sometimes and I see some features
> that speed-up a lot the code creating. I'm posting here one, I want to see
> what you think about it.
>
> Good: fast algorithm testings, code creating
> Bad?: not a standard of the pascal l
Am Tue, 10 May 2011 13:26:59 -0300
schrieb "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.
For example C++. Th
*I have been playing on other languages sometimes and I see some
features that speed-up a lot the code creating. I'm posting here one, I
want to see what you think about it.
*
*Good:* fast algorithm testings, code creating
*Bad?:* not a standard of the pascal language
/*method* MyMethod;
*var*
56 matches
Mail list logo
