Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c++ > #82720

Re: 1.0 / 0.0

From Juha Nieminen <nospam@thanks.invalid>
Newsgroups comp.lang.c++
Subject Re: 1.0 / 0.0
Date 2022-01-04 07:58 +0000
Organization Aioe.org NNTP Server
Message-ID <sr0unf$622$1@gioia.aioe.org> (permalink)
References (5 earlier) <sqnf01$1hn9$1@gioia.aioe.org> <squ4m0$258$1@gioia.aioe.org> <squb43$2oi$1@redfloyd.dont-email.me> <squc3a$84h$1@dont-email.me> <squfd9$4mg$1@gioia.aioe.org>

Show all headers | View raw


Muttley@dastardlyhq.com wrote:
> In a similar vein, why does C++ still insist on class static values being set
> outside of the class? eg:
> 
> struct myclass
> {
>    static int i;
> };
> 
> int myclass::i = 123;
> 
> Why on earth can't I just do:
> 
> struct myclass
> {
>    static int i = 123;
> };

As you probably know, 'static' variables declared inside a class aren't
actually member variables, but free-floating variables which visibility
scope is inside that class (the term "class variable" is often used for
these types of variables, in many OO languages, as opposed to "member
variable").

The 'static int i;' in the class definition is just a declaration, and
it needs to be actually defined, ie. instantiated somewhere, in one
(and only one) compilation unit. If you don't instantiate it somewhere
the compiler will be unable to decide where to instantiate it and you'll
get a linker error because it has only been declared but not instantiated
in any compilation unit.

C++17 extended the 'inline' functionality, which does that automatically
for you (so that you don't have to instantiate the variable by hand),
but prior to it you had to do it yourself.

I suppose that when C++98 was standardized it was decided that it's
better to specify the initial value of that 'static' variable where
it's instantiated rather than where it's declared. (I suppose that
technically speaking it wouldn't be hard for compilers to look up
the initial value from either one, because to instantiate the variable
it needs to see the declaration.) Perhaps it was thought that it causes
less confusion because if it's initialized in the declaration it may
look like it will be initialized to that value every time the class
is instantiated (which, of course, is not the case).

> in the same way that const members are initialised? I've never seen a good
> reason why it must be this way and it makes for messy header files.

I don't think const member variables can be initialized in the class
definition in C++98. That syntax was only introduced in C++11.

Back to comp.lang.c++ | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

1.0 / 0.0 Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-29 20:00 +0100
  Re: 1.0 / 0.0 Jack Lemmon <invalid@invalid.net> - 2021-12-29 19:15 +0000
    Re: 1.0 / 0.0 Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-29 21:20 +0100
  Re: 1.0 / 0.0 "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-12-29 13:08 -0800
    Re: 1.0 / 0.0 "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-12-29 20:37 -0800
  Re: 1.0 / 0.0 Paavo Helde <eesnimi@osa.pri.ee> - 2021-12-30 17:25 +0200
    Re: 1.0 / 0.0 "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-12-30 08:55 -0800
  Re: 1.0 / 0.0 Manfred <noname@add.invalid> - 2021-12-30 18:48 +0100
    Re: 1.0 / 0.0 "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-12-30 10:16 -0800
      Re: 1.0 / 0.0 Manfred <noname@add.invalid> - 2021-12-30 20:02 +0100
        Re: 1.0 / 0.0 Muttley@dastardlyhq.com - 2021-12-31 10:25 +0000
          Re: 1.0 / 0.0 Manfred <noname@add.invalid> - 2021-12-31 18:34 +0100
            Re: 1.0 / 0.0 Juha Nieminen <nospam@thanks.invalid> - 2022-01-03 06:21 +0000
              Re: 1.0 / 0.0 red floyd <no.spam.here@its.invalid> - 2022-01-03 00:11 -0800
                Re: 1.0 / 0.0 "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-01-03 09:28 +0100
                Re: 1.0 / 0.0 Juha Nieminen <nospam@thanks.invalid> - 2022-01-03 08:36 +0000
                Re: 1.0 / 0.0 Muttley@dastardlyhq.com - 2022-01-03 09:24 +0000
                Re: 1.0 / 0.0 David Brown <david.brown@hesbynett.no> - 2022-01-03 17:14 +0100
                Re: 1.0 / 0.0 Muttley@dastardlyhq.com - 2022-01-03 16:22 +0000
                Re: 1.0 / 0.0 scott@slp53.sl.home (Scott Lurndal) - 2022-01-03 17:40 +0000
                Re: 1.0 / 0.0 Muttley@dastardlyhq.com - 2022-01-04 09:15 +0000
                Re: 1.0 / 0.0 scott@slp53.sl.home (Scott Lurndal) - 2022-01-04 15:24 +0000
                Re: 1.0 / 0.0 Muttley@dastardlyhq.com - 2022-01-04 16:06 +0000
                Re: 1.0 / 0.0 Juha Nieminen <nospam@thanks.invalid> - 2022-01-04 07:58 +0000
                Re: 1.0 / 0.0 Muttley@dastardlyhq.com - 2022-01-04 09:17 +0000
                Re: 1.0 / 0.0 Manfred <noname@add.invalid> - 2022-01-03 23:14 +0100
                Re: 1.0 / 0.0 Öö Tiib <ootiib@hot.ee> - 2022-01-03 23:50 -0800
                Re: 1.0 / 0.0 Manfred <noname@add.invalid> - 2022-01-04 10:42 +0100
                Re: 1.0 / 0.0 Öö Tiib <ootiib@hot.ee> - 2022-01-04 10:15 -0800
                Re: 1.0 / 0.0 Manfred <noname@invalid.add> - 2022-01-04 20:49 +0100
                Re: 1.0 / 0.0 Öö Tiib <ootiib@hot.ee> - 2022-01-04 15:40 -0800
                Re: 1.0 / 0.0 Juha Nieminen <nospam@thanks.invalid> - 2022-01-04 08:34 +0000
                Re: 1.0 / 0.0 Manfred <noname@add.invalid> - 2022-01-04 10:47 +0100
                Re: 1.0 / 0.0 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-16 12:40 -0800

csiph-web