Board index » delphi » Static member

Static member

C++ classes can have static members, meaning that all objects of that class
share a single copy of that static variable.  It can be used, for example,
to count the number of objects instantiated.

I can't find an analagous feature in Delphi.  Does this once-in-a-while
handy language feature not exist in Object Pascal?

Thanks,
Lee

 

Re:Static member


Quote
"Lee Grey" <born...@xoptionxinsightx.com> wrote in message

news:3b8d5daa$1_1@dnews...

Quote
> C++ classes can have static members, meaning that all objects of that
class
> share a single copy of that static variable.  It can be used, for example,
> to count the number of objects instantiated.

> I can't find an analagous feature in Delphi.  Does this once-in-a-while
> handy language feature not exist in Object Pascal?

It can be emulated by having a unit-scoped variable in the implementation
section that is accessed by a property in the class, but, no, the feature is
not provided. There are class methods and perhaps we will get class members
in future.

--
Wayne Niddery (Logic Fundamentals, Inc.)
RADBooks: http://www.logicfundamentals.com/RADBooks/delphibooks.html
"Some see private enterprise as a predatory target to be shot, others as a
cow to be milked, but few are those who see it as a sturdy horse pulling the
wagon." - Winston Churchill

Re:Static member


"Wayne Niddery [TeamB]" <wnidd...@aci.on.ca> skrev i melding
news:3b8d6cb5$1_1@dnews...

Quote
> "Lee Grey" <born...@xoptionxinsightx.com> wrote in message
> news:3b8d5daa$1_1@dnews...
> > C++ classes can have static members, meaning that all objects of that
> class
> > share a single copy of that static variable.  It can be used, for
example,
> > to count the number of objects instantiated.

> > I can't find an analagous feature in Delphi.  Does this once-in-a-while
> > handy language feature not exist in Object Pascal?

> It can be emulated by having a unit-scoped variable in the implementation
> section that is accessed by a property in the class, but, no, the feature
is
> not provided. There are class methods and perhaps we will get class members
> in future.

There is a way of doing this:

constructor TMyClass.create;
begin
  GetNumberOfInstances(1);
end;

destructor TMyClass.destroy;
begin
  GetNumberOfInstances(-1);
  inherited Destroy;
end;

function TMyClass.GetNumberofInstances(Delta: integer): integer;
const
  NumInstances: integer = 0;
begin
  inc(NumInstances, Delta);
  result:=NumInstances;
end;

...a writeable const will keep the value from the last "round". It may seem
like a hack, but it's actually safe. Delphi's way of implementing this is not
very likely altered.

--
Bj?rge S?ther
Konsulent & Utvikler
bjo...@itte.no
Kontor: Str?ket 41, 1383 ASKER
Post: Drengsrudveien 44, 1385 ASKER
Telefon +47 66 75 86 00
Fax +47 66 75 86 01
Mobil +47 90 82 22 39
Privat +47 66 90 38 61

Re:Static member


Quote
>function TMyClass.GetNumberofInstances(Delta: integer): integer;
>const
>  NumInstances: integer = 0;
>begin
>  inc(NumInstances, Delta);
>  result:=NumInstances;
>end;

>...a writeable const will keep the value from the last "round". It may seem
>like a hack, but it's actually safe. Delphi's way of implementing this is not
>very likely altered.

Constants at procedure level are no longer supported in D6.

Regards from Germany

Franz-Leo

Re:Static member


In article <7qbsotc91qdrql0vjocj7nm5n58pmbt...@4ax.com>
        Franz-Leo Chomse <franz-leo.cho...@samac.de> wrote:

Quote
> >function TMyClass.GetNumberofInstances(Delta: integer): integer;
> >const
> >  NumInstances: integer = 0;
> >begin
> >  inc(NumInstances, Delta);
> >  result:=NumInstances;
> >end;

> >...a writeable const will keep the value from the last "round". It may seem
> >like a hack, but it's actually safe. Delphi's way of implementing this is not
> >very likely altered.

> Constants at procedure level are no longer supported in D6.

Yes they are.

What's not supported (by default) is writable typed constants. You can
turn them back on, but I wouldn't advise anyone to do so except for
compatibility reasons.

-- Barry

--
  If you're not part of the solution, you're part of the precipitate.
Team JEDI: http://www.delphi-jedi.org
NNQ - Quoting Style in Newsgroup Postings
  http://web.infoave.net/~dcalhoun/nnq/nquote.html

Re:Static member


Quote
>What's not supported (by default) is writable typed constants. You can
>turn them back on, but I wouldn't advise anyone to do so except for
>compatibility reasons.

Thanks for the clarification, but the type needed for your example is
the writable typed constant.

Regards from Germany

Franz-Leo

Re:Static member


In article <3b8f6aa2_2@dnews>
        misc...@linux.nu (Magnus Mischel) wrote:

Quote
> I find they come in handy once in a while... any reason in particular why
> you think they're bad?

Because they are counter-intuitive. They are global variables, but they
look like (in this case) local constants!

Quote
> An example: You have a procedure that you want executed only once.
> Accomplishing this is brilliantly easy using typed constants:

Also easily accomplished with a global variable, and also not as
cryptic.

-- Barry

--
  If you're not part of the solution, you're part of the precipitate.
Team JEDI: http://www.delphi-jedi.org
NNQ - Quoting Style in Newsgroup Postings
  http://web.infoave.net/~dcalhoun/nnq/nquote.html

Re:Static member


I think you're confusing variable lifetime with scoping rules. These are
orthogonal issues. If the variable is defined within a procedure, it is
local in scope  (i.e. it cannot be seen anywhere else) - however if it is
annotated such that its value survives inidividual executions of the
procedure, then it has a global lifetime - but that's fine, and often very
useful. Using a real global variable is much more dangerous since it can be
accessed unintentionally by other code.

However I dislike the notion that a constant is writable and would rather
see a separate marking (like 'static' in C except the word 'static' doesn't
make sense to me).

D

Quote
"Barry Kelly" <dyna...@eircom.net> wrote in message

news:macvot4j145nlnajlv771u7fpvj65ecmsg@4ax.com...
Quote
> Because they are counter-intuitive. They are global variables, but they
> look like (in this case) local constants!

> > An example: You have a procedure that you want executed only once.
> > Accomplishing this is brilliantly easy using typed constants:

> Also easily accomplished with a global variable, and also not as
> cryptic.

> -- Barry

> --
>   If you're not part of the solution, you're part of the precipitate.
> Team JEDI: http://www.delphi-jedi.org
> NNQ - Quoting Style in Newsgroup Postings
>   http://web.infoave.net/~dcalhoun/nnq/nquote.html

Re:Static member


Quote
"David Jameson" <nos...@here.com> wrote in message news:3b90aba5_1@dnews...

> However I dislike the notion that a constant is writable and would rather
> see a separate marking (like 'static' in C except the word 'static'
doesn't
> make sense to me).

Something like 'class variable' or 'class member' would make more sense.

Re:Static member


In article <3b90aba5_1@dnews>
        "David Jameson" <nos...@here.com> wrote:

Quote
> I think you're confusing variable lifetime with scoping rules.

You're wrong. I write compilers; I don't tend to make mistakes like
that.

Quote
> These are
> orthogonal issues. If the variable is defined within a procedure,

It isn't a variable.

Quote
> However I dislike the notion that a constant is writable

It's a logical impossibility, and thus a global variable should be used.

Quote
> and would rather
> see a separate marking (like 'static' in C except the word 'static' doesn't
> make sense to me).

It is static in the sense of being contained in the initialized data
section of the executable image, and loaded by the OS loader in memory
with appropriate fixups.

I wouldn't prefer a separate marking; I prefer to call a spade a spade,
and describe them as global variables, which they are. I'm phobic
towards global variables, where "global" is defined as having a lifetime
dependant on an implementation artifact like the lifetime of the
containing process. I only use global variables to implement singletons,
and even then rarely.

-- Barry

--
  If you're not part of the solution, you're part of the precipitate.
Team JEDI: http://www.delphi-jedi.org
NNQ - Quoting Style in Newsgroup Postings
  http://web.infoave.net/~dcalhoun/nnq/nquote.html

Re:Static member


In article <3b916239_1@dnews>
        "Terry Field" <ter...@nospam.symphosys.com> wrote:

Quote
> "David Jameson" <nos...@here.com> wrote in message news:3b90aba5_1@dnews...

> > However I dislike the notion that a constant is writable and would rather
> > see a separate marking (like 'static' in C except the word 'static'
> doesn't
> > make sense to me).

> Something like 'class variable' or 'class member' would make more sense.

Another name for a global variable. Why would it make more sense?

-- Barry

--
  If you're not part of the solution, you're part of the precipitate.
Team JEDI: http://www.delphi-jedi.org
NNQ - Quoting Style in Newsgroup Postings
  http://web.infoave.net/~dcalhoun/nnq/nquote.html

Re:Static member


Quote
"Barry Kelly" <dyna...@eircom.net> wrote in message

news:h4a3pt0s22ccnvu78d2dlkl8602ept1gd0@4ax.com...

Quote
> It isn't a variable.

Really? Let me see - it started with one value and then it got changed to
another value - that sounds awfully like a variable to me.

Quote
> It's a logical impossibility, and thus a global variable should be used.

The implication does not follow. I wonder perhaps if we have different
definitions for the meaning of "global". In the case of a variable, there is
scope and there is lifetime. If I declare a variable inside a procedure,
then its scope is limited to that procedure. In particular, it cannot be
accessed when that procedure is not executing. However, that does not mean
that the lifetime of the variable is limited to the procedure. In the case
of a local static variable (C-style), the variable maintains its value
through multiple executions of the procedure. It seems to me that this local
scope and global lifetime is precisely what is wanted here (and is
implemented in Delphi with those logically impossible writable-constants).

Quote
> It is static in the sense of being contained in the initialized data
> section of the executable image, and loaded by the OS loader in memory
> with appropriate fixups.

Purely an implementation issue. In particular, some languages (C++ comes
immediately to mind) allow static local variables to be initialised using a
function so it cannot be preinitialised and stored in the initialized data
section of the executable image.

D

Re:Static member


I don't think it would make more sense since we're not talking about
limiting the scope to objects of a class. There's already a definition for a
class variable - in particular, it's a variable whose value is accessible to
(and only to) all instances of a class. Unfortunately, Delphi does not
support class variables.

Incidentally, using a class variable would be better than a global variable
(because it restricts scope a little) but you could also use an instance
variable (which would restrict the scope to all methods of the class and the
lifetime to a particular instance of the class) but in the case where you
want the scope (but not the lifetime) to be limited to an individual
procedure, then you need a way to mark it as such. I'm almost tempted to
want to use the term 'persist' except that implies that the variable
survives multiple executions of the process! Maybe

procedure foo;
var
    i : integer = 24; once; // Initialise it once - allow it to survice
multiple calls to 'foo'
begin
end;

<VBG>

D

Quote
"Terry Field" <ter...@nospam.symphosys.com> wrote in message

news:3b916239_1@dnews...
Quote
> "David Jameson" <nos...@here.com> wrote in message

news:3b90aba5_1@dnews...
Quote

> > However I dislike the notion that a constant is writable and would
rather
> > see a separate marking (like 'static' in C except the word 'static'
> doesn't
> > make sense to me).

> Something like 'class variable' or 'class member' would make more sense.

Re:Static member


In article <3b934faa_1@dnews>
        "David Jameson" <nos...@here.com> wrote:

Quote
> "Barry Kelly" <dyna...@eircom.net> wrote in message
> news:h4a3pt0s22ccnvu78d2dlkl8602ept1gd0@4ax.com...

> > It isn't a variable.
> Really? Let me see - it started with one value and then it got changed to
> another value - that sounds awfully like a variable to me.

It's a "typed constant" - surely you see that it's value shouldn't be
changed?!?

Quote
> > It's a logical impossibility, and thus a global variable should be used.
> The implication does not follow.

You don't agree that modifying typed constants is a logical
impossibility?

Quote
> I wonder perhaps if we have different
> definitions for the meaning of "global".

I don't see global variables with local scope as being much "better"
than global variables with unit-implementation scope.

In fact, I don't see global variables being of much use at all, except
in very narrow circumstances - and in most of those circumstances, I
want to access them from more than one procedure.

Quote
> > It is static in the sense of being contained in the initialized data
> > section of the executable image, and loaded by the OS loader in memory
> > with appropriate fixups.
> Purely an implementation issue. In particular, some languages (C++ comes
> immediately to mind) allow static local variables to be initialised using a
> function so it cannot be preinitialised and stored in the initialized data
> section of the executable image.

Yes, the BSS section (called the initialized section, but it is just a
memory offset and length which the OS loader clears to zeros on program
load - it isn't preinitialized from stuff in the image).

-- Barry

--
  If you're not part of the solution, you're part of the precipitate.
Team JEDI: http://www.delphi-jedi.org
NNQ - Quoting Style in Newsgroup Postings
  http://web.infoave.net/~dcalhoun/nnq/nquote.html

Re:Static member


Hi.

It's a matter of taste to give things their names. You can call tree a
forest and forest a tree- it won't change their nature but force you to
explain what you're talking about. So we shouldn't stick to a paticular name
of a thing only because we like it more. It just isn't helpful in most
cases.

Let's begin by examining the term 'constant'. It's a thing compiler treats
specifically: it makes assumptions that it will be the same during the
lifetime of a program, so it's value may be evaluated and used in place of
the constant name. Also the compiler prevents changing of constant value.
The only way how the value of a constant can be set is by initializing it.

Then ask a question: does this relates somehow to the thing currently named
'typed constant'?
When {$J+} defined the answer is no. I can store and change this things'
value as many times as I wish. The compiler doesn't treats it like const. So
what else other than term 'const' is in it?

At the other hand when {$J-}defined then this thing is surely const!

This brings up a whole issue of relativity and mutation :). At the moment I
suggest to call it (allowed only at procedural level) mutable const or
static variable- actually, it doesn't make any difference.

Alexander

Quote
"Barry Kelly" <dyna...@eircom.net> wrote in message

news:3627ptoark9ormjnuu3b9f1rmh6aknfjaj@4ax.com...
Quote
> In article <3b934faa_1@dnews>
> "David Jameson" <nos...@here.com> wrote:

> > "Barry Kelly" <dyna...@eircom.net> wrote in message
> > news:h4a3pt0s22ccnvu78d2dlkl8602ept1gd0@4ax.com...

> > > It isn't a variable.
> > Really? Let me see - it started with one value and then it got changed
to
> > another value - that sounds awfully like a variable to me.

> It's a "typed constant" - surely you see that it's value shouldn't be
> changed?!?

> > > It's a logical impossibility, and thus a global variable should be
used.
> > The implication does not follow.

> You don't agree that modifying typed constants is a logical
> impossibility?

> > I wonder perhaps if we have different
> > definitions for the meaning of "global".

> I don't see global variables with local scope as being much "better"
> than global variables with unit-implementation scope.

> In fact, I don't see global variables being of much use at all, except
> in very narrow circumstances - and in most of those circumstances, I
> want to access them from more than one procedure.

> > > It is static in the sense of being contained in the initialized data
> > > section of the executable image, and loaded by the OS loader in memory
> > > with appropriate fixups.
> > Purely an implementation issue. In particular, some languages (C++ comes
> > immediately to mind) allow static local variables to be initialised
using a
> > function so it cannot be preinitialised and stored in the initialized
data
> > section of the executable image.

> Yes, the BSS section (called the initialized section, but it is just a
> memory offset and length which the OS loader clears to zeros on program
> load - it isn't preinitialized from stuff in the image).

> -- Barry

> --
>   If you're not part of the solution, you're part of the precipitate.
> Team JEDI: http://www.delphi-jedi.org
> NNQ - Quoting Style in Newsgroup Postings
>   http://web.infoave.net/~dcalhoun/nnq/nquote.html

Go to page: [1] [2]

Other Threads