Microsoft KB Archive/102618

From BetaArchive Wiki
< Microsoft KB Archive
Revision as of 16:02, 18 July 2020 by 3155ffGd (talk | contribs) (importing KB archive)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

New Error C2832 with Visual C++


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

Keywords : kb16bitonly
Issue type :
Technology : kbVCsearch kbAudDeveloper kbCVCComp

Last Reviewed: May 5, 2001
© 2001 Microsoft Corporation. All rights reserved. Terms of Use.