Bug in VS 2003.Net - Template parameter deduction

[Henrik Ullerichs]

The following gives you two bugs.

Just create a default console project, and paste it at the bottom of the file with _tmain.

e:\Src\C\BlobHolderTest\BlobHolderTest.cpp(44) : fatal error C1001: INTERNAL COMPILER ERROR
(compiler file 'msc1.cpp', line 2701)


e:\Src\C\BlobHolderTest\BlobHolderTest.cpp(49) : error C2914: 'makeConstObject' : cannot deduce template argument as
function argument is ambiguous
e:\Src\C\BlobHolderTest\BlobHolderTest.cpp(49) : error C2784: 'void makeConstObject(const C &,ITR (__thiscall C::*
)(void) const,size_t (__thiscall C::* )(void) const)' : could not deduce template argument for 'const T2 &' from
'CharBuf'
e:\Src\C\BlobHolderTest\BlobHolderTest.cpp(29) : see declaration of 'makeConstObject'

(commont-out line 44 to get the second).

It compiles with Comeau


Used Visual studio.net pro version 7.1.3088, dotnet framework 1.1.4322



template <class T> class MyBuffer {
public:
size_t size() const { return length; };
const T* data () const { return buffer; };
T* data () { return buffer; };

private:
T *buffer;
size_t length;
};


template <typename ITR,typename C>
void makeConstObject(const C& container, ITR (C::*get_begin)() const, size_t (C::*get_size)() const) {
}
template <typename ITR,typename C>
void makeObject(C& container, ITR (C::*get_begin)(), size_t (C::*get_size)() const) {
}

void test() {
typedef std::vector<char> CharVec;
typedef CharVec::const_iterator CharVecCITR;
typedef CharVec::iterator CharVecITR;
CharVec v;
makeConstObject<CharVecCITR>(v, &CharVec::begin, &CharVec::size);
makeObject<CharVecITR>(v, &CharVec::begin, &CharVec::size);

std::string hello("Hello");
makeObject(hello, &std::string::begin, &std::string::size); // <---- line 44

typedef MyBuffer<char> CharBuf;
CharBuf cb;
makeObject<char *>(cb, &CharBuf::data, &CharBuf::size);
makeConstObject<const char *>(cb, &CharBuf::data, &CharBuf::size); // <---- æome 49
}



Henrik Ullerichs

 

[David Lowndes]

Henrik,

The problem reproduces with the Whidbey alpha compiler, so I'll try to
pass on your report to MS.

Dave

 

[Patrick Bennett]

Nothing against you Dave, bug I've seen numerous mentions of bug reports
re. VC 7.1 as to whether or not it is reproducible with Whidbey. As a
7.1 user, I really don't care if it works in Whidbey or not. Whidbey
isn't available and won't be available for some time. Even when it is
released, upgrading to a new compiler release is not something taken on
lightly.

VC 7.1 users need fixes now.

Where is the much-needed Service Pack?

 

[Bo Persson]

Nothing against you Dave, bug I've seen numerous mentions of bug reports
re. VC 7.1 as to whether or not it is reproducible with Whidbey. As a
7.1 user, I really don't care if it works in Whidbey or not. Whidbey
isn't available and won't be available for some time. Even when it is
released, upgrading to a new compiler release is not something taken on
lightly.

VC 7.1 users need fixes now.

Where is the much-needed Service Pack?

We haven't seen any service packs what so ever since VC6SP5 in the year
2000. A service pack for 7.0 was to be released "soon after" the release of
7.1.

All this was expected to be fixed this year with a new Windows SQL Server
release and the accompanying .NET 2004 compiler (Whidbey). Unfortunately
there has been a slight delay in the server release (just another year,
nothing much), so the new preliminary name is now .NET 2005.

Can you see some pattern evolving here?


I can see the "synched releases" policy backfire here, because in reality it
means that the guys with most problems set the release date for the entire
company.


Bo Persson

 

[Carl Daniel [VC++ MVP]]

Nothing against you Dave, bug I've seen numerous mentions of bug
reports re. VC 7.1 as to whether or not it is reproducible with
Whidbey. As a
7.1 user, I really don't care if it works in Whidbey or not. Whidbey
isn't available and won't be available for some time. Even when it is
released, upgrading to a new compiler release is not something taken
on lightly.

VC 7.1 users need fixes now.

Then call product support, make a case for how a bug or bugs is severely
impacting your work, and request a hotfix. That's the only way you'll get a
patch.

Where is the much-needed Service Pack?

Even if a service pack for VC7.1 was released, service packs by definition
contain only hotfixes that have already been made - unless you make your
case with product support, it's likely that your favorite bug wouldn't be
fixed in a service pack either.

I know that whether something's fixed in Whidbey is of little consequence to
the VC7{.1} user, but the reality is that that's where the VC team is
spending their time right now, and bugs reported against the Whidbey alpha
(or beta, once it's out) have a much better chance of actually getting
fixed.

-cd