Is it possible to get information of the name of a var?

For Example.

var
 counter : longint;
 varname : shortstring;
varname := nameofvar( counter );

The content of varname then is 'counter'.

Am Monday 21 November 2011 14:08:43 schrieb

I think all the necessary information for this function are available. The compiler knows the names of all vars. So why shouldn't it be possible to put the name in a shortstring?

Conceivably, you can make such a function that returns the name when debug info is included in the binary.

Or put only the specific information when the compiler detects this function to avoid saving all vars.

Michael. _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

There is no way in Pascal. Conceivably, you can make such a function that returns the name when debug info is included in the binary.

Michael.

If we choose to implement such a function, yes.
My response was based on the compiler as it is.

> Conceivably, you can make such a function that > returns the name when debug info is included in the binary. Or put only the specific information when the compiler detects this function to avoid saving all vars.

Obviously.

Michael.

It would most likely be very easy to implement, but what is the need?

I am storing vars in a textfile like:

mintemp: 300
maxtemp: 350

And so on ...

I put the pointer to the var and the savetext (the same name as the var) in an array wich describes all the vars. When saving all vartexts are written and then the values.
It would be easier then to detect double names for example. The compiler does it then.

If you make all the variables published properties of a class, then you can use RTTI

Am 21.11.2011 14:22, schrieb

Seems like I'm not the only one that likes to have such a function. Though I would extend it to convert identifiers in scope to strings (such as functions names etc.)

Regards,
Sven

But what is the use ? As far as I can see, it forces you to type more.

Typing

VarName:=nameofvar( counter );

is more work than

VarName:='counter';

So what's the point ?

Michael.

Am 22.11.2011 10:13, schrieb

The best argument for such a feature is that the name is checked by the compiler. If I change the declaration of the variable the compiler will complain in the first case, but not in the second (let's assume that we don't need to care about some kind of backwards compatibilty, just because we wrote the identifiers to a file in different versions of the application were the variable had different names).

Regards,
Sven

Maybe there is a use for it in the dbugintf unit?

eg:

SendInteger(counter)

result on the debug server would then possibly be something like...

2011-11-22 Debug: counter = 20

The SendInteger() function will do the identifier-to-string call, not the developer. But then, the parameter name might be used, and not the original identifier name - not sure.

Anyway, currently you have to do the following in dbugintf...

   SendInteger('counter', counter);

I find this annoying, but with CodeTools+SyncroEdit I have managed to reduce my type too. :-)

Regards,
- Graeme -

It would use the name of the formal parameter, as this would mean that the compiler would need to pass the name of the variable as well (without knowing whether this will be needed at all).

Anyway, currently you have to do the following in dbugintf... SendInteger('counter', counter);

It would more be something like

SendInteger(StrOfIdent(counter), counter);

So now reduction of typing here, but a check by the compiler if you choose to rename "counter".

Regards,
Sven

Am Tuesday 22 November 2011 10:13:20 schrieb

Compiler check of the name as Sven also mentioned. This check is very important.

Michael.

Am Tuesday 22 November 2011 12:05:07 schrieb

No that's not correct.
That is in my eyes an excuse not to deal with it.
The search&replace function in lazarus is not the best. I often change the name in the declaration and then see what the compiler says. The compiler does not complain with the text 'counter'. So then you may feel 'secure' but it is not.

Michael.

No, if I was to program it using varname, I would get the name of the parameter in the function SendInteger.

You need the address of the variable that was passed to SendInteger. Obviously, there is no way the compiler can know that.

Michael.

I beg you.... That's the most weak argument I've ever heard.

The name of a variable is only used for debugging, and then you can just as well use the debug info. And the change of a name is usually done with search&replace, option whole word, so the text 'counter' should get changed as well.

The name of a variable is of absolutely no use to the end user.

Michael.

Am Tuesday 22 November 2011 12:14:54 schrieb

Are you sure that you are objective in this diskussion?

And as I answered, I can't possibly imagine why this would matter in the least.

Michael.

That depends entirely on the cost of this function. For example the use Graeme wants is not possible without adding a complete run-time environment a la .NET.

The search&replace function in lazarus is not the best. I often change the name in the declaration and then see what the compiler says. The compiler does not complain with the text 'counter'. So then you may feel 'secure' but it is not.

Once more: the name in the debug message is totally irrelevant. I would fire anyone RELYING on that. And since that's all you want the function for, I consider the use totally marginal...

Michael.

No, if I was to program it using varname, I would get the name of the parameter in the function SendInteger.

That's what I thought - and mentioned that fact.

You need the address of the variable that was passed to SendInteger. Obviously, there is no way the compiler can know that.

In that case I have no more use cases for the "name of var" feature. :)

Regards,
- Graeme -

In our previous episode, Sven Barth said:

The first or the second invocation of sendinteger ? :-)

sendinteger(nameofvar(var1),var2);

is an easily made mistake (copy and paste like).

So I have some doubts about this argument.

Call me old fashioned, but to ask for this capability to save typing seems bizarre.

I'l like it, if as has been suggested it is easy to do, so that it is easier & more error free to implement a variable save and restore capability. I have a program in which some variables values need to be stored in a file, and restored on restart. I do this by by storing a text representation followed by the variable eg jim123:0000. This is then restored by getting the file & finding string jim23: & assigning the value after it to jim23 etc etc. It's not easy to do this for say 40 disparately named variables because the saves and restores have to be individually coded - with this capability it could be done, reliably, in a loop.

John

As much as anyone else in this discussion ? :-)

I just know daily practice; how I and my collegae debug apps. I can't for the life of me imagine why you would *rely* on such a feature.

IMHO it adds only very marginal value: in the the case when you rename a variable, possibly a debug message will not reflect the name change. How marginal is that ?

Doubly so, because in case the executable contains debug info, you can write the function yourself so it looks up the name in the debug info.

But hey, if someone wants to implement this, why not. There are other things in FPC of which I personally do not see the added value...

Michael.

Am Tuesday 22 November 2011 14:09:42 schrieb

It is not that I rely on such a feature. But - of course - when implemented I would use it and it would be strange if this function then disappears.

Now I register every storable value in a list.
// pointer to val, name, alternative name when reading a file, initial value,
min value, max value
myregistervar( @counter , 'counter' , 'counteralt' , 10 , 5 , 200 );
myregistervar( @... , '...' , ... , ... , ... );

counteralt is the alternative name in case of changing the name of the variable. In this case reading from the file does not get lost. But when storing again in the file the new name is used. Ideally the name does not change, but if you have a huge list that's also for the reason of simplicity better to change the names sometimes.

I don't need all the debug info.

Michael.

John Lee wrote

Call me old fashioned, but to ask for this capability to save typing seems bizarre.

There are many functions I don't need. For example am I not a friend of dynamic allocated memory.
I have reasons for not using it.
You may have reasons for using it heavily.
Why shouldn't there exist a function you don't need or see the need for?

afaik debugging was not the initially mentioned purpose. Streaming to a file was. That already exists, see last line.

>> I would fire anyone RELYING on that. > Are you sure that you are objective in this diskussion? As much as anyone else in this discussion ? :-)

Just NameOfVar(x) is indeed not very useful.

But there where hints what people would also want.
- The Name of a variable a pointer is pointing to (or that was given by the callee for a param)
- looping through a list of variables

That would require a list of all variables and there names. So the implementation cost of the feature would be a lot higher.

And as I already wrote, why re-invent the wheel? Use published properties of an object, instead of variables. They have RTTI, so they can already do all of this.

I don't think the question is that simple.

Yes, there are many features not everybody needs. Yet they have to be chosen by some means (language design) and yet there will always be disagreement.

But remember each feature has a cost. Not only what it adds to your app (which it may well be worth), but also what it adds to the compiler: Now and in future maintenance.

And are you sure this feature is really that simple? Now and in all future?

Now it may just be an: check (for existence as var) and quote the literal identifier. But soon you or someone wants to pass a pointer to a variable, and that will raise the cost a lot.

In our previous episode, Martin said:

And as I already wrote, why re-invent the wheel? Use published properties of an object, instead of variables. They have RTTI, so they can already do all of this.

D2010 has RTTI on much more.

But remember each feature has a cost. Not only what it adds to your app (which it may well be worth), but also what it adds to the compiler: Now and in future maintenance.

so just check, & quote the literal val as you suggestl Minimal compiler cost?

Martin wrote

But remember each feature has a cost. Not only what it adds to your app (which it may well be worth), but also what it adds to the compiler: Now and in future maintenance.

A reason why it's a low priority feature of mine. Before I implement that I have other things to add to FPC ^^

Regards,
Sven

I'm a huge fan of synchron edit in Lazarus :P

So I have some doubts about this argument.

The Pros are very few, I admit. Another reason (the other mailed as an answer to one of Martin's mails) why this is a low priority feature for me and I'll implement other "gems" first ;)

Regards,
Sven