Get variable name at runtime

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Get variable name at runtime

Darius Blaszyk
Hi,

How can I retrieve a variable name at runtime? I know about RTTI on classes, what about simple type variables?

Regards, Darius
 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Get variable name at runtime

Sven Barth-2
Am 04.03.2013 14:39, schrieb [hidden email]:
> Hi,
>
> How can I retrieve a variable name at runtime? I know about RTTI on
> classes, what about simple type variables?

It's not possible.

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Get variable name at runtime

Darius Blaszyk
Is there any way macro's could help in this respect? I'm looking for an way to write the variable name and value to screen at runtime.

Darius



On Mar 4, 2013, at 10:05 PM, Sven Barth wrote:

> Am 04.03.2013 14:39, schrieb [hidden email]:
>> Hi,
>>
>> How can I retrieve a variable name at runtime? I know about RTTI on classes, what about simple type variables?
>
> It's not possible.
>
> Regards,
> Sven
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Get variable name at runtime

Sven Barth-2
Am 05.03.2013 16:41, schrieb Darius Blaszyk:
> Is there any way macro's could help in this respect? I'm looking for an way to write the variable name and value to screen at runtime.
No. I had once asked some time ago for a compiler intrinsic which
returns the name of an identifier, but I was told "why would you need
this?!"...

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Get variable name at runtime

Darius Blaszyk
Here's why :)

Unfortunately pascal macro's are rather limited compared to C. I know I know, you could potentially open up a can of worms, but sometimes more control is required.

Darius


On Mar 5, 2013, at 5:07 PM, Sven Barth wrote:

> Am 05.03.2013 16:41, schrieb Darius Blaszyk:
>> Is there any way macro's could help in this respect? I'm looking for an way to write the variable name and value to screen at runtime.
> No. I had once asked some time ago for a compiler intrinsic which returns the name of an identifier, but I was told "why would you need this?!"...
>
> Regards,
> Sven
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Get variable name at runtime

John Lee
Think there were reasons why it'd be useful - I'd like it so one can (easily) make a disk backup of specific variables' values eg on disk for programs (I have one) that need to be able to continue after stopping or a power failure.

I know new facilities are never trivial, need maintenance etc, but I'm guessing it wouldn't be too difficult (eg for you!) to implement. This would be especially true if it was limited to 'simple' variables longint, string, float etc    

John


>> Is there any way macro's could help in this respect? I'm looking for an way to write the variable name and value to screen at runtime.
> No. I had once asked some time ago for a compiler intrinsic which returns the name of an identifier, but I was told "why would you need this?!"...
>

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Get variable name at runtime

Marco van de Voort
In reply to this post by Darius Blaszyk
In our previous episode, Darius Blaszyk said:
> Here's why :)
>
> Unfortunately pascal macro's are rather limited compared to C. I know I know, you could potentially open up a can of worms, but sometimes more control is required.

There is nothing restraining anybody using an external macro processor. It
is just that we don't want to support it :-)
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Get variable name at runtime

Mark Morgan Lloyd-5
Marco van de Voort wrote:
> In our previous episode, Darius Blaszyk said:
>> Here's why :)
>>
>> Unfortunately pascal macro's are rather limited compared to C. I know I know, you could potentially open up a can of worms, but sometimes more control is required.
>
> There is nothing restraining anybody using an external macro processor. It
> is just that we don't want to support it :-)

Actually, I'd suggest that there is: the difficulty of integrating an
external macro processor with the standard build process (i.e. it's not
just another stage in a makefile).

I've had to deal with colleagues in the past who thought it was entirely
acceptable to make manual edits to compiler output (typically on Intel
blue boxes) before running it through the assembler, and it's very high
on my list of Thou Shalt Nots.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Get variable name at runtime

John Lee
In reply to this post by Marco van de Voort
So, why can't we have a get_name() type routine, so everyone can use it, not just those who can write pascal macros? J 

> Unfortunately pascal macro's are rather limited compared to C. I know I know, you could potentially open up a can of worms, but sometimes more control is required.

There is nothing restraining anybody using an external macro processor. It
is just that we don't want to support it :-)


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Get variable name at runtime

Marco van de Voort
In our previous episode, John Lee said:
> So, why can't we have a get_name() type routine, so everyone can use it,
> not just those who can write pascal macros? J

The proposed Get_name only makes sense for logging purposes. Since if you
can't resolve the gotten string back to an address, it is pretty useless
for other things.

So basically all it is good for is

  log(get_name(x)+' : '+inttostr(x));

like constructs. since this

1)    s:=get_name(x);
2) pass s to a different procedure
3) use s to get access to x in the different procedure

won't work.

>From what I quickly saw while quickreading this discussion, is that the
different proponents have different objectives, and don't seem to realize
it.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Get variable name at runtime

Marco van de Voort
In reply to this post by Mark Morgan Lloyd-5
In our previous episode, Mark Morgan Lloyd said:
> >> Unfortunately pascal macro's are rather limited compared to C. I know I know, you could potentially open up a can of worms, but sometimes more control is required.
> >
> > There is nothing restraining anybody using an external macro processor. It
> > is just that we don't want to support it :-)
>
> Actually, I'd suggest that there is: the difficulty of integrating an
> external macro processor with the standard build process (i.e. it's not
> just another stage in a makefile).

It is. Export all known sources to a new dir for the compiler through the
preprocessor.

> I've had to deal with colleagues in the past who thought it was entirely
> acceptable to make manual edits to compiler output (typically on Intel
> blue boxes) before running it through the assembler, and it's very high
> on my list of Thou Shalt Nots.

General preprocessor usage is on mine. I use preprocessors and
codegenerators all the time, and have no problem whatsoever with it.

What I have a problem is, is to give that formal statement, so that future
development on the compiler will be limited by it in all its gory glory.

IMHO we should simply have a directive that is either cdecl or stdcall
depending on the platform, and kill even the current macro support.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Get variable name at runtime

Darius Blaszyk

[hidden email] schreef op 6 mrt '13:

In our previous episode, Mark Morgan Lloyd said:
Unfortunately pascal macro's are rather limited compared to C. I know I know, you could potentially open up a can of worms, but sometimes more control is required.
There is nothing restraining anybody using an external macro processor. It is just that we don't want to support it :-)
Actually, I'd suggest that there is: the difficulty of integrating an external macro processor with the standard build process (i.e. it's not just another stage in a makefile).
It is. Export all known sources to a new dir for the compiler through the
preprocessor.
I've had to deal with colleagues in the past who thought it was entirely acceptable to make manual edits to compiler output (typically on Intel blue boxes) before running it through the assembler, and it's very high on my list of Thou Shalt Nots.
General preprocessor usage is on mine. I use preprocessors and
codegenerators all the time, and have no problem whatsoever with it.

What I have a problem is, is to give that formal statement, so that future
development on the compiler will be limited by it in all its gory glory.

IMHO we should simply have a directive that is either cdecl or stdcall
depending on the platform, and kill even the current macro support. 
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

What preprocessor do you use then, M4? I'm curious to find out how you use an external preprocessor. In principle it's not a bad idea to use an external one. I suggest we could also make it a bit more user friendly by providing some hooks in fpmake. This way one should not nescesarily create additional scripts to copy files to other locations. What do you think?

Please demonstrate how you use macro's in your perticular case. How do you adjust your build system.


 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Get variable name at runtime

Darius Blaszyk

Just found this project. Seems to be abandoned but might be interesting in the light of Marco's reply;

http://code.google.com/p/metapascal/


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Get variable name at runtime

Michael Van Canneyt
In reply to this post by Marco van de Voort


On Wed, 6 Mar 2013, Marco van de Voort wrote:

> In our previous episode, Mark Morgan Lloyd said:
>>>> Unfortunately pascal macro's are rather limited compared to C. I know I know, you could potentially open up a can of worms, but sometimes more control is required.
>>>
>>> There is nothing restraining anybody using an external macro processor. It
>>> is just that we don't want to support it :-)
>>
>> Actually, I'd suggest that there is: the difficulty of integrating an
>> external macro processor with the standard build process (i.e. it's not
>> just another stage in a makefile).
>
> It is. Export all known sources to a new dir for the compiler through the
> preprocessor.
>
>> I've had to deal with colleagues in the past who thought it was entirely
>> acceptable to make manual edits to compiler output (typically on Intel
>> blue boxes) before running it through the assembler, and it's very high
>> on my list of Thou Shalt Nots.
>
> General preprocessor usage is on mine. I use preprocessors and
> codegenerators all the time, and have no problem whatsoever with it.
>
> What I have a problem is, is to give that formal statement, so that future
> development on the compiler will be limited by it in all its gory glory.
>
> IMHO we should simply have a directive that is either cdecl or stdcall
> depending on the platform

+1

I proposed libcall about 10 years ago - if not longer. OSCall or NativeCall.
Whatever. Just not a macro.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Get variable name at runtime

Mark Morgan Lloyd-5
In reply to this post by Marco van de Voort
Marco van de Voort wrote:

> In our previous episode, Mark Morgan Lloyd said:
>>>> Unfortunately pascal macro's are rather limited compared to C. I know I know, you could potentially open up a can of worms, but sometimes more control is required.
>>> There is nothing restraining anybody using an external macro processor. It
>>> is just that we don't want to support it :-)
>> Actually, I'd suggest that there is: the difficulty of integrating an
>> external macro processor with the standard build process (i.e. it's not
>> just another stage in a makefile).
>
> It is. Export all known sources to a new dir for the compiler through the
> preprocessor.

I meant that in the context of FPC, which works out dependencies etc. on
the fly, one can't arbitrarily hook in an external preprocessor. I meant
that it wasn't another stage in a makefile because FPC doesn't (can't)
use makefiles- for reasons that you explained yesterday.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Get variable name at runtime

Marco van de Voort
In our previous episode, Mark Morgan Lloyd said:
> I meant that in the context of FPC, which works out dependencies etc. on
> the fly, one can't arbitrarily hook in an external preprocessor. I meant
> that it wasn't another stage in a makefile because FPC doesn't (can't)
> use makefiles- for reasons that you explained yesterday.

That's technically impossible, since how the preprocessor influences
dependencies is not know to the compiler.

It is the same discussion as the make -j bit. If you want a C compiling
model, don't use units and use {$i} and manually link it together, like in C.

I prefer the unit model though.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Get variable name at runtime

Marco van de Voort
In reply to this post by Darius Blaszyk
In our previous episode, Darius Blaszyk said:
> What
> preprocessor do you use then, M4?

Nearly always custom. With "general" I mean anything not part or integrated
with the compiler, not necessarily a known product.

The usage is now deceased and replaced by generics for the most.

> I'm curious to find out how you use an external preprocessor.

Basically I defined an own source type (template), and the generator created
Pascal from that. The resulting code was compiled.

> In principle it's not a bad idea to use an external one.  I suggest we
> could also make it a bit more user friendly by providing some hooks in
> fpmake.  This way one should not nescesarily create additional scripts to
> copy files to other locations.  What do you think?

I think while not bad, this is premature. First usage of it (and reallife
experiences), and only then adapt the infrastructure to it.

But fpmake is easier customizable than the compiler of course. First we need
sb willing to massively work on it though :-)

> Please demonstrate how you use macro's in your perticular case.
> How do you adjust your build system.

Not. I simply manually ran a batchfile that generated the makefiles. I was
too lazy to figure out msbuild for that (this was Delphi)
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal