1.00 1.50
WINDOWS
kbtool
----------------------------------------------------------------------
The information in this article applies to:
- The Microsoft C/C++ Compiler (CL.EXE), included with:
- Microsoft Visual C++ for Windows, versions 1.0 and 1.5
----------------------------------------------------------------------
SUMMARY
=======
Microsoft C/C++ versions 8.0 and 8.0c define a new error, C2832, that C/C++
version 7.0 does not define. The online help provides the following
information about the C2832 error:
Compiler Error C2832
'modifier' form of 'operator operator' cannot be a member
- The specified form of the operator new or delete was declared as a
member of a class, structure, or union. The huge and based forms of
these operators are not supported as member functions.
- The following are examples of this error:
class T
{
public:
void __huge* operator new (unsigned long, size_t); // error
void __based(void)* operator new (__segment, size_t); // error
void operator delete (void __huge*); // error
void operator delete (__segment, void __based(void)*); // error
};
MORE INFORMATION
================
The reasons for this new error are as follows:
Rationale for HUGE
------------------
Members "new" and "delete" are never used for arrays. Since the
size of a single object cannot exceed 64K anyway, member addressing
is adequate and more efficient when "far," even for elements of a
"huge" array.
To support "huge" in the presence of virtual destructors would
require the reservation of three virtual function slots in the
"vftable." This was considered to be an unacceptable overhead,
especially since it would only deal with objects of less than 64K
anyway.
The ambient class model is constrained to "near" and "far," as is
the type of the "this" pointer. Since all other members deal in
"near" and "far" instances only, supporting "huge" on members new
and delete would represent the only variation in this convention.
Rationale for BASED
-------------------
As stated above, the ambient class model and the type of the "this"
pointer are constrained to "near" and "far." There is no parallel
with "based" and supporting "based" on the members new and delete
would by inconsistent and represent an exception to the rule.
Supporting "based" delete would require the addition of an extra
"segment" hidden parameter to the destructor.
If the destructor is virtual, it would also require the reservation
of four virtual function entries in the "vftable." If "huge" was
also supported, this would become six reserved entries in the
"vftable."
The speed and space cost of making these changes and their impact on
the run-time libraries was considered too great when weighed against
the small advantage the changes would provide to most programs. The
impact is especially great and the advantage small because most
classes are never "huge" or "based" allocated. Supporting a segment-
based object addressing model would require the application to pass
both the segment and the offset and would constrain the data types
eligible for based allocations. In call cases, the code would require
more space and time than using "far."
Additional reference words: kbinf 1.00 1.50 8.00 8.00c
KBCategory: kbtool
KBSubcategory: CPPIss