Well known compiler bugs ignored by Microsoft?

112 views
Skip to first unread message

stefan_h...@my-deja.com

unread,
Jan 31, 2000, 3:00:00 AM1/31/00
to
As I am currently wrestling with template troubles caused by various
VC6 SP3 bugs (features?), I feel I have to get this off my chest:

While searching through the news archives I found various references to
"kown bugs" in VC6 which don't seem to make it into the Microsoft
Knowledge Base. For example there is the famous member function
template problem that requires you to have the template argument in the
function signature, or various C1001 occurrences, or LNK2001/2005
problems, or even undocumented error messages. Most of these have
already been described months ago, but are still aren't mentioned in
the knowledge base.

Does anybody know why that is?

- Is Microsoft censoring bug reports?
- Do they have a huge backlog of reports and no time to process them?
- Are they not considering them bugs?
- Are they only publishing bugs they know a workaround for?
- Are they only publishing bugs they plan to fix in the next release?
- Or is it just that they don't care?

A knowledge base that ain't up to date is not worth much to me. When I
start to ask the net before I look into the knowledge base then the
latter becomes superfluous.

Any comments?

Ah, by the way, is anybody keeping a more serious bug list or FAQ for
VC6 and willing to share it on the net?

Stefan


Sent via Deja.com http://www.deja.com/
Before you buy.

Erik Funkenbusch

unread,
Jan 31, 2000, 3:00:00 AM1/31/00
to
I don't know if MS is not documenting them or not. I can say this, just
because people talk about a "well known" bug doesn't mean that anyone has
actually reported it to MS.

<stefan_h...@my-deja.com> wrote in message
news:8741fd$f7f$1...@nnrp1.deja.com...

Jim Marshall

unread,
Jan 31, 2000, 3:00:00 AM1/31/00
to
What Erik says is true - I have seen many posts which refer to a well known
bug, but MS doesn't seem to know anything about it (I have a couple of
friends at MS who I talk to now & again).

Additionally I would suspect it is more a shortage of people or time to
write and review articles. Last I checked (a couple years ago) the tech
support people did the bulk of the article writing and they are often busy
doing other stuff (like helping customers). I work in tech support (not for
MS) and believe me, I would prefer to write an article then answer the
phone....

--
Homepage (freeware stuff):
http://ourworld.compuserve.com/homepages/jjmarshall/
Java Stuff: http://www.dynamoguru.com/


stefan_h...@my-deja.com

unread,
Feb 1, 2000, 3:00:00 AM2/1/00
to
In article <eNQpw#Gb$GA.1536@cppssbbsa06>,

"Jim Marshall" <Jim_Ma...@msn.com> wrote:
> What Erik says is true - I have seen many posts which refer to a well
known
> bug, but MS doesn't seem to know anything about it (I have a couple of
> friends at MS who I talk to now & again).
>

Well, it would suffice if someone at Microsoft did a search using
deja.com every month or so. You don't have to follow all relevant
newsgroups on a daily basis to catch the more important bugs.

Furthermore, last autumn I logged a bug together with a workaround
using the bug reporting facility on Microsoft's website. I didn't get
any kind of reply, not even an automatically generated one telling me
that they'd received it. From what I can tell it could just as well
have ended up in bit-heaven. So far, MSDN does not contain a
corresponding bug report article, either. If other people have made the
same experience, I wouldn't be surprised if they conclude that
reporting a bug to Microsoft isn't worth the bother.

> Additionally I would suspect it is more a shortage of people or time
to
> write and review articles. Last I checked (a couple years ago) the
tech
> support people did the bulk of the article writing and they are often
busy
> doing other stuff (like helping customers). I work in tech support
(not for
> MS) and believe me, I would prefer to write an article then answer the
> phone....
>

Sure, but there are (should be) two classes of people at Microsoft
interested in bug reports: The tech support people and the compiler
developers. I can see that the former are often swamped with phone
calls that prevent them from writing articles, but the latter could do
that and at the same time learn about the bugs that need fixing in the
next release. But maybe that's just not the way it is organized...

Bobby Mattappally

unread,
Feb 1, 2000, 3:00:00 AM2/1/00
to
Stefan,

. For example there is the famous member function
> template problem that requires you to have the template argument in the
> function signature, or various C1001 occurrences, or LNK2001/2005
> problems, or even undocumented error messages. Most of these have

This is already documented in the following article:

BUG: Explicitly Specified Template Functions Not Overloaded [visualc]
ID: Q240871
http://support.microsoft.com/support/kb/articles/Q240/8/71.ASP

Please also refer to:
INFO: C++ Standard Noncompliance Issues with Visual C++ 6.0 [visualc]
ID: Q243451
http://support.microsoft.com/support/kb/articles/q243/4/51.asp

Hope this helps.
Thank you,
Bobby Mattappally
Microsoft Visual C++ Support

stefan_h...@my-deja.com

unread,
Feb 2, 2000, 3:00:00 AM2/2/00
to
In article <O4159LPb$GA.266@cppssbbsa05>,
"Bobby Mattappally" <bobbym...@microsoft.com> wrote:
[...]

> This is already documented in the following article:
>
> BUG: Explicitly Specified Template Functions Not Overloaded
[visualc]
> ID: Q240871
> http://support.microsoft.com/support/kb/articles/Q240/8/71.ASP
>
> Please also refer to:
> INFO: C++ Standard Noncompliance Issues with Visual C++ 6.0
[visualc]
> ID: Q243451
> http://support.microsoft.com/support/kb/articles/q243/4/51.asp
>

Cool, I hadn't found these, thanks. Must have been added recently. Do
you also happen to know a workaround for the problem I described in a
post on this newsgroup a couple of days ago? It is about static member
function templates and I haven't found a corresponding KB article yet.

BTW, when I submit a bug report to MS, what is the procedure? Where do
I send it to, Do I get logging messages/confirmations back, how can I
track what's being done with it?

> Hope this helps.
> Thank you,
> Bobby Mattappally
> Microsoft Visual C++ Support

It did. Thanks, Bobby.

Oliver (no email, sorry)

unread,
Feb 3, 2000, 3:00:00 AM2/3/00
to
> We will consider all reproducible bug reports and work on documenting them
> in the Microsoft Knowledge Base. However, we are not able to guarantee
that
> any one problem will be resolved in any specific version of Visual Studio.

Actually, I reported reproducible bugs to Microsoft. Whether via web or
one-one, it was an almost complete black hole experience. Filling out the
web form provides no response or tracability at all. While one-one support
at least could confirm that a bug is reproducible, this is of little value.

When investing the time and effort required to isolate, reproduce, document
and report a bug, the minimum reward I would expect is that the bug be
traceable for me (e.g. by making it into the knowledge base and receiving a
response mentioning the article number).

In my view, the current state of Microsoft's policy and organisation ignores
the value of customers' investments into bug reporting.

Since MSVC++ Version 5, I have collected more than 20 reproducible bugs,
which did not appear in the knowledge base at the time of their detection
(as far as I was aware). However, having made such bad experiences, I am
reluctant to report these. (Of course, I could always post them here in case
any one is interested.)

Just my 2 cents.

Oliver
(email address is invalid to avoid spam - please respond to the group)

Todd Greer

unread,
Feb 4, 2000, 3:00:00 AM2/4/00
to
"Oliver (no email, sorry)" <so...@no.spam> writes:

> Since MSVC++ Version 5, I have collected more than 20 reproducible bugs,
> which did not appear in the knowledge base at the time of their detection
> (as far as I was aware). However, having made such bad experiences, I am
> reluctant to report these. (Of course, I could always post them here in case
> any one is interested.)

Perhaps this newsgroup could have a periodically posted FAQ that
included a collected list of MSVC bugs. I'd be happy to contribute
several bugs. Would anyone be willing to maintain the list?

--
Todd Greer <tgr...@acm.org>

J. Wesley Cleveland

unread,
Feb 7, 2000, 3:00:00 AM2/7/00
to

"Oliver (no email, sorry)" wrote:
[snip]

> Since MSVC++ Version 5, I have collected more than 20 reproducible bugs,
> which did not appear in the knowledge base at the time of their detection
> (as far as I was aware). However, having made such bad experiences, I am
> reluctant to report these. (Of course, I could always post them here in case
> any one is interested.)

I would be very interested in any bugs in VC6 sp3.

Oliver (no email, sorry)

unread,
Feb 10, 2000, 3:00:00 AM2/10/00
to
J. Wesley Cleveland <jw...@oro.net> wrote:

> I would be very interested in any bugs in VC6 sp3.

Below is my list of bugs not confirmed to be fixed yet. It may well be that
some of them were documented by MS and/or fixed in the meantime without
being noticed by me. I am sorry that some compiler messages are in German
(you can look up the translation by error number).

Hope this helps.

Oliver
(email address is invalid to avoid spam - please respond to the group)

============================================================================
P26: Conversion operator Target*() is ignored
*** present in MSVC++ 5.0 SP2

Reference.h and DB_Reference.h contained a conversion to pointer like
this:
operator Target*() const;

Comparing a Reference to a constant pointer (e.g. this) yielded this
error:

C:...\P26.cpp(27) : error C2593: 'operator !=' is ambiguous

Workaround: Changing the declaration this way resolved the problem:
operator Target* const() const;

--- P26.cpp ---

// P26.cpp

template <class Target>
class Reference
{
public:
// this declaration will produce the error below:
operator Target*() const;

// this declaration will make it work
file://operator Target* const() const;
};


class A
{
};


void p26()
{
A* const p_a = 0;
Reference<A> r_a;

// error C2593: 'operator !=' is ambiguous
r_a != p_a;
}
---


============================================================================
P30: Derived template class generates error C2555
*** present in MSVC++ 5.0 SP2

When a derived class is also a template class, error 2555 may be generated
although it shouldn't:

C:...\P30.cpp(26) : error C2555: 'Derived::new_object' : overriding
virtual function differs from 'Base::new_object' only by return type or
calling convention

A non-template class as derived class does not show this problem. For
details
see P30.cpp.

Workaround: Declare a typedef for the return type of the offending
operation.

--- P30.cpp ---

class Concrete_Target
{
};


template <class Target>
class Reference
{
public:
Target* _target;
};


class Base
{
virtual Reference<Concrete_Target> new_object() = 0;
};


template <class Generic>
class Derived
: public Base
{
// error C2555: 'Derived::new_object' : overriding virtual function
differs from 'Base::new_object' only by return type or calling convention
virtual Reference<Concrete_Target> new_object();
};
---


============================================================================
P31: Using iterator typedefs in <vector> in a template class generates C1001
*** present in MSVC++ 5.0 SP2

For details see P31.cpp.

C:...\P31.cpp(28) : fatal error C1001: INTERNAL COMPILER ERROR
(compiler file 'msc1.cpp', line 1188)
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more
information

Workaround: Use the allocator typedefs for iterator and const_iterator.

--- P31.cpp ---

#include <vector>

template <class Element>
class Vector
{
};


template <class Element>
class Vector_Iterator
{
public:
Vector_Iterator
(Vector<Element>& vector);

Vector_Iterator
(std::vector<Element>::iterator& i);
};


void p31()
{
std::vector<long>::iterator i;

new Vector_Iterator<long>(i);
}

---


============================================================================
P32: A stream manipulator operation defined as class member generates C1001
*** present in MSVC++ 5.0 SP2

Declaring a stream manipulator as (static) member of its stream class
may generate C1001. The error appears when another stream insertion
operator (of an unrelated class) is declared accepting a template argument
and only when the manipulator is actually used:

C:...\P32.cpp(32) : fatal error C1001: INTERNAL COMPILER ERROR
(compiler file 'msc1.cpp', line 1188)
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more
information

For details see P32.cpp.

Workaround:
- Rename the original manipulator (m).
- Declare a static operation pointer (mp) to use as string manipulator.
- Assign m to mp.

--- P32.cpp ---

// P32.cpp

class Stream_1
{
public:
Stream_1& operator<<(Stream_1& (*operation)(Stream_1& stream));

static Stream_1& end_line(Stream_1& stream);
};

template<class T>
class d_Ref
{
};

class Stream_2
{
};

template<class T>
Stream_2& operator<<(Stream_2& p1, const d_Ref<T>& p2)
{
return p1;
}

void p32()
{
Stream_1 description;

// The following line generates C1001:
description << Stream_1::end_line;
}
---


============================================================================
P33: Using the template comparison operators in <utility> breaks std::string
*** present in MSVC++ 5.0 SP2

The comparison operators in namespace std::rel_ops of <utility> break
string comparisons:

C:...\P33.cpp(25) : error C2667: '!=' : none of 2 overload have a best
conversion
C:...\P33.cpp(25) : error C2593: 'operator !=' is ambiguous

For details see P33.cpp.

--- P33.cpp ---

// P33.cpp

#include <string>

void p33_without_utility()
{
std::string left;
std::string right;

left != right;
left < right;
left > right;
left >= right;
}

#include <utility>
using namespace std::rel_ops;

void p33_with_utility()
{
std::string left;
std::string right;

// The following lines generate C2667, C2593 (each):
left != right;
left <= right;
left > right;
left >= right;
}
---


============================================================================
P34: Warning C4211 (redefined extern as static) generated erroneously
*** fixed in MSVC++ 5.0 SP2

The initialization of a static template class member generates C4211:

C:...\P34.cpp(15) : warning C4211: nonstandard extension used : redefined
extern to static

For details see P34.cpp.

Workaround: Use "#pragma warning(disable: 4211)". The pragma must not be
reset to its default to be effective.

--- P34.cpp ---

// P34.cpp

template <class Scalar>
class Infinity_Scalar
{
public:
static const Infinity_Scalar<Scalar> zero;
};


// This definition generates warning C4211:
template <class Scalar>
const Infinity_Scalar<Scalar> Infinity_Scalar<Scalar>::zero
= Infinity_Scalar<Scalar>();


template Infinity_Scalar<double>;
---


============================================================================
P37: Using a constant of a template class as default value does not compile
*** present in MSVC++ 6.0 SP3

When a template class member constant is used as a default value for
an argument of another class' member function, a compilation generates
these errors:

C:...\P37.cpp(21) : error C2039: 'null' : Ist kein Element von '`global
namespace''
C:...\P37.cpp(21) : error C2146: Syntaxfehler : Fehlendes ';' vor
Bezeichner 'null'
C:...\P37.cpp(21) : error C2275: "Smart_Pointer<class Font>" : Ungültige
Verwendung dieses Typs als Ausdruck
C:...\P37.cpp(21) : fatal error C1903: Weiterverarbeitung nach
vorhergehendem Fehler nicht moeglich; Kompilierung wird abgebrochen.

See P37.cpp.

--- P37.cpp ---

// P37.cpp

template <class Target>
class Smart_Pointer
{
public:
static const Smart_Pointer<Target> null;
};


class Font
{
};


class View
{
public:
void initialize
(const Smart_Pointer<Font>& font = Smart_Pointer<Font>::null);
};
---


============================================================================
P39: Template classes (in generic form) cannot be declared as friends
*** present in MSVC++ 5.0 SP2

Declaring a template friend (section 14.12 of the ANSI-C++ draft) results
in this error:

C:...\P39.cpp(13) : error C2059: syntax error : '<end Parse>'
C:...\P39.cpp(14) : error C2238: unexpected token(s) preceding ';'

See P39.cpp.

--- P39.cpp ---

// P39.cpp

template <class Type>
class Friend_Of_C
{
};

class C
{
// This statement generates C2059 followed by C2238.
template <class Type>
friend Friend_Of_C;
};
---


============================================================================
P40: Wrong member function called when using nested classes
*** present in MSVC++ 6.0 SP3

A nested class is derived from a base class with an identical name at
the deepest nesting level. When a derived class function tries to call
its base class version, it will actually itself. The resulting recursion
ultimately leads to a stack overflow. See P40.cpp.

Related KB article:
Q143082: BUG: Wrong Pointer Value When Nested Classes Have Same Name
(Contrary to what the article says, the bug still exists in MSVC++ 6.0
SP3.)

Workaround: Define the classes with unique names at the outermost level.
Use a nested typedef declaration replacing the original class declaration.

--- P40.cpp ---

// P40.cpp

#include <iostream>
using namespace std;


class A
{
public:
class Nest
{
public:
virtual void showme()
{
cout << "A::Nest::showme()" << endl;
}
};
};


class B
: public A // just to show the intended structure - not necessary
{
public:
class Nest
: public A::Nest
{
public:
typedef A::Nest Base; // necessary to work around C2352 (see P41)

virtual void showme()
{
Base::showme();
cout << "B::Nest::showme()" << endl;
}
};
};


void main()
{
B::Nest b;

b.showme();
}
---


============================================================================
P41: Calling a base class function generates C2352 when using nested classes
*** present in MSVC++ 5.0 SP2

A nested class is derived from a base class with an identical name at
the deepest nesting level. A derived class function should call its base
class version. This error results:

C:...\P41.cpp(27) : error C2352: 'A::Nest::showme' : illegal call of
non-static member function

See P41.cpp

Workaround: Avoid deriving nested classes with the same name (see P40).

--- P41.cpp ---

// P41.cpp

class A
{
public:
class Nest
{
public:
virtual void showme()
{
}
};
};


class B
: public A // just to show the intended structure - not necessary
{
public:
class Nest
: public A::Nest
{
public:
virtual void showme()
{
A::Nest::showme();
}
};
};
---


============================================================================
P45: Wrong this pointer when function called virtually from within
constructor
*** present in MSVC++ 6.0
*** reported to Microsoft via Web 98/05/27

When a function is called virtually from within a constructor in a
multiple
inheritance / virtual base class scenario, the <this> pointer is
incorrect.
A prerequisite for the incorrect behavior seems to be that the object in
question is not fully constructed yet.

Example: View <- scene() declared
/ \
Attribute_View Scene <- scene() redeclared
\ /
Text_View <- View::scene() called virtually
| in constructor
Number_View

The virtual call to View::scene() from withing Text_View's constructor
correctly calls Scene::scene(), but passes a wrong this pointer.

For details see P45.cpp.

The inheritance graph must match the one above to reproduce. If
Number_View
is removed, the problem will not happen.

This problem is similar to KB article ID Q151500, but occurs regardless of
a "global optimization" setting and is not fixed.

--- P45.cpp ---

// P45.cpp


class Scene;

class View
{
public:
View()
: _id1(1)
{
}

virtual Scene* scene()
{
return 0;
}

int _id1;
};


class Attribute_View
: public virtual View
{
public:
Attribute_View()
: _id2(2)
{
}

int _id2;
};


class Scene
: public virtual View
{
public:
Scene()
: _id3(3)
{
}

Scene* scene()
{
if (_id3 != 3)
throw "this pointer incorrect"; // <- this is thrown
return this;
}

int _id3;
};


class Text_View
: public Attribute_View,
public Scene
{
public:
Text_View()
: _id4(4)
{
View* this_view = this;

_id4 = this_view->scene()->_id3 + 1;
}

int _id4;
};


class Number_View
: public Text_View
{
public:
Number_View()
: _id5(5)
{
}

int _id5;
};


void main()
{
new Number_View();
}
---


============================================================================
P50: Nested typedefs for const / non-const template classes produces C2664
*** present in MSVC++ 5.0 SP2

Using nested typedefs (embedded in a template class List) referring to
the same template class (Standard_Iterator) with const and non-const
types produces this error:

C:...\P50.cpp(35) : error C2664:'Standard_Iterator<class
List<int>,int>::Standard_Iterator<class List<int>,int>(class List<int> &)' :
cannot convert parameter 1 from 'const class List<int>' to 'class
List<int> &'

Obviously, the compiler attempts to instantiate the wrong (con-const)
template.

Switching the typedef declarations makes the problem disappear.

For details see P45.cpp.

--- P50.cpp ---

// P50.cpp

template <class Collection, class Element>
class Standard_Iterator
{
public:
Standard_Iterator
(Collection& collection);
};


template <class Collection, class Element>
inline Standard_Iterator<Collection, Element>::Standard_Iterator
(Collection& collection)
{
}


template <class Element>
class List
{
public:
// Switching the order of the following two typedefs will make it work.

typedef Standard_Iterator<List<Element>, Element>
Iterator;

typedef Standard_Iterator<const List<Element>, const Element>
Const_Iterator;
};


void showme
(const List<int>& my_list)
{
List<int>::Const_Iterator i(my_list);
}


void main()
{
}
---


============================================================================
P52: When I assign a shorter string to an existing string which originally
contained a longer string, the assignment corrupts the heap.
*** present in MSVC++ 5.0 SP2
*** probably fixed in Dinkumware STL fixes

Information source: MSVC++ Web Site, STL FAQ

This problem is caused due to a bug in the Standard C++ Library
basic_string class implementation.

To workaround the problem call the string::erase member function
before assigning the new value to the existing string.

--- P52.cpp ---

// P52.cpp

file://Compile options: /GX

#include <crtdbg.h>
#include <string>

using namespace std;

int main()
{
string str, str2;
str = "abcdefghijklmnopqrstuvwxyzabcdefghij" ;
str2 = str;
file://Workaround, uncomment the following line
file://str.erase() ;
str = "zyxw" ;
_CrtCheckMemory() ;

return(0);
---


============================================================================
P53: CTreeCtrl::Expand unexpectedly returns nonzero on Windows 95
*** present in MSVC++ 5.0 SP2

After transferring an application developed unter NT 4.0 SP 3 to Windows
95
(Version 4.00.950a) the operation CTreeCtrl::Expand unexpectedly returns
nonzero. Exactly the same binary works under NT.

Workaround: Ignore the return code.


============================================================================
P57: Nested classes within template classes do not compile
*** present in MSVC++ 5.0 SP3

A nested class defined within a template class does not compile.
At least three different errors have been observed:
1. Call to a nested class constructor defined inline (Variant 1 of
P57.cpp):
P57.cpp(47) : error C2514: 'Outer<class Other>::Inner' : class has no
constructors
2. Defining a nested class constructor outline (Variant 2 of P57.cpp):
P57.cpp(38) : error C2039: '__ctor' : is not a member of 'Inner'
3. Call to a nested class constructor defined inline:
C1001 (not reproduced here).

See P57.cpp for details.

Workaround: Avoid using nested classes within template classes. Make the
fomerly nested class a top-level template class on its own.

--- P57.cpp ---

// P57.cpp

// Set VARIANT to 1 or 2 to observe different compiler errors:
#define VARIANT 1


class Other
{
};


template <class Argument>
class Outer
{
public:
class Inner;

void operation();
};


template <class Argument>
class Outer<Argument>::Inner
{
public:
#if VARIANT == 1
Inner
(Argument* argument)
{
}
#else
Inner
(Argument* argument);
#endif
};


#if VARIANT == 2
template <class Argument>
void Outer<Argument>::Inner::Inner
(Argument* argument)
{
}
#endif


template <class Argument>
void Outer<Argument>::operation()
{
new Inner(new Argument);
}


template class Outer<Other>;
---


============================================================================
P59: Enum bit field yields improper values for enumerator using the sign bit
*** present in MSVC++ 5.0 SP3

An enumeration defined as a bit field does not convert its signed
enumerators properly. They convert into negative values which are then
regarded as invalid.

E.g. if there are 2 bits and three enumerators, their binary values would
be: 00, 01, 10. The third enumerator is using the sign bit. It will be
converted to -2, while the full size enumerator's value is 2 (positive).

See P59.cpp.

Workaround: Declare enumeration bit fields with one extra bit. This
makes the sign bit stay zero at all times.

--- P59.cpp ---

// P59.cpp

#include <iostream>

using namespace std;


const int enumeration_bits = 2; // setting this to 3 will make it work


enum Enumeration
{
enumerator_0,
enumerator_1,
enumerator_2
};


class C
{
public:
Enumeration _enumeration : enumeration_bits;
};


void main()
{
C c;

c._enumeration = enumerator_2;

cout << "enumeration bits = " << enumeration_bits << endl;

cout << "c._enumeration = " << c._enumeration << endl;
cout << "enumerator_2 = " << enumerator_2 << endl;

if (c._enumeration == enumerator_2)
cout << "OK: c._enumeration == enumerator_2" << endl;
else
cout << "DEFECT: c._enumeration != enumerator_2" << endl;
}
---


============================================================================
P60: In-class typedef not recognized in double-derived template class
*** present in MSVC++ 6.0

A typedef defined in a base class two levels above a template class is
not recognized:

c:...\p60.cpp(30) : error C2629: 'class
Second_Derived<Argument_1,Argument_2> (' unerwartet
c:...\p60.cpp(33) : Siehe Verweis auf Instantiierung der kompilierten
Klassenvorlage 'Second_Derived<Argument_1,Argument_2>'

See P60.cpp.

Workaround: include a using declaration for the typedef in the
intermediate
base class (see P60.cpp).

--- P60.cpp ---

// P60.cpp

#define WORKAROUND 0


class Base
{
public:
typedef long Base_ID;
};


template <class Argument_1>
class First_Derived
: public Base
{
#if WORKAROUND == 1
using Base::Base_ID;
#endif
};


template <class Argument_1, class Argument_2>
class Second_Derived
: public First_Derived<Argument_2>
{
public:
Second_Derived
(Base_ID component_id)
{
}
};


Second_Derived<int, int> cam(0L);
---


============================================================================
P63: dynamic_cast crashes when given a pointer to an object being
constructed
*** present in MSVC++ 6.0

Downcasting a virtual base class pointer will result in a crash (access
violation) when the most derived class is not fully constructed.

Example: A
| <-- virtual inheritance
B1
|
C
|
D

Constructing an object of class D, the following should be possible:
- When C is fully constructed, its this pointer is assigned to a variable
of type 'A*'.
- This pointer is then downcasted to 'B1*'.
- The downcasted B1 pointer is used to access the object.

In the example P63.cpp, the downcast yields an invalid pointer, which
produces the crash when accessed. In another scenario, the downcast itself
resulted in an access violation.

For details see P63.cpp.

The inheritance graph must match the one above to reproduce. If D
is removed or B1's inheritance from A is not virtual, the problem will not
occur.

A similar case is documented as P45.

--- P63.cpp ---

// P63.cpp

#include <iostream>


class A
{
public:
A()
: _A("A")
{
}

virtual void whoami()
{
std::cout << "I am A." << std::endl;
}

char* _A;
};


class B1
: public virtual A // removing the 'virtual' will make it work
{
public:
B1()
: _B1("B1")
{
}

virtual void whoami()
{
std::cout << "I am B1." << std::endl;
}

char* _B1;
};


class C
: public B1
{
public:
C()
: _C("C")
{
A* a = this;

std::cout << "Before dynamic_cast." << std::endl;
B1* b = dynamic_cast<B1*>(a);

std::cout << "Before using the <b> pointer." << std::endl;

// The following statement generates an access violation.
b->whoami();

std::cout << "Did we get here?" << std::endl;
}

virtual void whoami()
{
std::cout << "I am C." << std::endl;
}

char* _C;
};


class D
: public C
{
public:
D()
: _D("D")
{
}

virtual void whoami()
{
std::cout << "I am D." << std::endl;
}

char* _D;
};


void main()
{
D d;
}
---


============================================================================
P75: throw causes double call of destructor
*** present in MSVC++ 6.0 SP3

Catching an exception by reference and then rethrowing it will cause
the exception's destructor to be called twice.

This defunct behavior only occurs in a specific (and less usual)
throw/catch scenario (#2 in P75.cpp). It does not occur in the more
common scenario (#1 in P75.cpp).

For details see P75.cpp.

Source: http://www.deja.com/forms/mid.shtml - search for:
<#K#ttnu#9GA...@uppssnewspub04.moswest.msn.net>

--- P75.cpp ---

// P75.cpp

#include <iostream>


class Exception
{
public:
Exception()
{
std::cout << "Constructor: " << this << std::endl;
}

Exception
(const Exception& exception)
{
std::cout << "Copy Constructor: " << this << std::endl;
}

~Exception()
{
std::cout << "Destructor: " << this << std::endl;
}
};


void main()
{
std::cout << "begin 1 (OK)" << std::endl;

try
{
try
{
std::cout << "throw" << std::endl;
throw Exception();
}
catch (Exception& exception)
{
std::cout << "catch & rethrow" << std::endl;
throw;
}
}
catch (Exception& exception)
{
std::cout << "second catch" << std::endl;
}

std::cout << "end 1" << std::endl << std::endl;


std::cout << "begin 2 (DEFUNCT)" << std::endl;

try
{
std::cout << "throw" << std::endl;
throw Exception();
}
catch (Exception& exception)
{
try
{
std::cout << "catch & rethrow" << std::endl;
throw;
}
catch (Exception& exception)
{
std::cout << "second catch" << std::endl;
}
}

std::cout << "end 2" << std::endl;
}
---


============================================================================
P78: Static variables as template class members may generate LNK1179
*** present in MSVC++ 6.0 SP3

A LNK1179 error occurs if these preconditions are met:
- The template class takes at least two arguments.
- The template is used at least two times with identical first
and different second arguments.
- The static member variable is of an object type with at least one
base class. (In another scenario it also occurred using a member
without a base class.)

The linker shows this error:
P78.obj : fatal error LNK1179: Ungueltige oder beschaedigte Datei:
Comdat "?_cardinality_selection@?$DB_Set@VPP_Class@@$D" doppelt

For details see P78.cpp.

Workaround: Instead of a static member variable use a static member
function which returns a reference to a local static variable.

--- P78.cpp ---

// P78.cpp

class Object
{
};

class DB_Operation
: public Object // must have a base class
{
};

template <class Owner, class Element>
class DB_Set
{
public:
static DB_Operation _cardinality_selection;
};

template <class Owner, class Element>
DB_Operation DB_Set<Owner, Element>::_cardinality_selection;

class PP_Container_Class_Property
{
};

class PP_Component
{
};

class PP_Class
{
public:
DB_Set<PP_Class, PP_Container_Class_Property> _employments;
DB_Set<PP_Class, PP_Component> _components;
};


int main()
{
PP_Class u1;

return &u1._employments._cardinality_selection
== &u1._components._cardinality_selection;
}
---


============================================================================
P80: Overloading: Non-template function not preferred over template function
*** present in MSVC++ 6.0 SP3

This operation:

Base_Interface Stream& operator<<
(Stream& stream,
const Real& value);

should be preferred over this one:

template <class Non_Object>
Stream& operator<<
(Stream& destination,
const Non_Object& non_object);

MSVC++ selects the latter one (which leads to multiply defined symbols
at link time).

MSVC++ appears not to follow this ISO rule:
- 13.3.3 Best viable function

J. Wesley Cleveland

unread,
Feb 10, 2000, 3:00:00 AM2/10/00
to

"Oliver (no email, sorry)" wrote:
>

> J. Wesley Cleveland <jw...@oro.net> wrote:
>
> > I would be very interested in any bugs in VC6 sp3.
>
> Below is my list of bugs not confirmed to be fixed yet. It may well be that
> some of them were documented by MS and/or fixed in the meantime without
> being noticed by me. I am sorry that some compiler messages are in German
> (you can look up the translation by error number).
>
> Hope this helps.

Thanks.

martyn.br...@gmail.com

unread,
Jun 7, 2017, 7:04:21 AM6/7/17
to
On Monday, January 31, 2000 at 8:00:00 AM UTC, stefan_h...@my-deja.com wrote:
> As I am currently wrestling with template troubles caused by various
> VC6 SP3 bugs (features?), I feel I have to get this off my chest:
>
> While searching through the news archives I found various references to
> "kown bugs" in VC6 which don't seem to make it into the Microsoft
> Knowledge Base. For example there is the famous member function
> template problem that requires you to have the template argument in the
> function signature, or various C1001 occurrences, or LNK2001/2005
> problems, or even undocumented error messages. Most of these have
> already been described months ago, but are still aren't mentioned in
> the knowledge base.
>
> Does anybody know why that is?
>
> - Is Microsoft censoring bug reports?
> - Do they have a huge backlog of reports and no time to process them?
> - Are they not considering them bugs?
> - Are they only publishing bugs they know a workaround for?
> - Are they only publishing bugs they plan to fix in the next release?
> - Or is it just that they don't care?
>
> A knowledge base that ain't up to date is not worth much to me. When I
> start to ask the net before I look into the knowledge base then the
> latter becomes superfluous.
>
> Any comments?
>
> Ah, by the way, is anybody keeping a more serious bug list or FAQ for
> VC6 and willing to share it on the net?
>
> Stefan
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Microsoft make it too difficult to report bugs and they ignore standards laid out in K&D and the C++ Programming language, so it's their own fault. There are bugs in MSXML that have been there for 13 years!

Stephen Wolstenholme

unread,
Jun 7, 2017, 8:01:07 AM6/7/17
to
On Wed, 7 Jun 2017 04:04:19 -0700 (PDT), martyn.br...@gmail.com
wrote:
You are responding to a problem posted 16 years ago.

In my experience Microsoft do fix bugs. I reported a problem in VC++
that was unknown. A chap in Microsoft phoned me up and I explained how
to create the problem. He suggested a way to avoid the bug. It was
fixed in the next update. A few months later I got a job offer!

Steve

--
Neural Network Software for Windows http://www.npsnn.com

Reply all
Reply to author
Forward
0 new messages