Koenig Lookup vs. Barton-Nackman Trick

[Guest]

I'm using a user-defined diagnostics stream and custom manipulators that work with it

template<class charT, class traits = std::char_traits<charT>
class basic_diagsstream : public std::basic_ostream<charT, traits

...
}

and a manipulator

class alar

template <typename charT, typename traits
friend basic_diagsstream<charT, traits>& operator <
(basic_diagsstream<charT, traits>& os, const alarm& a

// manipulate the diagnostics strea
..
return os

}

Intentionally, I defined the put operator inside the alarm manipulator, paying tribute to Angelika and Klaus for the boilerplate code, and to Nicolai and David for the Barton-Nackman explanation :-

I had been using code like this

// Works in VC
diags << "Hello, world"
diags << alarm(STOP_THE_WORLD_I_WANT_TO_GET_OFF)
diags << "Stop!" << alarm(I_WANT_TO_GET_OFF_TOO)

where diags is an instance of basic_diagstream

However, when porting to VC7.1, this code breaks. To fix it, I had to

- Bring the friend function definition for the put operator outside of the alarm manipulator
- Change the signature to take a basic_ostream instead
- Cast inside the global put operator

class alar

template <typename charT, typename traits
friend std::basic_osstream<charT, traits>& operator <
(std::basic_osstream<charT, traits>& os, const alarm& a)
}

template <typename charT, typename traits
std::basic_osstream<charT, traits>& operator <
(std::basic_osstream<charT, traits>& os, const alarm& a

// cast then manipulate..
dynamic_cast<basic_diagstream<charT, traits>>(os)
..
return os


Since VC7.1 is more compliant than VC7, I have the following questions (from the perspective of using VC7.1)

In VC7.1, when defining the put operator within the manipulator (alarm), the code does not compile. The compiler barfs that there is no suitable operator taking an alarm in the rhs. My assumption is that it had to do with Koenig Lookup finding the operator<< that takes an ostream, but could not find an overload that takes an alarm manipulator on its rhs. I would have expected it to find the operator defined inside the alarm manipulator, but it didn't, obviously

- Why does it work in VC7 and not in VC7.1? Does the friend name injection limit the name exposure of the operator<< inside the alarm manipulator (and this limitation is obviously applicable to VC7.1 only)

Regards

Javier Estrad

 

[Carl Daniel [VC++ MVP]]

- Why does it work in VC7 and not in VC7.1? Does the friend name
injection limit the name exposure of the operator<< inside the alarm
manipulator (and this limitation is obviously applicable to VC7.1
only)?

I see Daveed Vandevoorde responded to your posting of this issue in
comp.lang.c++.moderated. If you would be willing to put together a minimal
complete example that compiles under VC7 but fails under VC71 (and yet you
believe should compile) and post it here, I can test it with the whidbey
alpha compiler & submit a bug report for it if it's still broken in that
version.

-cd

 

[Hendrik Schober]

[...] If you would be willing to put together a minimal
complete example that compiles under VC7 but fails under VC71 (and yet you
believe should compile) and post it here, I can test it with the whidbey
alpha compiler & submit a bug report for it if it's still broken in that
version.

Carl,

I have seen statements like this numerous
times here during the last weeks. I assume
that, since reporting bugs for VC7.1 seems
to be considered wasting time, that there
is no intention to fix such bugs in SPs?

-cd

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

 

[Carl Daniel [VC++ MVP]]

Carl Daniel [VC++ MVP]

[...] If you would be willing to put together a minimal
complete example that compiles under VC7 but fails under VC71 (and
yet you believe should compile) and post it here, I can test it with
the whidbey alpha compiler & submit a bug report for it if it's
still broken in that version.

Carl,

I have seen statements like this numerous
times here during the last weeks. I assume
that, since reporting bugs for VC7.1 seems
to be considered wasting time, that there
is no intention to fix such bugs in SPs?

I couldn't say whether there's any intention to make an SP for VC7.1. In
any case, SP's are by definition collections of QFEs. QFEs come into
existence through product support. So, if there's something that needs to
be fixed in VC7.1 in order for you to use the product effectively, you need
to report it to PSS and make them aware of how much it's impacting your day
to day work.

In other words, I post bugs to the Whidbey alpha because I can - not because
it's the only path into the system.

-cd

 

[Hendrik Schober]

[...]
In other words, I post bugs to the Whidbey alpha because I can - not because
it's the only path into the system.

I see. Thanks for the clarification.

-cd

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers

 

[Ronald Laeremans [MSFT]]

As general guidance, issues in an area obscure enough to have Daveed make
the final call on what the standard really says are unlikely to get into an
SP. The bulk of the fixes we make go into the next product. Customer
critical issues (mainly rolled up QFEs) go into service packs.

As Carl said, if you call MS Developer Support and you can make the case
that any issue is absolutely critical for your use of the product, they will
submit a QFE request for it. And we do honor these QFE requests in over 95%
of the cases.

Ronald Laeremans
Visual C++ team

[...]
In other words, I post bugs to the Whidbey alpha because I can - not because
it's the only path into the system.

I see. Thanks for the clarification.

-cd

Schobi

--
(e-mail address removed) is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers