By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
428,739 Members | 1,523 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 428,739 IT Pros & Developers. It's quick & easy.

VC 8.0: Where is two phase lookup?

P: n/a

There have been many announciations that VC 8.0 will finally support two
phase template lookup; now, after I installing VC 2005 Express I had to
realize that it still doesn't!

What has happend to these plans???
Stefan
Nov 17 '05 #1
Share this Question
Share on Google+
29 Replies


P: n/a
Stefan Slapeta wrote:
There have been many announciations that VC 8.0 will finally support
two phase template lookup; now, after I installing VC 2005 Express I
had to realize that it still doesn't!

What has happend to these plans???


Where have you seen such an announcement?

-cd
Nov 17 '05 #2

P: n/a
Carl Daniel [VC++ MVP] wrote:

Where have you seen such an announcement?


I've not seen it, but I've heard it several times (also from Herb
Sutter); many people in the C++ community are currently ensured that
this feature will be part of the next compiler release!

Stefan
Nov 17 '05 #3

P: n/a
Stefan Slapeta wrote:
I've not seen it, but I've heard it several times (also from Herb
Sutter); many people in the C++ community are currently ensured that
this feature will be part of the next compiler release!


I confirmed with the VC++ team that there are no plans to support two-phase
lookup for Whidbey. I've never seen a statement that such support would be
in Whidbey, so I'd be very curious to see a reference to any such claims.

-cd
Nov 17 '05 #4

P: n/a
"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam > wrote in message news:<#l**************@TK2MSFTNGP09.phx.gbl>...
Stefan Slapeta wrote:
I've not seen it, but I've heard it several times (also from Herb
Sutter); many people in the C++ community are currently ensured that
this feature will be part of the next compiler release!


I confirmed with the VC++ team that there are no plans to support two-phase
lookup for Whidbey. I've never seen a statement that such support would be
in Whidbey, so I'd be very curious to see a reference to any such claims.


From http://msdn.microsoft.com/chats/vstu...dio_022703.asp

Host: Herb (Microsoft)
Q: What are current plans as far as becoming compliant wrt two-phase
name lookup?

A: That's one of the three things we didn't implement in Everett (the
others were enforcing exception specifications and export). Two-phase
lookup is related to export, so see also the export answer above. One
issue with two-phase lookup is that when we (or any compiler)
provide(s) it, we'll have to consider migration for users -- two-phase
lookup breaks a LOT of existing code, which is one reason it is not
widely implemented in compilers today. (IIRC, EDG supports it in
strict mode, Metrowerks supports it but you need to throw
-iso_templates on (even -ansi strict isn't enough), and IBM used to
support it as an option but no longer does (even as an option). The MW
and IBM situations are because of breaking code.) BTW, I'm giving a
talk about this at SD West in a few weeks, for those who are in the
Bay area and may be interested --
http://www.cmpevents.com/sdw/a.asp?o...=11&SessID=530. (BTW, I
don't know of any other compiler besides those three that does/did
support 2-phase lookup. Did I miss any?)
Nov 17 '05 #5

P: n/a
krazyman wrote:

From http://msdn.microsoft.com/chats/vstu...dio_022703.asp

Host: Herb (Microsoft)
Q: What are current plans as far as becoming compliant wrt two-phase
name lookup?

A: That's one of the three things we didn't implement in Everett (the
others were enforcing exception specifications and export). Two-phase
lookup is related to export, so see also the export answer above. One
issue with two-phase lookup is that when we (or any compiler)
provide(s) it, we'll have to consider migration for users -- two-phase
lookup breaks a LOT of existing code, which is one reason it is not
widely implemented in compilers today. (IIRC, EDG supports it in
strict mode, Metrowerks supports it but you need to throw
-iso_templates on (even -ansi strict isn't enough), and IBM used to
support it as an option but no longer does (even as an option). The MW
and IBM situations are because of breaking code.) BTW, I'm giving a
talk about this at SD West in a few weeks, for those who are in the
Bay area and may be interested --
http://www.cmpevents.com/sdw/a.asp?o...=11&SessID=530. (BTW, I
don't know of any other compiler besides those three that does/did
support 2-phase lookup. Did I miss any?)


I don't read this as 'two-phase look up will be in Whidbey'. Consider
the statement

"One issue with two-phase lookup is that *when we* (or any compiler)
provide(s) it, we'll have to consider migration for users"

Cheers

Russell
Nov 17 '05 #6

P: n/a
Can someone point me to a link that describes how two-phase look-up
works, and why implementing it will break current code? I've had a
quick search with google, but haven't come up with much help yet.

Thanks

Russell

Stefan Slapeta wrote:

There have been many announciations that VC 8.0 will finally support two
phase template lookup; now, after I installing VC 2005 Express I had to
realize that it still doesn't!

What has happend to these plans???
Stefan

Nov 17 '05 #7

P: n/a

"Russell Hind" <no****@no-where.com> skrev i meddelandet
news:uZ*************@TK2MSFTNGP10.phx.gbl...
Can someone point me to a link that describes how two-phase look-up
works, and why implementing it will break current code? I've had a
quick search with google, but haven't come up with much help yet.


The two-phase lookup is used to determine how to find non-dependent
names (not depending on the template parameters) in a template
definition. Accorning to the standard, the lookup should be performed in
the context of the template's not in the context of its use. The
standard document gives this example:

void g(double);

void h();

template<class T> class Z
{
public:
void f()
{
g(1); //calls g(double)
h++; //illformed: cannot increment function;
// this could be diagnosed either here or
// at the point of instantiation
}
};

void g(int); // not in scope at the point of the template
// definition, not considered for the call g(1)

This of course makes the lookup dependent on the order of the
declarations, which is a huge change.
Bo Persson

Nov 17 '05 #8

P: n/a
Bo Persson wrote:

This of course makes the lookup dependent on the order of the
declarations, which is a huge change.


Thanks. I take it then that if the void g(double) hadn't been declared,
that would have been an error as there was no declaration of g before
the template.

This would definitely break some of my code. Even stuff I was 'playing'
with last night, which is a co-incidence!

Cheers

Russell
Nov 17 '05 #9

P: n/a
Bo Persson wrote:
"Russell Hind" <no****@no-where.com> skrev i meddelandet
news:uZ*************@TK2MSFTNGP10.phx.gbl...
Can someone point me to a link that describes how two-phase look-up
works, and why implementing it will break current code? I've had a
quick search with google, but haven't come up with much help yet.

The two-phase lookup is used to determine how to find non-dependent
names (not depending on the template parameters) in a template
definition. Accorning to the standard, the lookup should be performed in
the context of the template's not in the context of its use. The
standard document gives this example:

void g(double);

void h();

template<class T> class Z
{
public:
void f()
{
g(1); //calls g(double)
h++; //illformed: cannot increment function;
// this could be diagnosed either here or
// at the point of instantiation
}
};

void g(int); // not in scope at the point of the template
// definition, not considered for the call g(1)

This of course makes the lookup dependent on the order of the
declarations, which is a huge change.

If I get it correctly, according to the standard void g(int); wouldn't
be considered to be used inside template class Z, however this is the
rational thing to be expected or am I wrong? Doesn't the same already
apply for ordinary class and function definitions?


Regards,

Ioannis Vranos
Nov 17 '05 #10

P: n/a
Ioannis Vranos wrote:

If I get it correctly, according to the standard void g(int); wouldn't
be considered to be used inside template class Z, however this is the
rational thing to be expected or am I wrong? Doesn't the same already
apply for ordinary class and function definitions?


For non-template classes yes, if g(double) wasn't declared there would
be an error.

However, for template stuff, the method code isn't really compiled until
you actually use it, so by the time you use it, both

g(double) and
g(int)

have been declared, so which would be called? templates behave
differently from non-template classes because the method compilation
doesn't take place until instantiation.

I think thats correct, anyway.

Thanks

Russell
Nov 17 '05 #11

P: n/a
Russell Hind wrote:
Ioannis Vranos wrote:

If I get it correctly, according to the standard void g(int); wouldn't
be considered to be used inside template class Z, however this is the
rational thing to be expected or am I wrong? Doesn't the same already
apply for ordinary class and function definitions?


For non-template classes yes, if g(double) wasn't declared there would
be an error.

However, for template stuff, the method code isn't really compiled until
you actually use it, so by the time you use it, both

g(double) and
g(int)

have been declared, so which would be called? templates behave
differently from non-template classes because the method compilation
doesn't take place until instantiation.

I think thats correct, anyway.


It doesn't matter in what stage of the compilation phase they get
compiled, it should matter in which order they were declared.


Regards,

Ioannis Vranos
Nov 17 '05 #12

P: n/a
Ioannis Vranos wrote:

void g(double);

void h();

template<class T> class Z
{
public:
void f()
{
g(1); //calls g(double)
h++; //illformed: cannot increment function;
// this could be diagnosed either here or
// at the point of instantiation
}
};

void g(int); // not in scope at the point of the template
// definition, not considered for the call g(1)

If I get it correctly, according to the standard void g(int); wouldn't
be considered to be used inside template class Z, however this is the
rational thing to be expected or am I wrong? Doesn't the same already
apply for ordinary class and function definitions?


It is not to be expected. Two-phase lookup means that every name which
is not dependent on a template parameter is looked up during _parsing_
the template (also dependent names are looked up if they are
unqualified, but the result set for this lookup is extended during the
second phase, see below). Thus, at the time of parsing this template,
only g(double) can be valid, because nothing of this call (name or
arguments) is dependent on a template parameter.

During the _second_ phase (instantiation of the template), the names for
qualified dependent names are looked up and for unqualified dependent
names, an additional ADL is performed. This is even more interesting if
you consider this example:
void g(float) {}

template<typename T> void f(T t) {
g(t);
}

void g(double) {}

int main() {
f(1);
}
Here, the argument t in g(t) _is_ dependent, but ADL does not add viable
candidates to the overload set. Thus, this call _must not_ be ambigous!
(=my favourite test case on two-phase lookup...)
Stefan
Nov 17 '05 #13

P: n/a
Stefan Slapeta wrote:

void g(float) {}

template<typename T> void f(T t) {
g(t);
}

void g(double) {}

int main() {
f(1);
}
Here, the argument t in g(t) _is_ dependent, but ADL does not add viable
candidates to the overload set. Thus, this call _must not_ be ambigous!
(=my favourite test case on two-phase lookup...)


However if the above is:

void g(float) {}

template<typename T> void f(T t)
{
g(t);
}

void g(int) {}

int main()
{
f(1);
}
according to the standard, which one should be called?


Regards,

Ioannis Vranos
Nov 17 '05 #14

P: n/a
Russell Hind wrote:
I don't read this as 'two-phase look up will be in Whidbey'. Consider
the statement

"One issue with two-phase lookup is that *when we* (or any compiler)
provide(s) it, we'll have to consider migration for users"


I wouldn't go so far, because such a strategy seems quite impossible to
me. I think it would be sufficient for all users if there is an optional
switch that turns on two-phase lookup (which can be disabled as
default). It is a simple fact that you can't guarantee that your code is
standard conformant if your compiler doesn't complain about issues
caused by incorrect declaration order in your code!

The better reason for not implementing it is, as I assume, that it would
strongly decrease compiler performance (because you have to parse
templates you normally wouldn't).

Stefan
Nov 17 '05 #15

P: n/a
Ioannis Vranos wrote:
However if the above is:

void g(float) {}

template<typename T> void f(T t)
{
g(t);
}

void g(int) {}

int main()
{
f(1);
}
according to the standard, which one should be called?


It's the same - the second g is no candidate for the overload set (it's
not seen at the time of parsing the template).

Stefan
Nov 17 '05 #16

P: n/a
Stefan Slapeta wrote:
Ioannis Vranos wrote:
However if the above is:

void g(float) {}

template<typename T> void f(T t)
{
g(t);
}

void g(int) {}

int main()
{
f(1);
}
according to the standard, which one should be called?


It's the same - the second g is no candidate for the overload set (it's
not seen at the time of parsing the template).


OK then, it seems I haven't understood yet. So what would be different
with the two phases?


Regards,

Ioannis Vranos
Nov 17 '05 #17

P: n/a
krazyman wrote:
"Carl Daniel [VC++ MVP]"
<cp*****************************@mvps.org.nospam > wrote in message
news:<#l**************@TK2MSFTNGP09.phx.gbl>...
Stefan Slapeta wrote:
I've not seen it, but I've heard it several times (also from Herb
Sutter); many people in the C++ community are currently ensured that
this feature will be part of the next compiler release!


I confirmed with the VC++ team that there are no plans to support
two-phase
lookup for Whidbey. I've never seen a statement that such support
would be
in Whidbey, so I'd be very curious to see a reference to any such
claims.


From http://msdn.microsoft.com/chats/vstu...dio_022703.asp


Thanks for the link. I participated in that chat - it might have been me
that asked the question about two-phase lookup in fact. There's clearly no
indication in that chat that two-phase lookup would be in Whidbey, only a
reasonably clear statement that two-phase lookup is related to export and
that MS would consider implementing it when there's sufficient market demand
for it, at that time providing a smooth migration path becasue two-phase
lookup will break a lot of code.

-cd
Nov 17 '05 #18

P: n/a

"Ioannis Vranos" <iv*@guesswh.at.grad.com> skrev i meddelandet
news:uI**************@TK2MSFTNGP12.phx.gbl...
Stefan Slapeta wrote:
Ioannis Vranos wrote:
However if the above is:

void g(float) {}

template<typename T> void f(T t)
{
g(t);
}

void g(int) {}

int main()
{
f(1);
}
according to the standard, which one should be called?


It's the same - the second g is no candidate for the overload set (it's not seen at the time of parsing the template).


OK then, it seems I haven't understood yet. So what would be different
with the two phases?


The big difference is that different sets of overloads can be seen at
different points of use of the template. They should all be using the
same g(float) anyway. This isn't considered in most of existing code.

I have heard stories about when HP first tried to implement this, and
almost nothing would compile, not even the standard library. It took
them a while to realize that the compiler was actually right, and that
they immediately had to add a switch to turn the new features off!
Bo Persson
Nov 17 '05 #19

P: n/a
Bo Persson wrote:
The big difference is that different sets of overloads can be seen at
different points of use of the template. They should all be using the
same g(float) anyway. This isn't considered in most of existing code.

I have heard stories about when HP first tried to implement this, and
almost nothing would compile, not even the standard library. It took
them a while to realize that the compiler was actually right, and that
they immediately had to add a switch to turn the new features off!


I think that all these statements are quite exaggerated; from my
experience, the impact on existing projects normally is quite small.

BTW, with two-phase lookup turned on, the 7.1 standard lib compiles
without any problems if you just make two very small patches (one in
xdebug and on in xlocale).
Stefan
Nov 17 '05 #20

P: n/a
Carl Daniel [VC++ MVP] wrote:
... MS would consider implementing it when there's sufficient market demand for it, at that time providing a smooth migration path becasue two-phase
lookup will break a lot of code.


As I said before - if you make it an optional feature,

.... you could find name lookup issues in your code
.... nobody would have to change any code if he doesn't like to
.... (thus) you wouldn't need any migration path
.... you would (optionally) have more standard conformance in your compiler
Stefan
Nov 17 '05 #21

P: n/a
Stefan Slapeta wrote:
Carl Daniel [VC++ MVP] wrote:
> ... MS would consider implementing it when there's sufficient

market demand
for it, at that time providing a smooth migration path becasue
two-phase lookup will break a lot of code.


As I said before - if you make it an optional feature,

... you could find name lookup issues in your code
... nobody would have to change any code if he doesn't like to
... (thus) you wouldn't need any migration path
... you would (optionally) have more standard conformance in your
compiler


And I'm sure that's what they'll do eventally (Herb pretty much said so) -
but not in Whidbey.

-cd
Nov 17 '05 #22

P: n/a
On Thu, 08 Jul 2004 15:11:28 +0200, Stefan Slapeta
<st************@slapeta.com> wrote:
Ioannis Vranos wrote:
However if the above is:

void g(float) {}

template<typename T> void f(T t)
{
g(t);
}

void g(int) {}

int main()
{
f(1);
}
according to the standard, which one should be called?


It's the same - the second g is no candidate for the overload set (it's
not seen at the time of parsing the template).


Nonsense - in the expression "g(t)" g is a dependent name, so lookup
is deferred. IOW, g(int) is called.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Nov 17 '05 #23

P: n/a
On Thu, 08 Jul 2004 16:25:37 +0200, Stefan Slapeta
<st************@slapeta.com> wrote:
Bo Persson wrote:
The big difference is that different sets of overloads can be seen at
different points of use of the template. They should all be using the
same g(float) anyway. This isn't considered in most of existing code.

I have heard stories about when HP first tried to implement this, and
almost nothing would compile, not even the standard library. It took
them a while to realize that the compiler was actually right, and that
they immediately had to add a switch to turn the new features off!


I think that all these statements are quite exaggerated; from my
experience, the impact on existing projects normally is quite small.

BTW, with two-phase lookup turned on, the 7.1 standard lib compiles
without any problems if you just make two very small patches (one in
xdebug and on in xlocale).


The 7.1 standard lib is Dinkumware's, and that works with Comeau C++,
which has had 2 phase lookup for years. They fixed any such problems
it had with two phase lookup years ago. Presumably the errors are
coming from VC 7.1 specific code in the library.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Nov 17 '05 #24

P: n/a
On Thu, 8 Jul 2004 09:09:32 -0700, "Carl Daniel [VC++ MVP]"
<cp*****************************@mvps.org.nospam > wrote:
Stefan Slapeta wrote:
Carl Daniel [VC++ MVP] wrote:
> ... MS would consider implementing it when there's sufficient

market demand
for it, at that time providing a smooth migration path becasue
two-phase lookup will break a lot of code.


As I said before - if you make it an optional feature,

... you could find name lookup issues in your code
... nobody would have to change any code if he doesn't like to
... (thus) you wouldn't need any migration path
... you would (optionally) have more standard conformance in your
compiler


And I'm sure that's what they'll do eventally (Herb pretty much said so) -
but not in Whidbey.


VC is now one of the few mainstream compilers that doesn't have two
phase name lookup. GCC 3.4 was the first GCC version with it.

http://gcc.gnu.org/gcc-3.4/changes.html#cplusplus

Microsoft are back to playing conformance catch-up!

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Nov 17 '05 #25

P: n/a
tom_usenet wrote:

Nonsense - in the expression "g(t)" g is a dependent name, so lookup
is deferred. IOW, g(int) is called.


Maybe you should try it out before you talk about nonsense. And - read
my postings.

Stefan
Nov 17 '05 #26

P: n/a

"tom_usenet" <to********@hotmail.com> skrev i meddelandet
news:tp********************************@4ax.com...
On Thu, 8 Jul 2004 09:09:32 -0700, "Carl Daniel [VC++ MVP]"
<cp*****************************@mvps.org.nospam > wrote:
Stefan Slapeta wrote:
Carl Daniel [VC++ MVP] wrote:

> ... MS would consider implementing it when there's sufficient
market demand
for it, at that time providing a smooth migration path becasue
two-phase lookup will break a lot of code.

As I said before - if you make it an optional feature,

... you could find name lookup issues in your code
... nobody would have to change any code if he doesn't like to
... (thus) you wouldn't need any migration path
... you would (optionally) have more standard conformance in your
compiler


And I'm sure that's what they'll do eventally (Herb pretty much said so) -but not in Whidbey.


VC is now one of the few mainstream compilers that doesn't have two
phase name lookup. GCC 3.4 was the first GCC version with it.

http://gcc.gnu.org/gcc-3.4/changes.html#cplusplus

Microsoft are back to playing conformance catch-up!


Yes, they are once again spending their effort on yet another managed
version of C++, instead of doing the real thing. Sigh!
Here's another company which DO have a beta of a compliant compiler.
http://www.borland.com/products/down...cbuilderx.html

Unfortunately they wrote the development environment in Java. Write
once, wait everywhere...

We'll have to start shouting louder again, so MS realizes that there IS
a customer demand!

Bo Persson
Nov 17 '05 #27

P: n/a
Bo Persson wrote:

Here's another company which DO have a beta of a compliant compiler.
http://www.borland.com/products/down...cbuilderx.html

Unfortunately they wrote the development environment in Java. Write
once, wait everywhere...


I've been using CBX since it was released last october and don't have a
problem with the speed of the IDE even though it is in Java. Running on
2.4GHz P4 with 1Gb RAM.

The compiler did seem to work well, but was only a beta and couldn't be
used for anything more than a few simple tests (well no multi-threading
support in the beta was a killer for me).

Unfortunately it seems Borland are no concentrating on mobile
applications development (palm, symbian etc) with CBX. They may be
doing another version of C++Builder with VCL but the new compiler will
only be useful in that if they add the VCL required extensions to it
(something the preview didn't have). The new compiler was intended for
wxWindows, but that work has since been put on hold and Borland haven't
released any details as it if/when they will do a new C++ product for
Desktop development.

A shame as the compiler did seem promising and the CBX IDE has some very
nice touches (although in v1, some missing features too).

Cheers

Russell
Nov 17 '05 #28

P: n/a
On Thu, 08 Jul 2004 19:09:43 +0200, Stefan Slapeta
<st************@slapeta.com> wrote:
tom_usenet wrote:

Nonsense - in the expression "g(t)" g is a dependent name, so lookup
is deferred. IOW, g(int) is called.


Maybe you should try it out before you talk about nonsense. And - read
my postings.


Whoops, my apologies - "int" has no associated namespaces, so ADL
doesn't find g(int) in the global namespace. I should have read your
earlier post.

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Nov 17 '05 #29

P: n/a
Carl Daniel [VC++ MVP] <cp*****************************@mvps.org.nospam > wrote:
[...] two-phase lookup is related to export and
that MS would consider implementing it when there's sufficient market demand
for it [...]
Consider me demanding very loudly, then.

Recently, I more and more find myself
developing template code using CodeWarrior
on the Mac and porting the code back to
VC, as CW has this feature. Maybe it's just
that, as I get deeper into template stuff,
I am doing more weird stuff -- but porting
template code /from/ VC /to/ the any other
compiler is becoming a major pain. It is
bad enough now that I put up with using CW
on the Mac, where I need the mouse so much.
(And I hate that!)
-cd


Schobi

--
Sp******@gmx.de is never read
I'm Schobi at suespammers dot org

"Sometimes compilers are so much more reasonable than people."
Scott Meyers
Nov 17 '05 #30

This discussion thread is closed

Replies have been disabled for this discussion.