Bug in VS 2003.Net - Template parameter deduction

  • Thread starter Thread starter Henrik Ullerichs
  • Start date Start date
H

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
 
Henrik,

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

Dave
 
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? :(
 
Patrick Bennett said:
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
 
Patrick said:
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
 
Back
Top