Conference decwet::nt-developers

3205.0. "c2782 - BUG OR FEATURE?" by AXPBIZ::knobby.pa.dec.com::PHEBERT (Mr. Knobby rides again. and again and again...) Wed Mar 12 1997 10:16

THE FOLLOWING OUTPUT SHOWS AN ERROR MESSAGE FROM VCPP V5 BETA ATTEMPTING 
TO COMPILE A TEST FILE DERIVED FROM AUTOCAD CODE WHICH FAILS TO BUILD ON 
V5 BUT BUILDS AND RUNS OKAY UNDER VCPP V4.2B.  I'M TOTALLY LOST TRYING TO 
UNDERSTAND EITHER THE CODE OR THE ERROR, BUT MY CONTRACTORS AGREE WITH 
THEIR AUTODESK COUNTERPARTS THAT THIS SHOULD NOT BE AN ERROR.  I'M TOLD 
THAT IT WAS REPORTED BY AUTODESK TO MICROSOFT AS A BUG, BUT MS ASSERTS 
THAT IT IS NOT A BUG.  I AM LOOKING HERE FOR (1) ANOTHER OPINION FROM 
INFORMED SOURCES AND (2) A WORKAROUND.  

[I'VE REFORMATTED THE OUTPUT SOME TO MAKE IT EASIER TO READ]

>cl templtest.cpp
Microsoft (R) & Digital (TM) AXP C/C++ Optimizing Compiler Version 
11.01.7021
Copyright (C) Microsoft Corp 1984-1997.
Copyright (C) Digital Equipment Corporation 1992-1997.
All rights reserved.

templtest.cpp
templtest.cpp(65) : error C2782: 'int __cdecl setComplexEntityProperty(
		template-parameter-1 *,
		class AcDbObjectIterator *,
		int,
		int (__cdecl 
template-parameter::*)(template-parameter-3,int),
		template-parameter-3,
		int)'
 : template parameter 'PropertyType' is ambiguous
           could be 'class AcCmColor' or 'const class AcCmColor &'


HERE IS THE CONTENT OF TEMPLTEST.CPP.  THE LAST LINE IS #65:


class AcCmColor;

class AcDbImpEntity {
public:
int setColor(const AcCmColor &, int) {return 0;};
};

class AcDb3dPolylineVertex : public AcDbImpEntity {
public:
};

class AcDbObjectIterator {
};

class AcDbImp3dPolyline : public AcDbImpEntity {
public:	
int setColor(const AcCmColor &, int);
};

class AcCmColor : public AcDbImpEntity {
};

template
   <class ImpEntityType,            // type of entity being modified
    class SubEntityType,            // type of sub-entities
    class PropertyType>             // type of property being set
int setComplexEntityProperty(       // function name

           ImpEntityType *pImpEnt,  // the entity to be modified
           AcDbObjectIterator * pObjIter,  // sub-entity iterator

           // return value from ImpEntity::set* call
           int es,

           // pointer to member function which sets the property
           int (SubEntityType::*pSetProp)(PropertyType, int),

           PropertyType newValue,   // new value of the property
           int  doSubents  // recurse thru subentities?
       )
{
return(es);
}	

AcDbObjectIterator *vertexIterator( void )
{
return new AcDbObjectIterator;
}

#define SetSomethingIterator(who, what, argtype, verttype, iteratorname) \
int who::what(argtype newVal, int doSubents) {  \
    return setComplexEntityProperty(this,  \
             iteratorname(),               \
             AcDbImpEntity::what(newVal, 0),  \
             (int (verttype::*)(argtype, int)) \
                  verttype::what,   \
             newVal,        \
             doSubents);    \
}

#define Poly3dSetSomethingIterator(method, argtype) \
SetSomethingIterator(AcDbImp3dPolyline, method, argtype, \
                     AcDb3dPolylineVertex, vertexIterator)

Poly3dSetSomethingIterator(setColor,          const AcCmColor &)

>[I'VE REFORMATTED THE OUTPUT SOME TO MAKE IT EASIER TO READ]
    
    Then let's try again...with caps unlocked.

    The issue is that C++ code that used to compile on Microsoft Intel and
    Alpha V4.x compilers now returns an error on Intel and Alpha V5.0
    compilers.
    
    The reason is that this C++ code is not conformant to the draft ANSI
    C++ standard (and soon to be standard, if it isn't already).
    
    Microsoft compiler development made a conscious decision not to
    have a backward compatibility switch.  Customers who upgrade to V5 must
    change their code to make it more standard compliant.
    
    This isn't what the customer wants to hear, but there are advantages to
    having standard compliant code.  Can a case be made to the customer
    to make these changes now instead of later?