Greg Comeau wrote:
> I suppose if we had to do it all over again, this might deserve
> some consideration.  But for now two issues seem to leap out:
> 1) Compatibility with C
> 2) Subtleties laced through Standard C++ about internal linkage

Searching through the standard for "internal", it doesn't look all that
bad. The salient issue seems to be that C++ relies on internal linkage
for the semantics of const objects at namespace scope. Presumably this
could be resolved by giving "const" the same treatment as "static" (i.e.
giving it unnamed external linkage). And remember that this use of const
already breaks C compatibility (as per C.1.2, paragraph 3).

- Jim

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <lwL08.21663$_x4.3227545@news2-win.server.ntlworld.com>,
Jim Barry <jim.barry@bigfoot.com> wrote:
>Greg Comeau wrote:
>> I suppose if we had to do it all over again, this might deserve
>> some consideration.  But for now two issues seem to leap out:
>> 1) Compatibility with C
>> 2) Subtleties laced through Standard C++ about internal linkage
>
>Searching through the standard for "internal", it doesn't look all that
>bad.

I think that's just my point: looking for "internal" in either
Standard C or Standard C++ won't find everything about internal linkage.

>The salient issue seems to be that C++ relies on internal linkage
>for the semantics of const objects at namespace scope. Presumably this
>could be resolved by giving "const" the same treatment as "static" (i.e.
>giving it unnamed external linkage). And remember that this use of const
>already breaks C compatibility (as per C.1.2, paragraph 3).

And all I'm saying is: perhaps.
--
Greg Comeau   What's next: additional Windows backends and 'export'!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <VJq%7.10314$Hx3.1319871@news11-gui.server.ntli.net>, Jim
Barry <jim.barry@bigfoot.com> writes
>Greg Comeau wrote:
>> It's really not just about external linkage vs internal linkage.
>> It's about external linkage vs everything else.
>
>Yes, internal linkage seems to be a holdover from C. We could respecify
>"static" to be semantically equivalent to the unnamed namespace. Then we
>would only have two categories: "linkage" and "no linkage". Much
>simpler.

I am not sure that we can if we want C compatibility. Suppose that I
want a file scope function (i.e. internal linkage) that I will pass via
a pointer to a function that expects a pointer to a C function. Yes we
could do it, but we would need a lot of special case rules.


--
Francis Glassborow
The Seasons best wishes to you and yours. May 2002 be better for all of us than
2001 was for some.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <VJq%7.10314$Hx3.1319871@news11-gui.server.ntli.net>,
Jim Barry <jim.barry@bigfoot.com> wrote:
>Greg Comeau wrote:
>> It's really not just about external linkage vs internal linkage.
>> It's about external linkage vs everything else.
>
>Yes, internal linkage seems to be a holdover from C. We could respecify
>"static" to be semantically equivalent to the unnamed namespace. Then we
>would only have two categories: "linkage" and "no linkage". Much
>simpler.

I suppose if we had to do it all over again, this might deserve
some consideration.  But for now two issues seem to leap out:
1) Compatibility with C
2) Subtleties laced through Standard C++ about internal linkage
--
Greg Comeau   What's next: additional Windows backends and 'export'!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <slrna3nlqk.kf.jk@localhost.localdomain>,
Eugene Karpachov <jk@steel.orel.ru> wrote:
>Tue,  8 Jan 2002 15:39:57 GMT Greg Comeau wrote:
>>In article <slrna3l1th.ip.jk@localhost.localdomain>,
>>Eugene Karpachov <jk@steel.orel.ru> wrote:
>>>By the way, why is it deprecated if internal linkage is exactly what I
>>>need? Does it effectively mean that internal linkage itself is
>>>"deprecated" as well? If so, I'd like to hear rationale of this.
>>
>>There are other ways to achieve similar effects.
>
>Yes, there are, but they have their own drawbacks - namely, it is
>impossible to have true internal linkage with unnamed namespace, because
>the standard dictates the opposite. And external linkage, while
>theoretically free of cost, in practice has significant run-time (or,
>to be precise, loading-time) penalty. This is a pain in big projects
>written in C++, such as Mozilla, KDE etc. - the application start-up
>time is incredibly huge, because there is too many of symbols with
>external linkage in executable file.
>
>One could say that it is host environment problem, not language; but it
>is real-world problem, caused by difference of external and internal
>linkage. And the only way to provide internal linkage in the language
>now is "static", which is "deprecated".

I can buy this to a certain extent.  Sure, it's not a language
problem per se.  For instance, one could argue that once the
executable program image has been established that "it" could change
many, at least, of the unnamed namespaces into internal linkage.

But yes, the reality is that nothing today seems to be occuring
with respect to this, whether compilers, linkers, loaders, OSes, etc.

That said, why do you feel that too many symbols with internal
linkage in an executable file don't come with some cost?
(I'm assuming you feel this way, which you may not...)
--
Greg Comeau   What's next: additional Windows backends and 'export'!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <slrna3nmho.kf.jk@localhost.localdomain>,
Eugene Karpachov <jk@steel.orel.ru> wrote:
>By the way, could you give some rationale, or, at least, some hints,
>why templates require parameters with external linkage, not internal?
>After all, with current technology, templates require all source code to be
>visible, so here is nothing to do with linkage. Is it for supporting
>that mythical "export"?

It's really not just about external linkage vs internal linkage.
It's about external linkage vs everything else.
--
Greg Comeau   What's next: additional Windows backends and 'export'!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Greg Comeau wrote:
> It's really not just about external linkage vs internal linkage.
> It's about external linkage vs everything else.

Yes, internal linkage seems to be a holdover from C. We could respecify
"static" to be semantically equivalent to the unnamed namespace. Then we
would only have two categories: "linkage" and "no linkage". Much
simpler.

- Jim

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <slrna3l1th.ip.jk@localhost.localdomain>, Eugene Karpachov says...
>
>on,  7 Jan 2002 17:44:42 GMT Ron Natalie wrote:
>>Of course, this use of static has been deprecated as the use of
>>an unnamed namespace for such symbols is preferred.
>
>By the way, why is it deprecated if internal linkage is exactly what I
>need? Does it effectively mean that internal linkage itself is
>"deprecated" as well? If so, I'd like to hear rationale of this.

'static' is deprecated, because the unnamed namespace is the current
best way to specify internal linkage. And since the unnamed namespace
mechanism is not deprecated, clearly internal linkage isn't either.

HTH,

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Eugene Karpachov wrote:
>
> on,  7 Jan 2002 17:44:42 GMT Ron Natalie wrote:
> >Of course, this use of static has been deprecated as the use of
> >an unnamed namespace for such symbols is preferred.
>
> By the way, why is it deprecated if internal linkage is exactly what I
> need? Does it effectively mean that internal linkage itself is
> "deprecated" as well? If so, I'd like to hear rationale of this.
>

Got me.  While I'm no fan of the n-way overloaded use of the word
static.  I wasn't on the Standards committee (nor paying attention
really until about CD2 time), so I can't comment.  Others probably can.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <slrna3l1th.ip.jk@localhost.localdomain>,
Eugene Karpachov <jk@steel.orel.ru> wrote:
>on,  7 Jan 2002 17:44:42 GMT Ron Natalie wrote:
>>Of course, this use of static has been deprecated as the use of
>>an unnamed namespace for such symbols is preferred.
>
>By the way, why is it deprecated if internal linkage is exactly what I
>need? Does it effectively mean that internal linkage itself is
>"deprecated" as well? If so, I'd like to hear rationale of this.

There are other ways to achieve similar effects.
Here's some of the issues in a nutshell:

   http://www.comeaucomputing.com/techtalk/#nostatic
--
Greg Comeau   What's next: additional Windows backends and 'export'!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <IDD_7.8589$cD4.15505@www.newsranger.com>,
Michiel Salters <Michiel.Salters@cmg.nl> wrote:
>In article <slrna3l1th.ip.jk@localhost.localdomain>, Eugene Karpachov says...
>>on,  7 Jan 2002 17:44:42 GMT Ron Natalie wrote:
>>>Of course, this use of static has been deprecated as the use of
>>>an unnamed namespace for such symbols is preferred.
>>
>>By the way, why is it deprecated if internal linkage is exactly what I
>>need? Does it effectively mean that internal linkage itself is
>>"deprecated" as well? If so, I'd like to hear rationale of this.
>
>'static' is deprecated, because the unnamed namespace is the current
>best way to specify internal linkage. And since the unnamed namespace
>mechanism is not deprecated, clearly internal linkage isn't either.

"specify" is probably the wrong operative word, and perhaps
"in some way mimic" is a better one, since unnamed namespaces do not
establish internal linkage in and of themselves.
--
Greg Comeau   What's next: additional Windows backends and 'export'!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Michiel Salters wrote:
>
> In article <slrna3l1th.ip.jk@localhost.localdomain>, Eugene Karpachov says...
> >
> >on,  7 Jan 2002 17:44:42 GMT Ron Natalie wrote:
> >>Of course, this use of static has been deprecated as the use of
> >>an unnamed namespace for such symbols is preferred.
> >
> >By the way, why is it deprecated if internal linkage is exactly what I
> >need? Does it effectively mean that internal linkage itself is
> >"deprecated" as well? If so, I'd like to hear rationale of this.
>
> 'static' is deprecated, because the unnamed namespace is the current
> best way to specify internal linkage. And since the unnamed namespace
> mechanism is not deprecated, clearly internal linkage isn't either.
>

Just because there's more than one way to do something in the language
hasn't been cause to officially designate something as deprecated.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

jk@steel.orel.ru (Eugene Karpachov) wrote in message
news:<slrna3l1th.ip.jk@localhost.localdomain>...
> on,  7 Jan 2002 17:44:42 GMT Ron Natalie wrote:
> >Of course, this use of static has been deprecated as the use of
> >an unnamed namespace for such symbols is preferred.

> By the way, why is it deprecated if internal linkage is exactly what
> I need? Does it effectively mean that internal linkage itself is
> "deprecated" as well? If so, I'd like to hear rationale of this.

I can think of two:
  - orthogonality: you can't declare a class (or class member
    functions) static, so you need to use unnamed namespaces if you
    don't want them to be seen elsewhere, and
  - static already has enough other uses, getting rid of one is a
    positive point in itself.

--
James Kanze                                   mailto:kanze@gabi-soft.de
Beratung in objektorientierer Datenverarbeitung --
                             -- Conseils en informatique orient   e objet
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany, T   l.: +49 (0)69 19 86 27

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <IDD_7.8589$cD4.15505@www.newsranger.com>, Michiel Salters
<Michiel.Salters@cmg.nl> writes
>'static' is deprecated, because the unnamed namespace is the current
>best way to specify internal linkage. And since the unnamed namespace
>mechanism is not deprecated, clearly internal linkage isn't either.

But the unnamed namespace does NOT provide internal linkage, it provides
external linkage with unutterable linkage names. That is important
because the compiler knows what those linkage names are and so can use
them where templates require that a parameter has external linkage.


--
Francis Glassborow
The Seasons best wishes to you and yours. May 2002 be better for all of us than
2001 was for some.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Tue,  8 Jan 2002 15:39:57 GMT Greg Comeau wrote:
>In article <slrna3l1th.ip.jk@localhost.localdomain>,
>Eugene Karpachov <jk@steel.orel.ru> wrote:
>>By the way, why is it deprecated if internal linkage is exactly what I
>>need? Does it effectively mean that internal linkage itself is
>>"deprecated" as well? If so, I'd like to hear rationale of this.
>
>There are other ways to achieve similar effects.

Yes, there are, but they have their own drawbacks - namely, it is
impossible to have true internal linkage with unnamed namespace, because
the standard dictates the opposite. And external linkage, while
theoretically free of cost, in practice has significant run-time (or,
to be precise, loading-time) penalty. This is a pain in big projects
written in C++, such as Mozilla, KDE etc. - the application start-up
time is incredibly huge, because there is too many of symbols with
external linkage in executable file.

One could say that it is host environment problem, not language; but it
is real-world problem, caused by difference of external and internal
linkage. And the only way to provide internal linkage in the language
now is "static", which is "deprecated".

--
jk

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Tue,  8 Jan 2002 17:51:00 GMT Francis Glassborow wrote:
>But the unnamed namespace does NOT provide internal linkage, it provides
>external linkage with unutterable linkage names. That is important
>because the compiler knows what those linkage names are and so can use
>them where templates require that a parameter has external linkage.

By the way, could you give some rationale, or, at least, some hints,
why templates require parameters with external linkage, not internal?
After all, with current technology, templates require all source code to be
visible, so here is nothing to do with linkage. Is it for supporting
that mythical "export"?

--
jk

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

// declarations
....
static char* str = "XXX";
static size_t lenofstr  = strlen( str );    // is this do-able?
....
int main()
{
....
// use str and lenofstr
....
return 0;
}


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Samantha Fox wrote:
>
> // declarations
> ....
> static char* str = "XXX";
> static size_t lenofstr  = strlen( str );    // is this do-able?

Sure.  It's called dynamic initialization.  As long as you don't
expect it to be initialized until main() starts, then things are
fine.

Of course you could also do:

static char str[] = "XXX";
static size_t lenofstr = sizeof(str) - 1;

Frankly, you probably ought to either do the latter or declare "str" in your
example to be "const char*".

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

// declarations
....
static char* str = "XXX";
static size_t lenofstr  = strlen( str );    // is this do-able?
....
int main()
{
....
// use str and lenofstr
....
return 0;
}




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Samantha Fox" <pamela2002@hotmail.com> wrote in message
news:vkOZ7.2117$lt4.105032@ozemail.com.au...
> // declarations
> ....
> static char* str = "XXX";

I think you mean:

    static const char* str = "XXX";

Because string literals are const.

Furthermore, if you put declarations at file scope, they are treated as if
they were static (or, they have internal linkage), so you can drop the
static qualifier. So you can write:

    const char* str = "XXX";

> static size_t lenofstr  = strlen( str );    // is this do-able?

And:
    size_t lenofstr = strlen( str );

> ....
> int main()
> {
> ....
> // use str and lenofstr

Now you can ...

> ....
> return 0;
> }

--
TiTi (Tom Tempelaere)
Upsilon S.A. - Financial and Computer Engineering
Luxembourg
"All your base are belong to us!" - Cats/Zero Wing


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

TiTi wrote:

> Furthermore, if you put declarations at file scope, they are treated as if
> they were static (or, they have internal linkage), so you can drop the
> static qualifier. So you can write:
>
>     const char* str = "XXX";

Not true.  The above has external linkage.  Static does change that.
Of course, this use of static has been deprecated as the use of
an unnamed namespace for such symbols is preferred.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3c3992f3$0$33503$ba620e4c@news.skynet.be>,
TiTi <TiTi_@skynet.be> wrote:
>"Samantha Fox" <pamela2002@hotmail.com> wrote in message
>news:vkOZ7.2117$lt4.105032@ozemail.com.au...
>> // declarations
>> ....
>> static char* str = "XXX";
>
>I think you mean:
>
>    static const char* str = "XXX";
>
>Because string literals are const.

That surely has its place.

>Furthermore, if you put declarations at file scope, they are treated as if
>they were static (or, they have internal linkage),

Er, no.  Although the static keyword means internal linkage,
static _lifetime_ need not, therefore...

> so you can drop the static qualifier

If the OP really wanted internal linkage, then they would not
want to drop the static qualifier.   As well, they may want
to consider using a unnamed namespace.

>So you can write:
>
>    const char* str = "XXX";
>
>> static size_t lenofstr  = strlen( str );    // is this do-able?
>
>And:
>    size_t lenofstr = strlen( str );

Perhaps static const.... but dropping both is probably not what
the OP wanted.
--
Greg Comeau   What's next: additional Windows backends and 'export'!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Samantha Fox wrote:
>
> // declarations
> ....
> static char* str = "XXX";
> static size_t lenofstr  = strlen( str );    // is this do-able?
> ....
> int main()
> {
> ....
> // use str and lenofstr
> ....
> return 0;
> }

Yes. See 8.5p2: "Automatic, register, static, and external variables of
namespace scope can be initialized by arbitrary expressions involving
literals and previously declared variables and functions."

However, I'd strongly recommend declaring 'str' to be a static
std::string instead, and use string.size() instead of lenofstr. The
approach you're using has lenofstr disconnected from str itself, which
leads to the danger of one being updated in a manner inconsistent with
the other. Variables which are that closely related should be packaged
together, which is precisely what std::string does.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <vkOZ7.2117$lt4.105032@ozemail.com.au>,
Samantha Fox <pamela2002@hotmail.com> wrote:
>static char* str = "XXX";
>static size_t lenofstr  = strlen( str );    // is this do-able?
>....
>int main()
>....

In C++ non-constant static initializers are possible.
You use lenofstr in main, and lenofstr appears after str, so,
that should be ok.  Other scenarios may not be.
--
Greg Comeau   What's next: additional Windows backends and 'export'!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

on,  7 Jan 2002 17:44:42 GMT Ron Natalie wrote:
>Of course, this use of static has been deprecated as the use of
>an unnamed namespace for such symbols is preferred.

By the way, why is it deprecated if internal linkage is exactly what I
need? Does it effectively mean that internal linkage itself is
"deprecated" as well? If so, I'd like to hear rationale of this.

--
jk

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]