Why? Why? Why? insufficient template implementation

[Thomas J. Clancy]

I was just wondering. After all these years of working on
Visual C++, why hasn't Microsoft yet seen fit to fully
implement the template portion of the C++ standard when so
many other vendors, both free and commercial, have, or at
least have come very close to doing so. I write code in
pure C++ and I so often have to ifdef the heck out of my
code just to get it to work in Visual C++.

Here is a simple example of what I mean:

#ifdef _WIN32
template<typename T,
template<typename Element,
typename Alloc = std::allocator<ELEM> >
class Container = std::deque >
class Stack
{
Container<T,std::allocator<T> > m_elems;
#else

template<typename T,
template<typename Element,
typename = std::allocator<ELEM> >
class Container = std::deque >
class Stack
{
Container<T> m_elems;
#endif

Note how under the _WIN32 code I need to name Alloc rather
than just setting the second typename's default, and of
course in the body, VC++ ignores the default an I have to
explicitly define Container with the element type and the
allocator type. This is just messy.

So, does anyone know why Microsoft just hasn't hired a
template expert to implement templates correctly? I
suppose that they are just trying to kill C++ as well as
everything not invented by them. Ah well. It'll be a C#
world after all. Ugggg.

Thomas J. Clancy

[Thomas Clancy]

Sorry, the code sample should read as follows

#ifdef _WIN32
template<typename T,
template<typename Element,
typename Alloc = std::allocator<Element> >
class Container = std::deque >
class Stack
{
Container<T,std::allocator<T> > m_elems;
#else

template<typename T,
template<typename Element,
typename = std::allocator<Element> >
class Container = std::deque >
class Stack
{
Container<T> m_elems;
#endif

-----Original Message-----

I was just wondering. After all these years of working onVisual C++, why hasn't Microsoft yet seen fit to fully
implement the template portion of the C++ standard when somany other vendors, both free and commercial, have, or at
least have come very close to doing so. I write code in
pure C++ and I so often have to ifdef the heck out of my
code just to get it to work in Visual C++.

Here is a simple example of what I mean:

#ifdef _WIN32
template<typename T,
template<typename Element,
typename Alloc = std::allocator<ELEM> >
class Container = std::deque >
class Stack
{
Container<T,std::allocator<T> > m_elems;
#else

template<typename T,
template<typename Element,
typename = std::allocator<ELEM> >
class Container = std::deque >
class Stack
{
Container<T> m_elems;
#endif

Note how under the _WIN32 code I need to name Alloc ratherthan just setting the second typename's default, and of
course in the body, VC++ ignores the default an I have to
explicitly define Container with the element type and the
allocator type. This is just messy.

So, does anyone know why Microsoft just hasn't hired a
template expert to implement templates correctly? I
suppose that they are just trying to kill C++ as well as
everything not invented by them. Ah well. It'll be a C#
world after all. Ugggg.

Thomas J. Clancy
.

[Carl Daniel [VC++ MVP]]

Thomas J. Clancy wrote:

I was just wondering. After all these years of working on
Visual C++, why hasn't Microsoft yet seen fit to fully
implement the template portion of the C++ standard when so
many other vendors, both free and commercial, have, or at
least have come very close to doing so.
Actually, only a single vendor (Comeau) even claims to have fully
implemented the C++ standard. VC7.1 is a huge step forward compared to
earlier versions of VC++, and future version will be better still.
I write code in
pure C++ and I so often have to ifdef the heck out of my
code just to get it to work in Visual C++.
Of course you dont - you choose to. In the example you give here, the
"MSVC" version is also 100% legal C++ code that your other compilers would
likely accept. Why not simply use that form everywhere, rather than
cluttering your code with #ifdefs?
So, does anyone know why Microsoft just hasn't hired a
template expert to implement templates correctly? I
suppose that they are just trying to kill C++ as well as
everything not invented by them. Ah well. It'll be a C#
world after all. Ugggg.

Actually, Microsoft is devoting considerable resources to supporting and
developing C++. The fact of the matter is, however, that fully supporting
templates is exremently difficult, and up until very recently, hasn't been a
customer priority. Backwards compatibility and code-generation quality are
much more important to MS's main customer base. Rest assured: the
commitment to C++ at Microsoft is very strong. VC7.1 isn't perfect, but
it's a huge improvement over VC6.

-cd

[Thomas J. Clancy]

-----Original Message-----
Thomas J. Clancy wrote:

I was just wondering. After all these years of working on Visual C++, why hasn't Microsoft yet seen fit to fully
implement the template portion of the C++ standard when so many other vendors, both free and commercial, have, or at least have come very close to doing so.
Actually, only a single vendor (Comeau) even claims to

have fullyimplemented the C++ standard. VC7.1 is a huge step forward compared toearlier versions of VC++, and future version will be better still.
The latest versions of GCC compile most of the standard
template stuff with little problem, which is why I asked
about VC++. When I write code for Linux or Unix using
GCC/G++ and then port it to windows I often have to ifdef,
even now with VC++ 7.1. This is what prompted these
questions.

I write code in
pure C++ and I so often have to ifdef the heck out of my
code just to get it to work in Visual C++.

Of course you dont - you choose to. In the example you

give here, the"MSVC" version is also 100% legal C++ code that your other compilers wouldlikely accept. Why not simply use that form everywhere, rather thancluttering your code with #ifdefs?

See my above comment. I often write based on the standard
using GCC. When porting I notice the problems and ifdef.
Yes, I could easily downgrade my code to conform to VC++
7.1 and then I could do away with ifdefs. So you are
correct here, but still, its a pain in the butt having to
see error messages regarding completely valid and standard-
conforming code.

So, does anyone know why Microsoft just hasn't hired a
template expert to implement templates correctly? I
suppose that they are just trying to kill C++ as well as
everything not invented by them. Ah well. It'll be a C# world after all. Ugggg.

Actually, Microsoft is devoting considerable resources to

supporting anddeveloping C++. The fact of the matter is, however, that fully supportingtemplates is exremently difficult, and up until very recently, hasn't been acustomer priority. Backwards compatibility and code- generation quality aremuch more important to MS's main customer base. Rest assured: thecommitment to C++ at Microsoft is very strong. VC7.1 isn't perfect, butit's a huge improvement over VC6.

I do agree about the huge improvements over VC6. And yes,
full template support is difficult, but I believe this to
not be a valid excuse for not implementing something,
especially with the resources that microsoft has at its
disposal.

I believe you are correct about the customer priority.
Most people don't really understand templates anyway and
there probably isn't much of a call for pure standards
conformance outside the academic realm, but I still don't
find this an adequate excuse for not developing a product
that conforms to the standard, especially given that the
standard is now five years old.

Although you claim that microsoft is committed to C++, for
some reason I find that difficult to believe, especially
now with C# and all the gastly extensions they've added to
C++. If anything their standards compliance seems to be
on the back burner. Now I said "seems to be." You might
be correct in your assessment. It just gets a little
frustrating when you're not committed to one
environment/one compiler and have to create portable code
and figure out the common denominator between all
compilers. :-)

Tom

[Carl Daniel [VC++ MVP]]

Thomas J. Clancy wrote:

Although you claim that microsoft is committed to C++, for
some reason I find that difficult to believe, especially
now with C# and all the gastly extensions they've added to
C++. If anything their standards compliance seems to be
on the back burner. Now I said "seems to be." You might
be correct in your assessment. It just gets a little
frustrating when you're not committed to one
environment/one compiler and have to create portable code
and figure out the common denominator between all
compilers. :-)

No denying that - it is frustrating trying to find the secret sauce that
makes your code compile across many compliers. If you haven't used them,
take a look at the Boost libraries (www.boost.org) which provide many
powerful features and which support many compilers (and, in many cases, are
riddled with annoying #ifdefs to deal with each compiler's vagueries).

Just wait for Whidbey. It think you'll be impressed with the commitment
that MS does have to C++.

-cd\

[thomas j. clancy]

-----Original Message-----
Thomas J. Clancy wrote:

Although you claim that microsoft is committed to C++, for some reason I find that difficult to believe, especially
now with C# and all the gastly extensions they've added to C++. If anything their standards compliance seems to be
on the back burner. Now I said "seems to be." You might be correct in your assessment. It just gets a little
frustrating when you're not committed to one
environment/one compiler and have to create portable code and figure out the common denominator between all
compilers. :-)
No denying that - it is frustrating trying to find the

secret sauce thatmakes your code compile across many compliers. If you haven't used them,take a look at the Boost libraries (www.boost.org) which provide manypowerful features and which support many compilers (and, in many cases, areriddled with annoying #ifdefs to deal with each compiler's vagueries).
Yes, I use boost all the time. I really like it for many
reasons. :-)
Just wait for Whidbey. It think you'll be impressed with the commitmentthat MS does have to C++.

-cd\

What is Whidbey?

[Carl Daniel [VC++ MVP]]

>> Just wait for Whidbey. It think you'll be impressed with the

commitment that MS does have to C++.

What is Whidbey?

The next version of Visual Studio. There used to be a "Visual Studio
Roadmap" posted on the MSDN site - I'm sure it's still around somewhere, but
I couldn't find a link to it with a few minutes hunting. The roadmap
outline some of the things that will be coming in Visual Studio "Whidbey".

-cd

[Carl Daniel [VC++ MVP]]

Carl Daniel [VC++ MVP] wrote:

Just wait for Whidbey. It think you'll be impressed with the
commitment that MS does have to C++.

What is Whidbey?

The next version of Visual Studio. There used to be a "Visual Studio
Roadmap"

Here it is:

http://msdn.microsoft.com/vstudio/pr...o/roadmap.aspx

-cd

[Thomas J. Clancy]

I completely and wholeheartedly agree! Thanks for backing
me up here. Still, perhaps this new Whidbey will be
better. I have some surefire tests... just try to use
loki, for example. :-)

Tom

-----Original Message-----
"Carl Daniel [VC++ MVP]" <cp******@nospam.mvps.org> wrote:

[...]
Just wait for Whidbey. It think you'll be impressed with the commitment that MS does have to C++.
I had a look at the roadmap before.
For C++ in Whidbey it talks about .NET, world-class
libraries as MFC, POGO and such. Not a single word
about C++ standards conformance.

Shall I say it again?
We do write software that runs on almost half a
dozen platforms, herding half a dozen compilers
and compiler versions. The three things we are
most interested in are standard conformance,
standard conformance, and standard conformance.
C# compatibility, the .NET platform, MFC and
such don't hurt, as long as we can turn that
stuff off and the VC team doesn't spend much
time with implementing it. Everything that ought
to work on all platforms, but doesn't work on
one, is a PITA. Yes, with VC71 we even start to
find bugs in our other compilers. (With VC6 we
never got that far). But still, the more I get
into more complicated template stuff, the more I
encounter bugs and limitations. Fix these issues,
so I can write and use advanced code and libraries
using VC. Then do all the whistles and bells.
(Heck, I know how to make my IDE crash immediately.
But that's no big deal, I can easily work around
that without hurting the other platforms. But if
the compiler dies, that takes a lot of time and
clutters the code.)

-cd\

Schobi

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

"And why should I know better by now/When I'm old enough

not to?" Beth Orton
.

[Ronald Laeremans [MSFT]]

Loki was on the list of libraries we verified the 7.1 compiler with. We
shipped with no know issues in building Loki code.

Ronald Laeremans
Visual C++ team

"Thomas J. Clancy" <tc*****@netspoke.com> wrote in message
news:0b****************************@phx.gbl...

I completely and wholeheartedly agree! Thanks for backing
me up here. Still, perhaps this new Whidbey will be
better. I have some surefire tests... just try to use
loki, for example. :-)

Tom

-----Original Message-----
"Carl Daniel [VC++ MVP]" <cp******@nospam.mvps.org> wrote:

[...]
Just wait for Whidbey. It think you'll be impressed with the commitment that MS does have to C++.

I had a look at the roadmap before.
For C++ in Whidbey it talks about .NET, world-class
libraries as MFC, POGO and such. Not a single word
about C++ standards conformance.

Shall I say it again?
We do write software that runs on almost half a
dozen platforms, herding half a dozen compilers
and compiler versions. The three things we are
most interested in are standard conformance,
standard conformance, and standard conformance.
C# compatibility, the .NET platform, MFC and
such don't hurt, as long as we can turn that
stuff off and the VC team doesn't spend much
time with implementing it. Everything that ought
to work on all platforms, but doesn't work on
one, is a PITA. Yes, with VC71 we even start to
find bugs in our other compilers. (With VC6 we
never got that far). But still, the more I get
into more complicated template stuff, the more I
encounter bugs and limitations. Fix these issues,
so I can write and use advanced code and libraries
using VC. Then do all the whistles and bells.
(Heck, I know how to make my IDE crash immediately.
But that's no big deal, I can easily work around
that without hurting the other platforms. But if
the compiler dies, that takes a lot of time and
clutters the code.)

-cd\

Schobi

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

"And why should I know better by now/When I'm old enough

not to?"

Beth Orton
.

[Hendrik Schober]

"Brandon Bray [MSFT]" <br******@online.microsoft.com> wrote:

Hendrik Schober wrote:

I've never used Loki. However, I'm doing some
template metaprogramming myself nowadays (which
does include some stuff I learned from MCD) and
I do run into ICEs. I can surely imagine that,
using Loki, one runs into compiler bugs as well.
Hi Hendrik,
As Ronald said, we harnessed Loki before we shipped VC7.1. The version
available built without error.

And what does that mean? You can parse the
headers? No big deal in this millenium, when
you don't even lookup non-dependend names.
It's not that VC71 ICEs with simple or even
more complicated templates. But when you use
stuff like this all the time, you'll find
errors.
It is possible that changes made to Loki
since 7.1 shipped now cause errors, but looking through our bug database
there are no active or postponed issues regarding Loki.
I don't know, since I don't use Loki. But
since Loki uses quite advanced template
stuff, I'm sure using it one would run
into errors similar to the ones I find.
If you are coming across ICEs on your own, they really need to be reported.
Otherwise, it makes it impossible to fix them.
If I can get something to reproduce, I post
it here. Sometimes, however, I cannot find
the time to cut it down to a repro case or
even to find out whether it's my fault (and
one of the other compilers I use) or VC's.
Then I simply need something that works ASAP.
If these are bugs, you won't hear them from
me.

(Also as someone else already has complained
about, I have no idea where the bugs should
go offically. All I can find is the payed
support. Yes, I know that you won't charge
if I found a real bug in your product. But
my boss isn't going to take this risc twice
a month. I think that's the same with other
bosses. So whoever doesn't use these newsgroup
won't report bugs that way, no matter how
serious they are.
I really think there should be an easier way
to report bugs. Because that will help you to
fix your product.)
Cheerio!
Prost! <g>
Brandon Bray Visual C++ Compiler

Schobi

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

"And why should I know better by now/When I'm old enough not to?"
Beth Orton

[Brandon Bray [MSFT]]

Patrik Ellren wrote:

This might not be relevant to your discussion, but one area where I feel
you can get better is to provide a simple method of reporting bugs and
browsing already reported ones.

Hi Patrik,
I certainly understand your desire. I have certainly advocated this to as
many people as I can. There are plans to improve this in future products (we
actually have an entire team devoted to this kind of thing). I'm sure over
time it will get much better.

The best advice I have for now is to get involved with beta releases as soon
as possible. The sooner a bug is reported in a beta, the easier it is for us
to fix it.

Thanks for providing your feedback. Cheerio!

--
Brandon Bray Visual C++ Compiler
This posting is provided AS IS with no warranties, and confers no rights.

[Carl Daniel [VC++ MVP]]

Brandon Bray [MSFT] wrote:

Patrik Ellren wrote:

This might not be relevant to your discussion, but one area where I
feel you can get better is to provide a simple method of reporting
bugs and browsing already reported ones.

Hi Patrik,
I certainly understand your desire. I have certainly advocated this
to as many people as I can. There are plans to improve this in future
products (we actually have an entire team devoted to this kind of
thing). I'm sure over time it will get much better.

The best advice I have for now is to get involved with beta releases
as soon as possible. The sooner a bug is reported in a beta, the
easier it is for us to fix it.

To add to what Brandon said -

Many regulars on these ngs (including many MVPs and all VC team members)
will be participating in any beta programs that are ongoing - so posting on
the newsgroups is more effective than you might think at getting bugs
noticed. I, and I assume many others, try to keep an eye out for things
reported on the ngs about current product that may be applicable to ongoing
beta programs. Whever I see such a posting, if I can reproduce the problem
with whatever beta I might have access to, I'll report the bug to the beta
program.

Of course, getting involved with the beta programs yourself offers you a
more direct route into the process. Knowledgebase article 33814 outlines
the process by which you can apply to be a beta tester.

http://support.microsoft.com/default...kb;en-us;33814

-cd

[Hendrik Schober]

"Carl Daniel [VC++ MVP]" <cp******@nospam.mvps.org> wrote:

[...] I, and I assume many others, try to keep an eye out for things
reported on the ngs about current product that may be applicable to ongoing
beta programs. Whever I see such a posting, if I can reproduce the problem
with whatever beta I might have access to, I'll report the bug to the beta
program.
This is all very great and I know that I own a
lot to the MVPs here. (I'm sure you reproduced
and reported 90% of all the issues I ever posted
here.)
I know that here is a great place to report bugs.

However, if you just think of how many copies of
VC are sold, and how many people post here, you
will have to agree that the overwhelming majority
of VC users never show up here. (Actually, that
is pretty good, as I have problems with this
group's posting volume anyway...)
All those users, if they find a problem, and try
to report it, either find these newsgroups, but
don't want to post, or don't find anything at
all.
Thinking of how I searched the website before I
found these groups, I suspect they never find
anything but the payed-per-incidence service and
give up.

What I expect is, on the VC website, a link
"Report bug", that leads to a form which I can
fill in, hit the sent button, and get an ID back,
that I can then use to track the bug's status
later on. And if the bug's status ever says
"can't reproduce" or something ugly, I need a
link right there that allows me to provide
further information (or probably will get me
into contact with a human beeing) to re-open
the bug.
Heck, this all could probably even be found in
VS' help menu!

I know that this could bring in a lot of false
reports and I know that this is a problem.
However, we're not talking Word or Excel here.
This is a product for developers, and I'd suspect
that the majority of them would know what a bug
report should be.
[...]
-cd

Schobi

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

"And why should I know better by now/When I'm old enough not to?"
Beth Orton