Dinkum 3.08, VC6, and use_facet 
Author Message
 Dinkum 3.08, VC6, and use_facet

This call:

const std::ctype<char>& fac = std::use_facet<std::ctype<char> >(
std::locale::classic() );

generates and error: 'const _Facet &use_facet(const locale &,const _Facet
*)' : expects 2 arguments - 1 provided'

The offending line in xlocale:

const _Facet& __cdecl use_facet(const locale& _Loc, const _Facet *)

adds the Facet* parameter to fix VC6's template handling issues.  I'd prefer
to use use_facet instead of the _USE macro I see in the same file.  Since
VC6 seems to require a Facet ptr even though no variable name is declared,
why not just go the extra mile and change the declaration to this:

const _Facet& __cdecl use_facet(const locale& _Loc, const _Facet* f=0)  ?

Is there any reason to use "_USE" over the above?



Mon, 30 Aug 2004 05:21:50 GMT  
 Dinkum 3.08, VC6, and use_facet

Quote:

> This call:

> const std::ctype<char>& fac = std::use_facet<std::ctype<char> >(
> std::locale::classic() );

> generates and error: 'const _Facet &use_facet(const locale &,const _Facet
> *)' : expects 2 arguments - 1 provided'

> The offending line in xlocale:

> const _Facet& __cdecl use_facet(const locale& _Loc, const _Facet *)

You left out the line that precedes it:

template<class _Facet> inline

The compiler determines which version of the template function to use
from the type of the pointer passed as the second argument. That's a
workaround for limitations in VC6's template support. The way to call it
is:

        std::use_facet(loc, (facet*)0)

For VC7 you'd call use_facet like this (as the standard requires):

        std::use_facet<facet>(loc)

Quote:

> adds the Facet* parameter to fix VC6's template handling issues.  I'd prefer
> to use use_facet instead of the _USE macro I see in the same file.  Since
> VC6 seems to require a Facet ptr even though no variable name is declared,
> why not just go the extra mile and change the declaration to this:

> const _Facet& __cdecl use_facet(const locale& _Loc, const _Facet* f=0)  ?

> Is there any reason to use "_USE" over the above?

_USE generates the right call both when the library has this workaround
for template limitations and when it doesn't. If you use the macro and
later switch to VC7 you won't have to rewrite your code.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)



Mon, 30 Aug 2004 06:03:44 GMT  
 Dinkum 3.08, VC6, and use_facet

Quote:

> The compiler determines which version of the template function to use
> from the type of the pointer passed as the second argument. That's a
> workaround for limitations in VC6's template support.

right

Quote:
> The way to call it is:

> std::use_facet(loc, (facet*)0)

Why require the extra null when the declaration could provide a default,
though?

Sean



Mon, 30 Aug 2004 06:33:22 GMT  
 Dinkum 3.08, VC6, and use_facet

Quote:


> > The compiler determines which version of the template function to
use
> > from the type of the pointer passed as the second argument. That's a
> > workaround for limitations in VC6's template support.

> right

> > The way to call it is:

> > std::use_facet(loc, (facet*)0)

> Why require the extra null when the declaration could provide a
default,
> though?

It is not the NULL that counts, it's the type of that NULL. Without it,
MSVC cannot figure out the type of return value. If the user does not
specify this type in some way, there's nowhere to obtain it from. MSVC6
does not support specifying it as in use_facet<facet>, so some other way
has to be provided.

Suppose the default argument is given as you suggest. What type is this
expression supposed to return?

std::use_facet(loc);

Note how type name "facet" is not mentioned anywhere.
--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken



Mon, 30 Aug 2004 06:56:38 GMT  
 Dinkum 3.08, VC6, and use_facet

Quote:




> > > The way to call it is:

> > > std::use_facet(loc, (facet*)0)

> > Why require the extra null when the declaration could provide a
> default,
> > though?

> It is not the NULL that counts, it's the type of that NULL. Without it,
> MSVC cannot figure out the type of return value. If the user does not
> specify this type in some way, there's nowhere to obtain it from. MSVC6
> does not support specifying it as in use_facet<facet>, so some other way
> has to be provided.

> Suppose the default argument is given as you suggest. What type is this
> expression supposed to return?

> std::use_facet(loc);

> Note how type name "facet" is not mentioned anywhere.

Certainly.  But the standard requires passing the type name as a template
argument:

std::use_facet<facet>(loc);

So the return type is explicitly specified.  My point was that changing the
line:

const _Facet& __cdecl use_facet(const locale& _Loc, const _Facet *)

to:

const _Facet& __cdecl use_facet(const locale& _Loc, const _Facet *f=0)

would bring the behavior of the call syntactically in line with the standard
and still include the second parameter for VC6 template purposes.  I was
wondering at the reason behind the call not being declared this way, since
it seems such an obvious solution.



Mon, 30 Aug 2004 07:22:52 GMT  
 Dinkum 3.08, VC6, and use_facet

Quote:

> So the return type is explicitly specified.  My point was that changing the
> line:

> const _Facet& __cdecl use_facet(const locale& _Loc, const _Facet *)

> to:

> const _Facet& __cdecl use_facet(const locale& _Loc, const _Facet *f=0)

> would bring the behavior of the call syntactically in line with the standard
> and still include the second parameter for VC6 template purposes.

Code that conforms to the C++ standard calls use_facet<facet>(loc). That
doesn't work with VC6, but it does work with VC7. The approach you
suggest would let you continue to write the same non-conforming code
under VC7. But why do you object to using the _USE macro, which is a
conforming extension, and masks the difference?

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)



Mon, 30 Aug 2004 07:41:12 GMT  
 Dinkum 3.08, VC6, and use_facet

Quote:

> > So the return type is explicitly specified.  My point was that changing
the
> > line:

> > const _Facet& __cdecl use_facet(const locale& _Loc, const _Facet *)

> > to:

> > const _Facet& __cdecl use_facet(const locale& _Loc, const _Facet *f=0)

> > would bring the behavior of the call syntactically in line with the
standard
> > and still include the second parameter for VC6 template purposes.

> Code that conforms to the C++ standard calls use_facet<facet>(loc). That
> doesn't work with VC6, but it does work with VC7. The approach you
> suggest would let you continue to write the same non-conforming code
> under VC7.

I agree that specifying a variable name for the nonstandard _Facet pointer
has undesirable implications.  That being, that use_facet might actually
want to operate on the pointer in some way (or at the very least that the
declaration is less in line with the standard then your solution).  So in
that regard I agree with you.  However adding the default would allow me to
use use_facet in a syntactically standard fashion in VC6, and when I moved
my code to VC7 it would still work, though the call would actually be
referring to a declaration without the second parameter instead (since I
assume the VC6 version of the call would be #ifdef'ed out).  How is this
writing nonstandard code?  Is it just because of what I said above?

Quote:
> But why do you object to using the _USE macro, which is a conforming
> extension, and masks the difference?

I have no real objections to using _USE.  I was just wondering why the macro
was added when such a straightforward solution that used conforming syntax
was available.

Sean



Mon, 30 Aug 2004 07:58:40 GMT  
 Dinkum 3.08, VC6, and use_facet

Quote:

> I have no real objections to using _USE.  I was just wondering why the macro
> was added when such a straightforward solution that used conforming syntax
> was available.

The straightforward solution doesn't work.

The standard requires use_facet<facet>(loc). That works with VC7. With
VC5 (the library was originally written for VC5) it doesn't compile. The
workaround is to call use_facet(loc, (facet*)0). Adding a default value
for the second argument doesn't affect the form of the call in VC5. You
can't say use_facet(loc) -- you have to supply the second argument
explicitly, so the compiler knows the type of the facet that you want.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)



Mon, 30 Aug 2004 08:29:55 GMT  
 Dinkum 3.08, VC6, and use_facet

Quote:

> The straightforward solution doesn't work.

> The standard requires use_facet<facet>(loc). That works with VC7. With
> VC5 (the library was originally written for VC5) it doesn't compile. The
> workaround is to call use_facet(loc, (facet*)0). Adding a default value
> for the second argument doesn't affect the form of the call in VC5. You
> can't say use_facet(loc) -- you have to supply the second argument
> explicitly, so the compiler knows the type of the facet that you want.

Ah, ok.  Thanks for clearing that up.

Sean



Mon, 30 Aug 2004 08:45:47 GMT  
 Dinkum 3.08, VC6, and use_facet

Quote:



> > The straightforward solution doesn't work.

> > The standard requires use_facet<facet>(loc). That works with VC7. With
> > VC5 (the library was originally written for VC5) it doesn't compile. The
> > workaround is to call use_facet(loc, (facet*)0). Adding a default value
> > for the second argument doesn't affect the form of the call in VC5. You
> > can't say use_facet(loc) -- you have to supply the second argument
> > explicitly, so the compiler knows the type of the facet that you want.

> Ah, ok.  Thanks for clearing that up.

Facets are tricky to understand and to get right.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)



Mon, 30 Aug 2004 09:26:06 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Dinkum 3.08 and use_facet

2. Dinkum 3.08 and autoexp.dat

3. Dinkum STL for VC6 with Intel C++ 5

4. Visual c++ 6.0 debugger and DInkumware C++ library 3.08

5. Slightly OT: VC++6, Dikumware 3.08 and Stingray

6. ostream copy constructor question while porting to Dinkumware 3.08

7. Dinkumware 3.08 std::string performance

8. default new_handler with Dinkumware 3.08?

9. STL Error message filter for MSVC6/Native lib/Dinkumware 3.08: now available

10. std::use_facet<>() BUG

11. Dinkum C++ Library

12. Dinkum STL V3.08

 

 
Powered by phpBB® Forum Software