Technical discussions related to Analog Devices DSPs (including Blackfin, TigerSHARC, SHARC and ADSP-21xx DSPs).
|
> -----Ursprüngliche Nachricht----- > Von: duhlynn [SMTP:] > Gesendet am: Donnerstag, 22. Juli 2004 16:43 > An: > Betreff: [adsp] Far Pointers / Near > > Why does the ADSP219x C++ compiler require a overloading of the '=' > operator when using far qualified structures??? > > The answer I got from ADI back in April: > "The far keyword is treated as being a > type qualifier like volatile. An explicit assignment operator is > required for both far and volatile." > > Does anyone have a link to standards documentation on this? The official ISO standard documentation isn't available without fee. There's a news group at comp.lang.c++ where such stuff is regularly discussed with fair competence, you might post your question there. As far as I can see, ADI's response is correct. IMHO, it might help to understand the issue, if you consider this: typedef int t_int; The resulting type t_int is certainly congruent to the builtin type int, however you'll certainly get warnings or even errors if you pick the wrong one. And this is the case not only with C++ but even with newer C compilers. They should all mock if you use the wrong type. This is even more important if you want to mix 'int' with 'volatile int'. I like it if the compiler warns me if I unattendedly store a volatile value into a non-volatile. It happened very often that I just forgot about the volatile nature of the underlying variable (especially if dealing with old code). When the compiler issued a warning/error, it reminded me to check very carefully if the right thing happens. Another thing with pointers into different memory segments: far pointers might be handled different from near pointers. I remember a compiler which had one-byte pointers with very effective coding, while far pointers were two-bytes wide and part of it consisted of a memory type identifier and coding were less effective. Therefore the compiler must know which type is on either side of an assignment, and in neither case it could produce a single code for all types and being well-optimized at the same time. Guess it's not a big issue to redefine/overload the operator= and/or some others. If you want to create a base class which shall "export" the operator= (which is not possible), it might export a function which does the work. Then you need only call this function in the operator= definition. If it's not mixing of different types of variables which you intend, but only one code instance for all types: did you try to solve this with templates? Bernhard |