Jump to content
mderie

Global variable : why the compiler don't complain about this ?

Recommended Posts

Hi,

 

I was disturbed to say the least that one can declare a global variable the same name as an existing one in another (system) unit.

IE : I encounter the case today, some funny guy declared a global like this one.

 

FormatSettings : TFormatSettings;

 

Althought the exact same line exists in SysUtils... I let you imagine what happened when debugging !

Since some units does include this funny one and the SysUtils one...

 

Any idea ? And yes I know that globals are evil :)

 

Regards.

Share this post


Link to post

Thats a situation where you could use fully qualified names, like

UnitFormats1.FormatSettings. DateSeparator

UnitFormats2.FormatSettings. DateSeparator

 

And yes, the last Uses entry wins, but if you use it may show usually some "ambiguous" name warning,

when accessing methods or fields.

 

 

Edited by Rollo62

Share this post


Link to post

The same applies to type definitions. For example, there is a TBitmap in Vcl.Graphics, and a a completely different TBitmap in Winapi.Windows.

Edited by Der schöne Günther

Share this post


Link to post
32 minutes ago, mderie said:

Indeed, but it is a shame that the compiler don't emit a warning

I don't think so. This is a highly desirable feature to be able to use an existing indentifier. There are rules that the compiler follow. And as @Rollo62 said, you can always use fully qualified names to designate what you want to.

 

  • Like 3

Share this post


Link to post
Guest

 If you check the source files of RAD Studio (Delphi, for example), you will see that this happens! Therefore, it is advisable to use "name-space" for types or vars (if strictly necessary), for example:

  • System.faDirectory in System.SysUtils
  • TFileAttribute.faDirectory in System.IOUtils

note that "faDirectory" is used by default when you do not use "System.IOUtils" in the "Uses" and "TFileAttribute" clause to determine the enumeration where the "faDirectory" value comes from!

 

another, normally, the Global definition will be "hided"  while "local" is used... the, when "local" is out of scope, the "global" is seen.

Edited by Guest

Share this post


Link to post

Hi,

 

<NOSTALGIA_ON>

I'm glad to rediscover a Delphi programmer community !

Back in time I was pleased to find answers through TeamB among other nice people

And finding good components on Torry's Delphi pages

</NOSTALGIA_ON>

 

Now I've quickly test C++ in respect of type redeclarations and global variable redefinitions...

Well let say that my heart beats for the later one... Delphi just takes too many shortcuts !

 

Regards

 

Edited by mderie

Share this post


Link to post
13 hours ago, Fr0sT.Brutal said:

I agree that this identifier overriding should produce a warning or a hint.

We've all been saying this for years and years. My old boss first said this to me 20+ years ago. We are so so so far behind. 

  • Like 1

Share this post


Link to post

Although it is true that the compiler ought to catch such things, it is also true that

- Delphi declares type names like TIntArray

- we should declare like TwmIntArray

 

The more the Delphi types increase, the greater the likelihood of collisions with built-in types.

 

Naming is hard, yes, because too often names are assigned thoughtlessly.

  • Like 1

Share this post


Link to post
Guest
1 hour ago, Bill Meyer said:

Naming is hard, yes, because too often names are assigned thoughtlessly.

no talking about... here we are talking about a "team corporative" that was replaced many many times... then, each "boss" one "vox" or would b a "Bono Vox" :classic_cheerleader:

Share this post


Link to post
1 minute ago, emailx45 said:

no talking about... here we are talking about a "team corporative" that was replaced many many times... then, each "boss" one "vox" or would b a "Bono Vox" :classic_cheerleader:

So mix or match at every turn?

Share this post


Link to post
Guest
Just now, Bill Meyer said:

So mix or match at every turn?

take a time and write to Embarcadero 'Bosses

start by Product Manager, Marcos Cantu

:classic_biggrin:

Share this post


Link to post
On 2/9/2021 at 3:16 PM, FPiette said:

I don't think so. This is a highly desirable feature to be able to use an existing indentifier. There are rules that the compiler follow. And as @Rollo62 said, you can always use fully qualified names to designate what you want to.

 

I like this 'feature' too. Imagine you would need to have a list of all definitions from all Delphi units (+all 3rd party code you use) to be able to create your own unique names. that would be crazy hard to find unique names.

 

What would happen if you have your own TCustomizedPanel and use it all over your project... then Delphi adds same name to their code base. Or any other 3rd party code you want to use, ads it in next update. I think the full qualified name or unit used last in uses clause if good tradeoff.

 

  • Like 1

Share this post


Link to post
Guest

for that i like use "TmyXXX" prefix, of course, somebody can copy me now :classic_unsure:.

 

not much long this, I remember that the Marcos Cantu, "Delphi 3, The Bible", where it showed the "hierarch" of class and a little app for some like this, know all classes on Delphi.

 

Share this post


Link to post
Guest

normally, enums should stay with its "Type"-domain for avoid this. look definition basic:

TxxxxS = (a,b,c, ....)

xxxx = set of TxxxS

 

Share this post


Link to post

Scoping can lead to some weird scenarios.
F.x.

type
  TBase = class
  private
  public
    Data: Integer;
  end;

  TChild = class(TBase)
  private
  public
    Data: string;
  end;


But, being able to "hijack" methods, simply by introducing them to the visible scope, is also kinda useful.

A set of hints would be nice, though, so that you don't do it by accident.
 

Share this post


Link to post
7 hours ago, Mike Torrettinni said:

What about enums?

Like TContactAddressType = (caBusiness, caHome, caPublic) or TmyContactAddressType= (mycaBusiness, mycaHome, mycaPublic)?

 

 

IMHO: First option (Classic).

Delphi is typed so most collisions will be caught by type checking.

  • Like 1

Share this post


Link to post

Come on, compare it with what exists in C++ or C# (I don't know Java enough)

Ask yourself what could be a namespace !

 

Share this post


Link to post

"Let's put dots into unit names, add some confusing matching logic for uses clauses that nobody understands and call that namespaces"

Edited by Stefan Glienke
  • Like 1
  • Haha 2

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×