Francis Glassborow <francis@robinton.demon.co.uk> wrote in message
news:uWF+Z+AG4Fl4Ewks@robinton.demon.co.uk...
>
> In article <86tvim$3va$1@panix.com>, Greg Comeau <comeau@panix.com>
> writes
> >>>namespace
> >>>{
> >>>void f() {}
> >>>}
> >>>
> >>>template <void (*)()> class T {};
> >>
> >>Your template parameter doesn't have a name. Is this legal?
> >
> >Yes.
>
> Assuming you are correct, what on earth value other than to cause code
> bloat is there on a template that cannot use its template parameters ?

You can do a "typedef" that creates a new type, which is sometimes useful,
eg

template <class> IntWrapper
{
   public:
      explicit IntWrapper(int i_) : i(i_) {}
      IntWrapper(const IntWrapper& Another) : i(Another.i) {}

   // etc
   private:
      int i;
};

struct RowTag {};
struct ColTag {};

typedef IntWrapper<RowTag> RowType;
typedef IntWrapper<ColTag> ColType;

double Matrix::operator()(RowType Row, ColType Col);


and we've disambiguated forever whether MyMatrix(a,b) refers to the element
at row a, column b or row b, column a.  If the class contains any
non-trivial code, it can _always_ be implemented in terms of inline
forwarding functions to a common (non-unnamed-template) class.  So code
bloat is a non-issue.

Cheers,
Ian McCulloch



---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote in message
news:3895CB04.EF5E33BC@physik.tu-muenchen.de...
> Francis Glassborow wrote:
> >
> > In article <86tvim$3va$1@panix.com>, Greg Comeau <comeau@panix.com>
> > writes
> > >>>namespace
> > >>>{
> > >>>void f() {}
> > >>>}
> > >>>
> > >>>template <void (*)()> class T {};
> > >>
> > >>Your template parameter doesn't have a name. Is this legal?
> > >
> > >Yes.
> >
> > Assuming you are correct, what on earth value other than to cause code
> > bloat is there on a template that cannot use its template parameters ?
>
> It could f.ex. control class behaviour.
>
> Example:
>
> class raw_file
> {
> public:
>   void read(void* size_t);
>   void write(void*, size_t);
>   // ...
> };
>
> enum Packing { unpacked, packed };
>
> template<class POD, Packing = unpacked>
>  struct file_of
> {
> public:
>   void write(POD const& pod)
>   {
>     file.write(&pod, sizeof(pod));
>   }
>   void read(POD& pod)
>   {
>     file.read(&pod, sizeof(pod));
>   }
>   // ...
> private:
>   raw_file file;
>   // ...
> };
>
[snip]
> template<class POD> struct file_of<POD, packed>
> {
> public:
>   void write(POD const& pod)
>   {
>     size_t size = pack_traits<POD>::packed_size();
>     char* data = new char[size];
>     pack_traits<POD>::pack(data, pod);
>     file.write(data, size);
>     delete[] data;
>   }
>   void read(POD& pod)
>   {
>     size_t size = pack_traits<POD>::packed_size();
>     char* data = new char[size];
>     file.read(data, size);
>     pack_traits<POD>::unpack(pod, data);
>     delete[] data;
>   }
>   // ...
> private:
>   raw_file file;
>   // ...
> };
>
> // usage
>
> struct foo { int i; char c; }
[snip]
> file_of<foo> f1;         // not packed
> file_of<foo, packed> f2; // packed
>
> As you see, f1 and f2 have different behaviour, although the code
> itself has no access to the value of the Packing template parameter.

Actually, it does.  In both cases the value of the Packing template
parameter is known and used.  A shorter but equivalent example:

template <bool> struct MyStruct      // un-named template parameter
{
   static std::string WhatAmI() { return "true"; }
};

template<> struct MyStruct<false>
{
   static std::string WhatAmI() { return "false"; }
};

int main()
{
   std::cout << MyStruct<true>::WhatAmI() << ' ' <<
MyStruct<false>::WhatAmI() << std::endl;
}

While it doesn't have _explicit_ access to the template parameter, it has
_implicit_ access and it definitely makes use of the value.  The original
question was whether there is any use for a class that cannot use the value
of its template parameter.

Cheers,
Ian McCulloch



---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <389f0954@clarion.carno.net.au>, Ian McCulloch
<s3141862@student.anu.edu.au> writes
>While it doesn't have _explicit_ access to the template parameter, it has
>_implicit_ access and it definitely makes use of the value.  The original
>question was whether there is any use for a class that cannot use the value
>of its template parameter.

Thanks for this and the other responses.  I had never considered
providing template with an unnamed template parameter and then
specialising it for named types. I am still trying to decide if that is
actually a useful idea.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Andrei Alexandrescu" <andrewalex@hotmail.com> wrote:

>It's strange that many compiler vendors implement functions in
>anonymous namespaces as having internal linkage. I think this code
>should be correct, but MWCW, Intel and Comeau reject it. However, MSVC
>accepts it:
>
>namespace
>{
>void f() {}
>}
>
>template <void (*)()> class T {};

Your template parameter doesn't have a name. Is this legal?

>T<&f> var;

Assuming the unnamed template parameter is legal, this should be legal.
I can see why some compiler's would get it wrong, since static linkage
is such a seductively easy way to implement unnamed namespaces.

>Correct me if I'm wrong.
---------------------------------------------------------------
Pablo Halpern                              phalpern@newview.org
Check out my new book, The C++ Standard Library from Scratch at
http://www.halpernwightsoftware.com/stdlib-scratch

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pablo Halpern <phalpern@newview.org> wrote in message
news:389120a4.449500447@news.internetconnect.net...
> >template <void (*)()> class T {};
>
> Your template parameter doesn't have a name. Is this legal?

It is. To the best of my knowledge, you can comfortably use nonamed template
parameters whenever you feel like it:

template <class> class Mystery;

You can even provide default parameters:

template <class = int> class Mystery;

This is nice with enumerated template parameters, because they already have
a meaningful name:

enum IteratorChoice { ExposeIterators, DontExposeIterators };

template <
    class Leaf,
    IteratorChoice = ExposeIterators>
class Composite;

Thanks for answering.



Andrei


---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <389120a4.449500447@news.internetconnect.net> phalpern@newview.org (Pablo Halpern) writes:
>"Andrei Alexandrescu" <andrewalex@hotmail.com> wrote:
>>It's strange that many compiler vendors implement functions in
>>anonymous namespaces as having internal linkage. I think this code
>>should be correct, but MWCW, Intel and Comeau reject it. However, MSVC
>>accepts it:
>>
>>namespace
>>{
>>void f() {}
>>}
>>
>>template <void (*)()> class T {};
>
>Your template parameter doesn't have a name. Is this legal?

Yes.

>>T<&f> var;
>
>I can see why some compiler's would get it wrong, since static linkage
>is such a seductively easy way to implement unnamed namespaces.

I can't recall if we did it that was because of an earlier draft of C++
before standardization, or because, as you say, it was handy to make
it internal linkage, but in any event the next release of
Comeau C++ 4.2.43 supports it fine.

- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.42 -- NOTE 4.2.42 NOW AVAILABLE
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <86tvim$3va$1@panix.com>, Greg Comeau <comeau@panix.com>
writes
>>>namespace
>>>{
>>>void f() {}
>>>}
>>>
>>>template <void (*)()> class T {};
>>
>>Your template parameter doesn't have a name. Is this legal?
>
>Yes.

Assuming you are correct, what on earth value other than to cause code
bloat is there on a template that cannot use its template parameters ?


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

in article uWF+Z+AG4Fl4Ewks@robinton.demon.co.uk, Francis Glassborow at
francis@robinton.demon.co.uk wrote on 1/30/00 6:39 PM:

> Assuming you are correct, what on earth value other than to cause code
> bloat is there on a template that cannot use its template parameters ?

To avoid code bloat. I'm serious!
You can turn ordinary classes into templates which, if never used, will
never even be instantiated.

-Dave


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <B4BA4695.DE2%abrahams@mediaone.net>, Dave Abrahams
<abrahams@mediaone.net> writes
>To avoid code bloat. I'm serious!
>You can turn ordinary classes into templates which, if never used, will
>never even be instantiated.

?? But any halfway respectable linker will eliminate such code.  And if
you put it in a library it can't include it unless you ask for it.

The code as presented requires a new instantiation for each function
pointer that it might be used with (and hence a new mangled name), now
you need more than a smart linker to eliminate redundancies.

IMHO the above is one of the worst hacks I have ever seen proposed.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <86tvim$3va$1@panix.com>, Greg Comeau <comeau@panix.com>
> writes
> >>>namespace
> >>>{
> >>>void f() {}
> >>>}
> >>>
> >>>template <void (*)()> class T {};
> >>
> >>Your template parameter doesn't have a name. Is this legal?
> >
> >Yes.
>
> Assuming you are correct, what on earth value other than to cause code
> bloat is there on a template that cannot use its template parameters ?

It could f.ex. control class behaviour.

Example:

class raw_file
{
public:
  void read(void* size_t);
  void write(void*, size_t);
  // ...
};

enum Packing { unpacked, packed };

template<class POD, Packing = unpacked>
 struct file_of
{
public:
  void write(POD const& pod)
  {
    file.write(&pod, sizeof(pod));
  }
  void read(POD& pod)
  {
    file.read(&pod, sizeof(pod));
  }
  // ...
private:
  raw_file file;
  // ...
};

template<class T> struct pack_traits // to be specialized
{
  size_t packed_size() { return sizeof(T); }
  void pack(void* dest, T const& src)
  {
    memcpy(dest, &src, packed_size());
  }
  void unpack(T& dest, void const* src)
  {
    memcpy(&dest, src, packed_size();
  }
};

template<class POD> struct file_of<POD, packed>
{
public:
  void write(POD const& pod)
  {
    size_t size = pack_traits<POD>::packed_size();
    char* data = new char[size];
    pack_traits<POD>::pack(data, pod);
    file.write(data, size);
    delete[] data;
  }
  void read(POD& pod)
  {
    size_t size = pack_traits<POD>::packed_size();
    char* data = new char[size];
    file.read(data, size);
    pack_traits<POD>::unpack(pod, data);
    delete[] data;
  }
  // ...
private:
  raw_file file;
  // ...
};

// usage

struct foo { int i; char c; }

template<> struct pack_traits<foo>
{
  size_t packed_size()  { return sizeof(foo::i)+sizeof(foo::c); }
  void pack(void* dest, foo const& src)
  {
    char* dst = static_cast<char*>(dest);
    memcpy(dst, src.i, sizeof(src.i));
    dst += sizeof(foo::i);
    memcpy(dst, src.c, sizeof(src.c));
  }
  void unpack(foo& dest, void const* src)
  {
    char const* s = static_cast<char const*>(src);
    memcpy(dest.i, s, sizeof(dest.i));
    s += sizeof(dest.i);
    memcpy(dest.c, s, sizeof(dest.c));
  }
};

file_of<foo> f1;         // not packed
file_of<foo, packed> f2; // packed

As you see, f1 and f2 have different behaviour, although the code
itself has no access to the value of the Packing template parameter.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

OK, point taken.

TiTi


> Andrei's code was correct. Your code was also correct, but it was not
> related to the point he was making.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Andrei Alexandrescu" <andrewalex@hotmail.com> wrote in message
news:s6nuql1g5k281@news.supernews.com...
[snip]
>
> It's strange that many compiler vendors implement functions in
> anonymous namespaces as having internal linkage. I think this code
> should be correct, but MWCW, Intel and Comeau reject it. However, MSVC
> accepts it:
>
> namespace
> {
> void f() {}
> }
>
> template <void (*)()> class T {};
>
> T<&f> var;
>
>
> Correct me if I'm wrong.

You are right. I'm glad to report that Borland's BCB4 compiles this code
correctly. It only gives a warning that & is superfluous when taking a
pointer to the function. I think it's also a correct message.

--
Gene Bushuyev
Entia non sunt multiplicanda praeter necessitatem
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I'm writing some Python extension modules in C++. This job requires
defining many function pointers (to functions with similar
functionality) with "C" linkage and stuffing them into structs. That's
the background.

So file-static functions are deprecated: I'm supposed to use the
unnamed namespace instead. But names in the unnamed namespace might
have external linkage, and functions declared extern "C" can not
receive the normal protection from name collisions afforded by the
unnamed namespace. If I want to avoid name collisions, it seems like
file-static functions are the only way to go.

Is it time to retract the deprecation of file-static functions, or have
I missed something important here?

-Dave


Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

david_abrahams@my-deja.com wrote:

> So file-static functions are deprecated: I'm supposed to use the
> unnamed namespace instead. But names in the unnamed namespace might
> have external linkage, and functions declared extern "C" can not
> receive the normal protection from name collisions afforded by the
> unnamed namespace.

Why not?

namespace {
 extern "C" void c_func();
}

won't appear in unnamed namespaces in other TU's?



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

<david_abrahams@my-deja.com> wrote in message
news:84dnc5$767$1@nnrp1.deja.com...
> So file-static functions are deprecated: I'm supposed to use the
> unnamed namespace instead. But names in the unnamed namespace might
> have external linkage, and functions declared extern "C" can not
> receive the normal protection from name collisions afforded by the
> unnamed namespace.

It's strange that many compiler vendors implement functions in
anonymous namespaces as having internal linkage. I think this code
should be correct, but MWCW, Intel and Comeau reject it. However, MSVC
accepts it:

namespace
{
void f() {}
}

template <void (*)()> class T {};

T<&f> var;


Correct me if I'm wrong.


Andrei
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 30 Dec 99 17:24:29 GMT, david_abrahams@my-deja.com wrote:

>I'm writing some Python extension modules in C++. This job requires
>defining many function pointers (to functions with similar
>functionality) with "C" linkage and stuffing them into structs. That's
>the background.
>
>So file-static functions are deprecated: I'm supposed to use the
>unnamed namespace instead. But names in the unnamed namespace might
>have external linkage, and functions declared extern "C" can not
>receive the normal protection from name collisions afforded by the
>unnamed namespace. If I want to avoid name collisions, it seems like
>file-static functions are the only way to go.
>
>Is it time to retract the deprecation of file-static functions, or have
>I missed something important here?

I can find nothing in the standard that deprecates file-static
functions.  The nearest thing I can find (D.2)

 The use of the static keyword is deprecated when
 declaring objects in namespace scope.

applies only to objects, not functions.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 31 Dec 1999 02:59:29 GMT, Ron Natalie <ron@sensor.com> wrote:

>david_abrahams@my-deja.com wrote:
>
>> So file-static functions are deprecated: I'm supposed to use the
>> unnamed namespace instead. But names in the unnamed namespace might
>> have external linkage, and functions declared extern "C" can not
>> receive the normal protection from name collisions afforded by the
>> unnamed namespace.
>
>Why not?
>
>namespace {
> extern "C" void c_func();
>}
>
>won't appear in unnamed namespaces in other TU's?

Yes it will.  From 7.5:

 At most one function with a particular name can have C
 language linkage. Two declarations for a function with C
 language linkage with the same function name (ignoring
 the namespace names that qualify it) that appear in
 different namespace scopes refer to the same function.
 ,,, [Note: because of the one definition rule (3.2), only

 one definition for a function or object with C linkage
 may appear in the program; that is, such a function or
 object must not be defined in more than one namespace
 scope.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> It's strange that many compiler vendors implement functions in
> anonymous namespaces as having internal linkage. I think this code
> should be correct, but MWCW, Intel and Comeau reject it. However, MSVC
> accepts it:
> namespace
> {void f() {} }
> template <void (*)()> class T {};
> T<&f> var;
> Correct me if I'm wrong.


I think your code should look like this; it compiles in VC++6, and I suspect
that it compiles on other compilers too. Your code was incorrect, I believe.


Ciao
TiTi
HNY2000


// BC
namespace
{ void f() {}}

typedef void (*simple_f) ();

template <class templ_par>
templ_par T(templ_par t)
{ return t; }

int main(void)
{
 simple_f ff = T<simple_f>(&f);
 (*ff)();
 return 0;
}
// EC



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I think B.Stroustrup has somethng to that extent in the 3d edition, (pp 818,
actually, i just looked it up) but I do not read the standard for a bedtime
story, so I cannot speak for it.
happy new year,
max.



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David Abrahams <david_abrahams@my-deja.com> wrote:

>> So file-static functions are deprecated: I'm supposed to use the
>> unnamed namespace instead. But names in the unnamed namespace might
>> have external linkage, and functions declared extern "C" can not
>> receive the normal protection from name collisions afforded by the
>> unnamed namespace.

Ron Natalie <ron@sensor.com> wrote:

> Why not?
>
>     namespace {
>         extern "C" void c_func();
>     }
>
> won't appear in unnamed namespaces in other TU's?

Lets check the wording of the standard.

7.5/6 says, "Two declarations for a function with C language linkage with
the same function name (ignoring the namespace names that qualify it) that
appear in different namespace scopes refer to the same function."

So it seems that two declarations of c_func refer to the same function, even
if they are in different translation units.

    -- Darin

Note: As you follow up to this thread, please be kind to the readers of
comp.std.c and follow up only to comp.std.c++.



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Michael Rubenstein <miker3@ix.netcom.com> wrote:

> I can find nothing in the standard that deprecates file-static
> functions.  The nearest thing I can find (D.2)
>
>     The use of the static keyword is deprecated when
>     declaring objects in namespace scope.
>
> applies only to objects, not functions.

See C++ core language issue 167, "Deprecating static functions"
<http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/core8.htm#167>. Perhaps this
issue should not become a defect report because of the issue with extern
"C". Or it could be amended to deprecate declaring namespace-scope functions
as static, except those with C language linkage.

    -- Darin

Note: As you follow up to this thread, please be kind to the readers of
comp.std.c and follow up only to comp.std.c++.



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <s6nuql1g5k281@news.supernews.com> "Andrei Alexandrescu" <andrewalex@hotmail.com> writes:
><david_abrahams@my-deja.com> wrote in message
>news:84dnc5$767$1@nnrp1.deja.com...
>> So file-static functions are deprecated: I'm supposed to use the
>> unnamed namespace instead. But names in the unnamed namespace might
>> have external linkage, and functions declared extern "C" can not
>> receive the normal protection from name collisions afforded by the
>> unnamed namespace.
>
>It's strange that many compiler vendors implement functions in
>anonymous namespaces as having internal linkage. I think this code
>should be correct, but MWCW, Intel and Comeau reject it. However, MSVC
>accepts it:
>
>namespace
>{
>void f() {}
>}
>
>template <void (*)()> class T {};
>
>T<&f> var;
>
>Correct me if I'm wrong.

You're not wrong, you're exactly right.  The problem was that
the (draft) language changed about how declarations using 'extern'
are treated in an unnamed namespace, and it's took us a whole to
catch up.  I haven't tried it, but Comeau C++ 4.2.43 should implement
the above ok (a beta of Comeau C++ 4.2.43 is available online on the
Comeau web site if you want to check it out).

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
          Producers of Comeau C/C++ 4.2.42 -- NOTE 4.2.42 NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <PQVsOPtZ4tfQIpcmaxYvjIg+MMm8@4ax.com> , Michael Rubenstein
<miker3@ix.netcom.com>  wrote:

> I can find nothing in the standard that deprecates file-static
> functions.  The nearest thing I can find (D.2)
>
>  The use of the static keyword is deprecated when
>  declaring objects in namespace scope.
>
> applies only to objects, not functions.

Wonderful! It pays to read the standard carefully ;)
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <s6nuql1g5k281@news.supernews.com> , "Andrei Alexandrescu"
<andrewalex@hotmail.com> wrote:

> It's strange that many compiler vendors implement functions in
> anonymous namespaces as having internal linkage. I think this code
> should be correct, but MWCW, Intel and Comeau reject it. However, MSVC
> accepts it:
>
> namespace
> {
> void f() {}
> }
>
> template <void (*)()> class T {};
>
> T<&f> var;
>
>
> Correct me if I'm wrong.

By my reading of the standard (careful, this time), you're correct. I'm
surprised, too!

-Dave
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Andrei Alexandrescu wrote:
>
> <david_abrahams@my-deja.com> wrote in message
> news:84dnc5$767$1@nnrp1.deja.com...
> > So file-static functions are deprecated: I'm supposed to use the
> > unnamed namespace instead. But names in the unnamed namespace might
> > have external linkage, ...
>
> It's strange that many compiler vendors implement functions in
> anonymous namespaces as having internal linkage.

It's a hack to ensure names in the unnamed namespace in different
translation units are kept separate. The hack is not correct, as your
example shows.

> I think this code
> should be correct, but MWCW, Intel and Comeau reject it. However, MSVC
> accepts it:
>
> namespace
> {
> void f() {}
> }
>
> template <void (*)()> class T {};
>
> T<&f> var;

Yes, the code is valid, because f is supposed to have external linkage.

Since this thread has nothing to do with C, I've eliminated comp.std.c
from the cross-posting.

--
Steve Clamage, stephen.clamage@sun.com
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

TiTi <cenTipod@anTi.com> wrote in message
news:84hs0k$srd$1@trex.antw.online.be...
> I think your code should look like this; it compiles in VC++6, and I
suspect
> that it compiles on other compilers too. Your code was incorrect, I
believe.
> namespace
> { void f() {}}
>
> typedef void (*simple_f) ();
>
> template <class templ_par>
> templ_par T(templ_par t)
> { return t; }
>
> int main(void)
> {
>  simple_f ff = T<simple_f>(&f);
>  (*ff)();
>  return 0;
> }

Happy new year,

My code is not incorrect, or better said, it's not incorrect the way
you say. I use a non-type template parameter, while your example
illustrates a type template parameter.

You can have a template taking as argument the address of a function
with external linkage. Functions in unnamed namespaces do have
external linkage. Hence my code should be correct.

Let me write it and ask again: is the code below correct? Thanks.

namespace { void f() {} }
template <void (*)()> class T {};
T<&f> var;

Wow, I've been terse this time :o).


Happy New Year again, to everybody.

Andrei
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

TiTi <cenTipod@anTi.com> wrote:

> I think your code should look like this; it compiles in VC++6, and I suspect
> that it compiles on other compilers too. Your code was incorrect, I believe.

Andrei's code was correct. Your code was also correct, but it was not
related to the point he was making. His point was about compilers that don't
accept pointers to functions in unnamed namespaces as template arguments.
(Compilers are supposed to reject functions with internal linkage, but not
functions with external linkage in an unnamed namespace.)

Template parameters can be types, but they can also be non-types, like
integers or function pointers. This is covered in section 14.1 of the C++
Standard and in section 13.2.3 of Stroustrup's "The C++ Programming
Language, Third Edition".

The class template in the code that you (TiTi) posted takes a template type
parameter. The class template in the code that Andrei posted takes a
template non-type parameter: a function pointer. Passing a function pointer
type as a template argument is not the same thing as passing an actual
function pointer as a template argument.

    -- Darin



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]