ADS 1.2 error C3032E: non-public member | developer.brewmp.com ADS 1.2 error C3032E: non-public member | developer.brewmp.com

Developer

ADS 1.2 error C3032E: non-public member

The code compiles just fine on VC7 and works on the emulator, but it's giving me some trouble on ADS 1.2

I have a base class "Object" from which all other classes inherit. And a class Vector wihich contains an array of pointers to objects.

class Object;
class Image : public Object {
...

class Vector : public Object {
public:
[INDENT]Object ** elementData;
void addElement (Object & obj);

template ‹class T>
T & elementAt (int i) {
[INDENT]return *((T*)(elementData[i]));[/INDENT]
...[/INDENT]

}

class myApp {
...[INDENT]Image img1, img2;
Vector vec;

vec.addElement(img1);
vec.addElement(img2);
vec.addElement(vec);

draw(vec.elementAt‹Vector>(2).elementAt‹Image>(1));[/INDENT]

When it gets to the call to vec.elementAt, the compiler crashes with this C3032E 'Vector::elementAt' is a non-public member

I've tried different parenthising configurations on the method call, with no luck.

Am I doing something wrong, or is this just part of the "partial support" of ADS to templates? :confused:

Cheers!
Markus

For the record, the problem is also not the multiple calls to elementAt. Simply calling
draw(vector.elementAt‹Image>(0))
will result on the same compiler error message

For the record, the problem is also not the multiple calls to elementAt. Simply calling
draw(vector.elementAt‹Image>(0))
will result on the same compiler error message

In case someone might be interested: not finding anything wrong with my code (hell, it works on VC7!), I went with the "-Ea" option of the ADS compiler, which "downgrades access control errors to warnings"
I believe I can do this in this particular case because I'm sure that the only lines triggering this kind of error where the calls to this elementAt method. Ignoring the error generates a perfectly functional mod file. But I would still like to hear someone say I can avoid the error by changing something in my code, instead of using -Ea
Cheers! :)
Markus

In case someone might be interested: not finding anything wrong with my code (hell, it works on VC7!), I went with the "-Ea" option of the ADS compiler, which "downgrades access control errors to warnings"
I believe I can do this in this particular case because I'm sure that the only lines triggering this kind of error where the calls to this elementAt method. Ignoring the error generates a perfectly functional mod file. But I would still like to hear someone say I can avoid the error by changing something in my code, instead of using -Ea
Cheers! :)
Markus

class Object;
class Image : public Object {
...

class Vector : public Object {
public:Object ** elementData;
void addElement (Object & obj);
template ‹class T>
T & elementAt (int i, const T *) {return *((T*)(elementData[i]));...}
}
class myApp {
...Image img1, img2;
Vector vec;
vec.addElement(img1);
vec.addElement(img2);
vec.addElement(vec);
Vector * pVector;
Image * pImage;
draw(vec.elementAt‹Vector>(2, pVector).elementAt‹Image>(1, pImage));}

class Object;
class Image : public Object {
...

class Vector : public Object {
public:Object ** elementData;
void addElement (Object & obj);
template ‹class T>
T & elementAt (int i, const T *) {return *((T*)(elementData[i]));...}
}
class myApp {
...Image img1, img2;
Vector vec;
vec.addElement(img1);
vec.addElement(img2);
vec.addElement(vec);
Vector * pVector;
Image * pImage;
draw(vec.elementAt‹Vector>(2, pVector).elementAt‹Image>(1, pImage));}

markus wrote:In case someone might be interested: not finding anything wrong with my code (hell, it works on VC7!), I went with the "-Ea" option of the ADS compiler, which "downgrades access control errors to warnings"
I believe I can do this in this particular case because I'm sure that the only lines triggering this kind of error where the calls to this elementAt method. Ignoring the error generates a perfectly functional mod file. But I would still like to hear someone say I can avoid the error by changing something in my code, instead of using -Ea
Cheers! :)
Markus
I know this is an old thread, but i encountered the same problems when trying to implement some template policies and meta template code. Basically the support for templates on ADS 1.2 is laughable. Its not even partial. Its minimal.
The problem you'd discovered also happens for static functions. Basically, it is a bad idea to template any functions at all in a non-templated class. Template template prototyping is also not fully supported (doesn't work for level 2 upwards), making it extremely difficult to make policy classes collaborative.
Using the -Ea flag at least works for the template class method problem. But on all other problems, the compiler just spews some non-related errors and shutdown.
I know many ppl would say "stop doing all these fancy footwork, code in plain vanilla C and everything will be fine". All i have to say is that if you know how powerful templates can be when properly used, it will just blow your argument into the void. We are developing for BREW for the long haul and we want to have extensible, typesafe and compile-time optimized code. I don't wanna have to maintain a library that is just asking to be modified, updated and violated (code wise) everytime a new project comes around. :mad:
On a constructive note, does any1 else have any alternatives to this problem? I know many ppl use gcc to compile their BREW code. Personally i'd never done that b4 but i heard the .mod size comes up pretty big.

markus wrote:In case someone might be interested: not finding anything wrong with my code (hell, it works on VC7!), I went with the "-Ea" option of the ADS compiler, which "downgrades access control errors to warnings"
I believe I can do this in this particular case because I'm sure that the only lines triggering this kind of error where the calls to this elementAt method. Ignoring the error generates a perfectly functional mod file. But I would still like to hear someone say I can avoid the error by changing something in my code, instead of using -Ea
Cheers! :)
Markus
I know this is an old thread, but i encountered the same problems when trying to implement some template policies and meta template code. Basically the support for templates on ADS 1.2 is laughable. Its not even partial. Its minimal.
The problem you'd discovered also happens for static functions. Basically, it is a bad idea to template any functions at all in a non-templated class. Template template prototyping is also not fully supported (doesn't work for level 2 upwards), making it extremely difficult to make policy classes collaborative.
Using the -Ea flag at least works for the template class method problem. But on all other problems, the compiler just spews some non-related errors and shutdown.
I know many ppl would say "stop doing all these fancy footwork, code in plain vanilla C and everything will be fine". All i have to say is that if you know how powerful templates can be when properly used, it will just blow your argument into the void. We are developing for BREW for the long haul and we want to have extensible, typesafe and compile-time optimized code. I don't wanna have to maintain a library that is just asking to be modified, updated and violated (code wise) everytime a new project comes around. :mad:
On a constructive note, does any1 else have any alternatives to this problem? I know many ppl use gcc to compile their BREW code. Personally i'd never done that b4 but i heard the .mod size comes up pretty big.

yeah your arguments fall flat on their face when you discover the toolset doesn't support them , ARM say flat out that they don't support them too.
gcc should let you use them just fine, but it will deliver slower, larger code.

yeah your arguments fall flat on their face when you discover the toolset doesn't support them , ARM say flat out that they don't support them too.
gcc should let you use them just fine, but it will deliver slower, larger code.

charliex, I understand your concern for size, but if used sparingly on only a few classes I don't see the code growing too large (especially in the case of the templated code not being that big in the first place).
I don't understand why you believe the code will run slower though. Isn't the whole point of templates to do things at compile time? Is there something about the ARM generated code related to templates that I don't understand??
P.S. I am not using gcc to compile code similar to the posters and it compiles and runs fine so far. I am worried about the future, thats why I'm asking if there is some known problem with templates and speed. Also, what toolset do you mean??

charliex, I understand your concern for size, but if used sparingly on only a few classes I don't see the code growing too large (especially in the case of the templated code not being that big in the first place).
I don't understand why you believe the code will run slower though. Isn't the whole point of templates to do things at compile time? Is there something about the ARM generated code related to templates that I don't understand??
P.S. I am not using gcc to compile code similar to the posters and it compiles and runs fine so far. I am worried about the future, thats why I'm asking if there is some known problem with templates and speed. Also, what toolset do you mean??

slower because gcc generates less optimal code than ADS (the toolset)
average is around 20% code size increase in my tests, not that virtuals are slower, as you say careful use of them wont affect speed. its the compiler switch that does.
20% is a fair chunk to lose on a mod size for me

slower because gcc generates less optimal code than ADS (the toolset)
average is around 20% code size increase in my tests, not that virtuals are slower, as you say careful use of them wont affect speed. its the compiler switch that does.
20% is a fair chunk to lose on a mod size for me