Hi,

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

Regards, Darius

Am 04.03.2013 14:39, schrieb

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

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

Darius Blaszyk wrote

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 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

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

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

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.

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

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.

In our previous episode, Mark Morgan Lloyd said:

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.

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.

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/ [1]

Links:
------
[1]
http://code.google.com/p/metapascal/

+1

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

Michael.

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.

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.

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)