Encapsulation IS a first-class motivator for OOP. All the texts teaching college-level programming have included this as a motivator for OOP for at least the last 15 years.

>Encapsulation IS a first-class motivator for OOP. All the>texts teaching college-level programming have included this as>a motivator for OOP for at least the last 15 years.Ok... guess I was wrong all these years... of course... I started in 1979... so things tend to get fuzzy after a while. Then again... maybe I never said wasn't a "first-class motivator" (snicker)... I said it wasn't THE primary purpose of OOP. It still isn't.If you were taking a class under me, and you used OOP to encapsulate something and you couldn't definitively represent it's need to be an object... I'd give you a bad grade. OOP isn't a 'convenience' tool. There IS overhead involved in code to support an object and thus defining an object strictly for convenience is not always the best approach.J-L's object serves a purpose and provides a 'code repository' in that in the compiled code itself the methods being called reside in exactly one location in the code... thus reducing the overall code size while expanding the functionality and reducing the core code maintenance requirements. He could declare 500 variables using this object... and there would be 500 memory pointers with local data and exactly one memory area with the methods for all 500 variables. That is a good candidate for OOP... however, it meets far more critera than "encapsulation".I love college grads... I really do... never-ending source of entertainment for me. ;)

>Any idea?Well, I don't see why you would want to use the inefficent execute_calculator_code() just to retrieve XML variables, instead of simply call aircraft_varget() directly. Even if it's precompiled, precompiling will only save you the step of converting from xml to intermediate code, but execute_calculator_code() is surely less efficent than aircraft_varget(). Never used execute_calculator_code() in any of my projects, and I can't think right now of a case when I wouldn't be able to obtain the same results with a combination of aircraft_varget() and C++ code.However, you surely can rewrite your class using a combination of templates and function overrides, to have just a single function call differentiated by paramater types.

However, if you *really* want to use the xml compiler, a rewrite of your class might look like this:template class XmlVarExecute{public: XmlVarExecute() : _source_code(0), _precomp(false) {};~XmlVarExecute() { if (_precomp && _source_code) { delete [] _source_code; _source_code = 0; _precomp =false; }}void Init(char* source_code, bool precomp = true){ if (!_source_code && source_code) { _source_code = source_code; if (precomp) { PCSTRINGZ pszCode; UINT32 uSize; if(gauge_calculator_code_precompile(&pszCode,&uSize, source_code)) { _source_code = new char[uSize]; memcpy(_source_code,pszCode, uSize); _precomp = true; } } }}void Lookup( FLOAT64* var ){ execute_calculator_code(_source_code, var,0,0);}void Lookup( SINT32* var ){ execute_calculator_code(_source_code,0,var,0);} private: char* _source_code; bool _precomp;};To be used like this:// During module_initXmlVarExecute myint32;XmlVarExecute myfloat64;myint32.Init( "(A:ADF SIGNAL:1,Number)" );myfloat64.Init( "(A:ADF ACTIVE FREQUENCY:1,KHz)" );// When neededSINT32 a = 0;FLOAT64 b = 0;myint32.Lookup( &a );myfloat64.Lookup( &b );Easier to read, an no unneeded inheritance used...you can get rid of the template as well, if you don't like it.regards,

Actually, I think writting in this forum lead me to find out more about this! the key seems to be class template specialization. I'll try it out and let you know how it goes.Here is what I came up with, not tested yet, just typed and compiled ok:template class xmlvar : public _xml_var_execute{public: xmlvar(){}; xmlvar(char* source_code, bool precomp =true) {Init(source_code, precomp);} T Lookup() {return (T) 0;}};template <>class xmlvar : public _xml_var_execute{public: xmlvar(){}; xmlvar(char* source_code, bool precomp =true) {Init(source_code, precomp);} SINT32 Lookup() {SINT32 var; execute_calculator_code(_source_code,0,&var,0); return var;}};template <>class xmlvar : public _xml_var_execute{public: xmlvar(){}; xmlvar(char* source_code, bool precomp =true) {Init(source_code, precomp);} FLOAT64 Lookup() {FLOAT64 var; execute_calculator_code(_source_code,&var,0,0); return var;}};In this case, we would do:xmlvar myVar1;xmlvar myVar2;myVar1.Init("blabla");myVar2.Init("toto");double val1 = myVar1.Lookup();int val2 = myVar2.Lookup();Sounds easy!

I even wonder if I can have a specialisation based on return type, in overloading operator type(). This would give instead:operator double() {double var; execute_calculator_code(_source_code,&var,0,0); return var;}operator int() {int var; execute_calculator_code(_source_code,0,&var,0); return var;}However, this would suppose a form or RTTI (i.e. the type returned is determined at runtime - well compiled with direct function call though)The issue I see: some XML vars return a float value, and you could miss the value with an int dwVar = myDoubleXml.Lookup();What do you think?

>The issue I see: some XML vars return a float value, and you>could miss the value with an int dwVar =myDoubleXml.Lookup();>>What do you think?As I've said initially, I'd make it even simpler:Right now, you made a specialization template just to differentiate between integer and floating variables, because that's what execute_calculator_code() requires. Well, there's the additional string version but, let's deal with numbers first.If you used aircraft_varget() instead, and wrap *that* one in a C++ class with Templates for tokens (use a list of const char strings as a Template parameter to initialize the variable names), handling tokens and unit conversion in the class, you'll only have to deal with FLOAT64 datatypes for all numbers, and that's it. You can always cast to int afterwards, if really needed.Don't you think it's a little bit overkill to use inheritance and pre-compiled xml code *just* to ask some variables ?You might consider using the execute_calculator_code() approach just for string data types, that are far less common.regards,

There are certain variables that are only available via XML.

>There are certain variables that are only available via XML.There are very few (P: vars, for example) for which XML might still be needed, and the few that requires string returns. However, some of the useful vars that have a string type, are those of the gps and, in that case, it's possible to access those with C++ without touching XML at all, using the Get/SetPropertyValue() C++ interface. But that's another topic...But, 95% of the "XML" variables, are available through aircraft_varget()So, clearly, best programming practices dictates that you solve the most general case in the most efficent way, and then separately handle the few exceptions with the less efficent code, instead of doing the opposite, modeling a generic interface to suit the less favourable case.I assure you, there's no single XML calculator code (nor any calculation done in XML, btw) in the whole of the Acceleration F/A-18 code and that airplane isn't surely short of features: everything is done with C++, wrapping only documented Gauge SDK calls (By "documented", I mean "available in GAUGES.H", not necessarily "well explained in the docs" )regards,

I do have the other one class, using aircraft_var_get of course. This one is even easier and I cast the return value to my liking.For completness in my framework, I also wanted to have the exec_calc_code based class, and I wanted it to be as simple as possible from the developer perspective (i.e. simple, not long lines of code to type, and universal ala overloaded Lookup() function).In that case, I was not seeking best programing practices Umberto, just completness of the set of classes I have available in regard to accessing SDK variables.In any case, this topic brought a good discussion around C++ I hope!

"I started in 1979... so things tend to get fuzzy after a while. Then again... maybe I never said wasn't a "first-class motivator" (snicker)... I said it wasn't THE primary purpose of OOP. It still isn't."I don't disagree entirely, but I was simply pointing out that encapsulation is in the list of what makes a language object-oriented in nature (or, enables a language to be used on an object-oriented fashion). And yes, I am fully aware of the reuse and the memory advantages of OOP, but thank you for the input (not sarcasm).In any case:A) you needn't be arrogant in your reply:( Encapsulation is among the many features/goals for doing objects, it is taught in most programming courses as among the benefits of using this approach. We could use a struct if we simply wanted to encapsulate, but objects/classes go beyond simple encapsulation for the reasons we seem to agree on. I can't see how every publisher is getting it wrong. I certainly can't see how [a href=http://www.research.att.com/~bs/whatis.pdf]this guy[/a] could be considered in error on the subject.C) ">I love college grads... I really do... never-ending source of>entertainment for me. ;)" - a very conceited thing for you to say; you don't know anything about me. I am simply telling you that anyone who graduated from any college curriculum in the last 15 years in which they study programming and how to do OOP are taught that encapsulation is among the benefits of OOP.

>I do have the other one class, using aircraft_var_get of course. >For completness in my framework, I also wanted to have the >exec_calc_code based class.Well, this of course makes much more sense, I guess your sample was just a little bit misleading: I was trying to figure out what was the point to go to such great lenghts, jut to get the adf frequency...>In any case, this topic brought a good discussion around C++ I>hope!Yes, of course!If we discuss more about C++ and less about XML, up to a point that we can pretend it never existed, maybe it *will* go away...Well, that's only a joke: I don't think XML will ever go away for gauges. I'll only do my best (basically, ####, moaning, lobbying and, more important, creating great stuff in C++), to ensure that C++ will remain. I know you are thinking exactly the same...regards,

Exactly! in fact what is funny, is that now that I have an entirely runtime time created gauge + elements with the framework (nothing statically linked via the MACROS - there is another post of mine here that shows the code of the rxpDrop gauge as an example), I can even imagine having a universal gauge, that would read an XML gauge file, and create C++ gauges from the XML source at runtime! kinda reinventing the wheel though, unless I can come up with a more efficient "interpreter" implementation than the one included in the panels.dll.At least, I can still generate C++ source from the XML code, that would use the framework to generate the gauge structure in the framework. Much better for "encryption" than the easily reversed engineered SPB file format :)

>I can even imagine having a universal>gauge, that would read an XML gauge file, and create C++>gauges from the XML source at runtime! kinda reinventing the>wheel though, unless I can come up with a more efficient>"interpreter" implementation than the one included in the>panels.dll.>>At least, I can still generate C++ source from the XML code,>that would use the framework to generate the gauge structure>in the framework. Much better for "encryption" than the easily>reversed engineered SPB file format :)>That would be an interesting project!It is my opinion that the future in panels development goes through the combination of XML "source" code and a single dll (or many) linked to FS via dll.xml. I think the.gau format (which are dlls as well) has become obsolete -again it's my opinion-; there is no real need to maintain so many .gau/dll libraries when it's more efficient to let them be created at runtime as C++ class instantiations- XLM gauges are not actually "gauges" but text source code used to build the "real" gauges in memory. Appart from the known limitations to support sound, file IO or vector graphics, XML "gauges" are unbeaten in complex projects because of their flexibility and a fast development/testing cycle. Now it happens that those limitations already mentioned are well resolved with the support of a master DLL. And other very important weak point to talented developers-its visible source code-has been partially fixed by MS when making the new precompiled .spb format. I think MS will keep working on the enhancement of precompiled XML code in the future, maybe more secure than today.So JeanLuc,if you are willing to work on a project in that direction, I will be glad to help in any way for sure :-)Tom

>there is no real need to maintain so many .gau/dll>libraries when it's more efficient to let them be created at>runtime as C++ class instantiations- XLM gauges are not>actually "gauges" but text source code used to build the>"real" gauges in memory. Sorry, but that's not the case.The most efficent implementation is writing everything in C++, and letting the C++ *compiler* translating into machine code the largest possible part of the gauge logic. Being "all too dynamic" sounds exciting, but it's not always the best option. It's the compiler that should do most of the work, and yes, Macros are bad, but there are templates for that.>Appart from the known limitations to support sound, file IO or>vector graphics, XML "gauges" are unbeaten in complex projects>because of their flexibility and a fast development/testing>cycle. Reality is exactly the opposite: XML gauges might be useful to begineers who don't know C++ to get "some" results. But, the MORE the project is complex, the MORE XML "code" will show its limitations."Fast development/testing" cycle it's NOT just how much time it will take to restart FSX. It's more about debugging options at your disposal, and Visual Studio can offer far more debugging options than anything possible with XML. Moreover, you don't even have to restart FSX when debugging gauges, because it's possible to freely attach/detach debug process without restarting. It's only needed to switch to a differen airplane, then going back to the one under debug.XML code doesn't scale well, also. The largest the project becomes, the more you see the impact of interpreted code.XML can't access to a vast library of standard libraries and algorithms, just the avilability of the crucial Standard C++ Library (former STL) it's more than enough to disregard XML entirely, for big project.If you are still using char* instead of std::string, if you are still using arrays[] instead of std::vector<>, this might not concern you at all, but this also means you are not using C++ at the fullest, then you can't obviously fully comment how better/worse is, comparing to XML.A project like, for example, a full FMC, done with STL and with containers of pointers to user-defined classes, perhaps with C++ patterns, like the Comnmand pattern, can still be done within a reasonable amount of time, by a proficent C++ developers.The same thing in XML, will take so much time, and will result in unreadable, unmantainable SLOW, and messy code, that the company writing it, will probably go bankrupt while doing it. Or, it will go bankrupt when they'll discover having to rewrit it from scratch, to support a slightly different airplane...Sound, Gdi+, Opengl, DirectX, complex i/o, Windows API calls, Multithreading programming (more and more important now and in the future), there are simply too many things you can't use in XML and, if you have to go through the cumbersome route of hybrid code, using C: custom calls and mixing XML and C++, to have C++ doing the missing things, you might well writing everything in C++.