I'm trying to belt Suse linux into submission regarding installing GCC. It's pretending not to find the standard libraries, maybe I'll try Debian as you developed on that.
Cheers, Mike.
Go to software.opensuse.org, state your version and install what you need. I am using 10.3 and it works. I've compiled mplayer and other tools.
Tullio
I'm trying to belt Suse linux into submission regarding installing GCC. It's pretending not to find the standard libraries, maybe I'll try Debian as you developed on that.
Cheers, Mike.
Go to software.opensuse.org, state your version and install what you need. I am using 10.3 and it works. I've compiled mplayer and other tools.
Tullio
Ah, well. I have Suse 11.1 so maybe I ought to slide back to 10.x ......
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
- the GraphicsEngineFactory class can instantiate objects which create AbstractGraphicsEngine's. That is GraphicsEngineFactory::createInstance() returns a pointer to an AbstractGraphicsEngine.
I would phrase it differently, but in principle this is correct!
Quote:
- the AbstractGraphicsEngine class is, obviously, abstract or virtual so you have to subclass to get concrete instances. There are currently two subclasses : StarsphereS5R3 and StarsphereRadio. I select which one when I call GraphicsEngineFactory::createInstance() by indicating in it's parameter list one element from each of the enumerations GraphicsEngineFactory::Engines and GraphicsEngineFactory::Applications ( sensible combination thereof ).
Correct. The whole notion of a "GraphicsEngine" stems from the idea of different visualization "plugins" - Starsphere being only one of them, coming in two different styles (one each for S5 and ABP).
At some point I want(ed) to implement the different engines as true plugins that are loaded dynamically during GFX startup. Which visulization engine/plugin gets used could be set by the user in the project specific preferences for example... In order to prepare for this I had to provide a common interface for all future implementations - that's what AbstractGraphicsEngine is all about.
Quote:
- Starsphere class is derived from AbstractGraphicsEngine, but is still virtual.
Yep, it's one specific engine but in two different styles/flavors. One's used for S5Rx and one for ABP. Thus Starsphere contains the common parts of both flavors.
Quote:
- now StarsphereS5R3 class and StarsphereRadio class each multiply inherit ( subclass ) from both Starsphere and m_EinsteinAdapter classes?
Nope, but we already discussed that :-) Both classes contain the respective application-specific parts. Don't be confused by the somehow outdated naming: S5 always refers to the hierarchical search and Radio/ERP/ABP refer to the radio pulsar search - the usual historical reasons ;-)
Quote:
[aside]Where does m_EinsteinAdapter get defined - in the BOINC library or somesuch?[/aside]
That's an instance of EinsteinS5R3Adapter and a member of StarsphereS5R3. This is the interface to the BOINC client and the shared memory segment used to pass real-time search information from the science application to the graphics application. As this information is different for S5 and ABP, there're two implementations of the abstract class BOINCClientAdapter.
Quote:
- thus StarsphereS5R3 and StarsphereRadio can be returned from a GraphicsEngineFactory::createInstance() call as they ( amongst other things like being an m_EinsteinAdapter ) can be considered of type AbstractGraphicsEngine.
Yes, both are implementations of AbstractGraphicsEngine (but forget about "being an m_EinsteinAdapter").
Quote:
- presumably one could/would/should add an enumeration constant to the GraphicsEngineFactory::Engines enum within GraphicsEngineFactory.h to indicate a new type - that I will write, call it the HewsonSphere class for this discussion.
Correct!
Quote:
- HewsonSphere need not derive from Starsphere, as my design for a screensaver may have no interest in the particular interface that Starsphere offers.
Also correct. That's the reason why there's a framework. You don't have to care about anything in the "starsphere" folder (almost, see next topic), just create your own and use what's in "framework". Starsphere should only serve as an example of how to use the framework.
Quote:
- HewsonSphere class could remain virtual, but probably doesn't need to be ( unlike Starsphere ). But it, or a concrete class derived from it if I leave it virtual, also needs to inherit from m_EinsteinAdapter too.
HewsonSphere should be abstract/virtual only if you have one or more children that specialize it. Otherwise it's a single concrete class implementing AbstractGraphicsEngine.
Considering the Einstein[APP]Adapter classes: it's not inheritance, it's a composition. But I suppose that's clear by now, isn't it? So this is the only part of the "starsphere" directory that could be of interest to you. When you want to use the information provided by the science apps mentioned above, you need the Einstein[APP]Adapter classes.
Background: the framework is meant to be useful for all BOINC projects, therefore it doesn't contain anything project-specific. Unfortunately this is not 100% true, however, because of the intended plugin concept that's not yet implemented. So for the time being GraphicsEngineFactory contains these tiny project-related bits :-/ A working plugin-concept would let the factory query all available plugins for their identifiers (engine/application) dynamically, so that this information would not have to be stored/maintained manually in its header as it is today (see below).
Quote:
- ( assuming all of the above ) I would leave alone the GraphicsEngineFactory::Applications enumeration as it's none of my business, as I don't write science applications.
- but I need to chose an application within that GraphicsEngineFactory::Applications enumeration so that my HewsonSphere, being of type derived from m_EinsteinAdapter, can respond to do the BOINC communication thingy via.
No, right now you need to specify both, an "engine" and an "application". Both are are needed to identify a specific graphics application (can be the same in your case). The "application" IDs are meant to differentiate between separate implementations of the graphics code for, say, SxRx and ABPx.
I hope all this makes some sense to you. Let me know if you have more questions. BTW, are you aware of the available documentation (doxygen)?
- the GraphicsEngineFactory class can instantiate objects which create AbstractGraphicsEngine's. That is GraphicsEngineFactory::createInstance() returns a pointer to an AbstractGraphicsEngine.
I would phrase it differently, but in principle this is correct!
Quote:
- the AbstractGraphicsEngine class is, obviously, abstract or virtual so you have to subclass to get concrete instances. There are currently two subclasses : StarsphereS5R3 and StarsphereRadio. I select which one when I call GraphicsEngineFactory::createInstance() by indicating in it's parameter list one element from each of the enumerations GraphicsEngineFactory::Engines and GraphicsEngineFactory::Applications ( sensible combination thereof ).
Correct. The whole notion of a "GraphicsEngine" stems from the idea of different visualization "plugins" - Starsphere being only one of them, coming in two different styles (one each for S5 and ABP).
At some point I want(ed) to implement the different engines as true plugins that are loaded dynamically during GFX startup. Which visulization engine/plugin gets used could be set by the user in the project specific preferences for example... In order to prepare for this I had to provide a common interface for all future implementations - that's what AbstractGraphicsEngine is all about.
I see now. In true OO flavour. Very much like a Java interface.
Quote:
Quote:
- Starsphere class is derived from AbstractGraphicsEngine, but is still virtual.
Yep, it's one specific engine but in two different styles/flavors. One's used for S5Rx and one for ABP. Thus Starsphere contains the common parts of both flavors.
Quote:
- now StarsphereS5R3 class and StarsphereRadio class each multiply inherit ( subclass ) from both Starsphere and m_EinsteinAdapter classes?
Nope, but we already discussed that :-) Both classes contain the respective application-specific parts. Don't be confused by the somehow outdated naming: S5 always refers to the hierarchical search and Radio/ERP/ABP refer to the radio pulsar search - the usual historical reasons ;-)
Got that.
Quote:
Quote:
[aside]Where does m_EinsteinAdapter get defined - in the BOINC library or somesuch?[/aside]
That's an instance of EinsteinS5R3Adapter and a member of StarsphereS5R3. This is the interface to the BOINC client and the shared memory segment used to pass real-time search information from the science application to the graphics application. As this information is different for S5 and ABP, there're two implementations of the abstract class BOINCClientAdapter.
Ditto.
Quote:
Quote:
- thus StarsphereS5R3 and StarsphereRadio can be returned from a GraphicsEngineFactory::createInstance() call as they ( amongst other things like being an m_EinsteinAdapter ) can be considered of type AbstractGraphicsEngine.
Yes, both are implementations of AbstractGraphicsEngine (but forget about "being an m_EinsteinAdapter").
Yup.
Quote:
Quote:
- presumably one could/would/should add an enumeration constant to the GraphicsEngineFactory::Engines enum within GraphicsEngineFactory.h to indicate a new type - that I will write, call it the HewsonSphere class for this discussion.
Correct!
Quote:
- HewsonSphere need not derive from Starsphere, as my design for a screensaver may have no interest in the particular interface that Starsphere offers.
Also correct. That's the reason why there's a framework. You don't have to care about anything in the "starsphere" folder (almost, see next topic), just create your own and use what's in "framework". Starsphere should only serve as an example of how to use the framework.
Mind you, there are a couple or seven things I will pinch from the Starsphere area. Those star co-ordinate lists for one. But I'll chop and trim them into my own interface.
Quote:
Quote:
- HewsonSphere class could remain virtual, but probably doesn't need to be ( unlike Starsphere ). But it, or a concrete class derived from it if I leave it virtual, also needs to inherit from m_EinsteinAdapter too.
HewsonSphere should be abstract/virtual only if you have one or more children that specialize it. Otherwise it's a single concrete class implementing AbstractGraphicsEngine.
Yup, I'll keep it simplest pro-tem. Can always generalise later.
Quote:
Considering the Einstein[APP]Adapter classes: it's not inheritance, it's a composition. But I suppose that's clear by now, isn't it?
Got that.
Quote:
So this is the only part of the "starsphere" directory that could be of interest to you. When you want to use the information provided by the science apps mentioned above, you need the Einstein[APP]Adapter classes.
Background: the framework is meant to be useful for all BOINC projects, therefore it doesn't contain anything project-specific. Unfortunately this is not 100% true, however, because of the intended plugin concept that's not yet implemented. So for the time being GraphicsEngineFactory contains these tiny project-related bits :-/ A working plugin-concept would let the factory query all available plugins for their identifiers (engine/application) dynamically, so that this information would not have to be stored/maintained manually in its header as it is today (see below).
So quite general. There may be all sorts of weird and wonderful science apps in the future. Weird and wonderful BOINC projects ....
[ 'Hello factory! I'm a HewsonSphere and I work with the EinsteinS5R3 ....' ]
We never did the factory paradigm either. But I can see the difference between concrete factory class objects producing object instances that are ultimately derived from virtual classes vs. an abstract factory class per se. ( I spent half a day up the wrong street on that one ). Phew! 'Virtual' really does mean "to be defined later in a class ultimately derived from this one". Let me guess - somewhere in the world someone has written a factory that creates other factories ....... :-)
Quote:
Quote:
- ( assuming all of the above ) I would leave alone the GraphicsEngineFactory::Applications enumeration as it's none of my business, as I don't write science applications.
- but I need to chose an application within that GraphicsEngineFactory::Applications enumeration so that my HewsonSphere, being of type derived from m_EinsteinAdapter, can respond to do the BOINC communication thingy via.
No, right now you need to specify both, an "engine" and an "application". Both are are needed to identify a specific graphics application (can be the same in your case). The "application" IDs are meant to differentiate between separate implementations of the graphics code for, say, SxRx and ABPx.
Got that.
Quote:
I hope all this makes some sense to you. Let me know if you have more questions. BTW, are you aware of the available documentation (doxygen)?
Blush .... :-) Well caught. I read it after I posted. Today's lesson is : Read The Fine Manual !! :-)
Looking at the resource compiler ( orc.cpp ) - you want better filename checking? I'll make that a side project. Shame standard library C++ doesn't do regex. Mind you if the wrong filename is given it'll fall over pretty quick anyway. And you're likely to be invoking from a makefile, so if the filename is wrong you'd have rather bigger problems.
Cheers, Mike.
( edit ) For that matter, I'll pinch your comment/documentation style too. It could be Doxygen'ed later!
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
There's considerable freedom with the resource compiler. A nifty deal. For example :
- pick an image, say, that you want to use in some way within the screensaver animation.
- think of the form you'll need it in when it will be called/used by some Open GL functionality. Like an array of RGBA values ( three colors plus alpha - the blending/transparency factor ).
- but there are many choices, primarily related to how quick/efficient you want the rendering and in what manner - vertex series, a raster image, a texture map, even a line stippling pattern perhaps. Whatever floats your boat. Mentally I work from an idea of the proposed rendering technique ( so you need to study OpenGL!! ) back through to the best/suitable format to have it stored within the executable.
- give the data a symbolic name ( as a C++ string ) that you will use programmatically to represent it. The resource compiler will associate that string with the C++ type vector. That's essentially a byte array, but with STL vector functionality to call upon ( in particular it's resizable and all that memory management stuff entailed therein ).
- in a '*.orc' file ( 'resources.orc' currently ) supply the association, as described, between the above symbolic name and the actual file name from which the bytes will be retrieved. Excepting comments, denoted by '#" at line start, the lines in this file are of type 'TheSymbolicName|TheFileNameToGetByteDataFrom'.
- this association is kept in a map ( associative array ResourceCompiler::m_ResourceFileMap ) which is used by the ResourceCompiler to drag the data in when called to do so ( ie. the ResourceCompiler::compile() member function ).
- this creates another file of style 'SomethingOrOther.cpp' which then joins your compilation. That name would/should/could be provided in a makefile. Currently :
so this keeps the 'resource cache' naming coherent across the project.
- now there's another map ( ResourceCompiler::m_ResourceDataMap ) correlating the symbolic name you chose originally and the actual byte data ( as a vector ) that you want to be using during your rendering process(es). ResourceCompiler::m_ResourceCodeFile keeps track of the source code file that contains the C++ code produced during ResourceCompiler::compile().
- note the 'SomethingOrOther.cpp' file now contains data from possibly many files : as many as were specified in the '*.orc' file initially.
Phew!! :-)
- NOW the programmatic method for accessing the data is to have a ResourceFactory.
- it picks up on the following members within 'SomethingOrOther.cpp' : c_ResourceIdentifiers, c_ResourceIndex and c_ResourceStorage. These array names were declared as 'extern' when ResourceCompiler::compile() wrote the file ( 'extern' lets you define a symbol in one compilation unit/file but refer to it from another ). See lines 90 thru 107 of ResourceCompiler.cpp .... in other words the ResourceCompiler class actually writes C++ code with 'hard' data declarations.
- the ResourceFactory instance returns pointers to instantiations of type Resource. And Resource has these two public member functions :
- Resource::data() to return a const vector * ( the data from the original file )
- Resource::identifier() to return a string ( the name you chose to represent it )
- but note well : when you invoke ResourceFactory::createInstance( const string identifier ) thenidentifierhas to be the same as the one specified in the *.orc file used to compile the resources.
- all the identifier's have been kept coherent with the content of their respective initial data files throughout the construction chain. A really nifty job Oliver!! :-)
Cheers, Mike.
( edit ) and there's const-ness about liberally all the way through, but you can cast around that if you dare.
( edit ) And I'll have to dust off my Josuttis. Again. :-)
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Phew! 'Virtual' really does mean "to be defined later in a class ultimately derived from this one".
Just to clarify the terminology differences between Java and C++: Java uses the standard terms "interface" and "abstract class" while C++ (IMHO just being C with an OO add-on) does it differently.
In C++ an abstract class is a class that contains at least one abstract method (declared as "pure virtual" (see below), not defined) that's to be defined in an implementing child in order to be instantiated - just like Java but with a different declaration. However, an interface is again just declared as a class but this time it contains only abtract methods.
Be careful when you notice the keyword "virtual": virtual just means that this (declared and defined) method is allowed to be overwritten/substituted by a child class. However, if a virtual declaration ends with "= 0" then this method is an abtract method, or "pure virtual" in C++ terms. Have a look at XMLProcessorInterface.h and AbstractGraphicsEngine.h as an example.
Quote:
Looking at the resource compiler ( orc.cpp ) - you want better filename checking? I'll make that a side project. Shame standard library C++ doesn't do regex. Mind you if the wrong filename is given it'll fall over pretty quick anyway. And you're likely to be invoking from a makefile, so if the filename is wrong you'd have rather bigger problems.
Right, the focus was to embed safely any kind of resource (e.g. fonts, images) in the final executable. ORC's file name checking is, say, sufficient. It might indeed just lead to a build problem that's triggered immediately when there's an error in the Makefile.
Quote:
( edit ) For that matter, I'll pinch your comment/documentation style too. It could be Doxygen'ed later!
Just to clarify the terminology differences between Java and C++: Java uses the standard terms "interface" and "abstract class" while C++ (IMHO just being C with an OO add-on) does it differently.
In Java everything is a class/object, but no multiple inheritance. In C++ maybe/maybe not.
Quote:
In C++ an abstract class is a class that contains at least one abstract method (declared as "pure virtual" (see below), not defined) that's to be defined in an implementing child in order to be instantiated - just like Java but with a different declaration. However, an interface is again just declared as a class but this time it contains only abtract methods.
Be careful when you notice the keyword "virtual": virtual just means that this (declared and defined) method is allowed to be overwritten/substituted by a child class. However, if a virtual declaration ends with "= 0" then this method is an abtract method, or "pure virtual" in C++ terms. Have a look at XMLProcessorInterface.h and AbstractGraphicsEngine.h as an example.
Thank you kindly. I stand corrected. Yes the C++/Java terminology difference is significant. Hey, I'm learning stuff! :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Be careful when you notice the keyword "virtual": virtual just means that this (declared and defined) method is allowed to be overwritten/substituted by a child class. However, if a virtual declaration ends with "= 0" then this method is an abtract method, or "pure virtual" in C++ terms. Have a look at XMLProcessorInterface.h and AbstractGraphicsEngine.h as an example.
Thank you kindly. I stand corrected. Yes the C++/Java terminology difference is significant. Hey, I'm learning stuff! :-)
Also note that in Java, all methods are virtual, and you can't change that. In C++, you get to choose.
RE: I'm trying to belt Suse
)
Go to software.opensuse.org, state your version and install what you need. I am using 10.3 and it works. I've compiled mplayer and other tools.
Tullio
RE: RE: I'm trying to
)
Ah, well. I have Suse 11.1 so maybe I ought to slide back to 10.x ......
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Ok, here we
)
Ok, here we go...
I would phrase it differently, but in principle this is correct!
Correct. The whole notion of a "GraphicsEngine" stems from the idea of different visualization "plugins" - Starsphere being only one of them, coming in two different styles (one each for S5 and ABP).
At some point I want(ed) to implement the different engines as true plugins that are loaded dynamically during GFX startup. Which visulization engine/plugin gets used could be set by the user in the project specific preferences for example... In order to prepare for this I had to provide a common interface for all future implementations - that's what AbstractGraphicsEngine is all about.
Yep, it's one specific engine but in two different styles/flavors. One's used for S5Rx and one for ABP. Thus Starsphere contains the common parts of both flavors.
Nope, but we already discussed that :-) Both classes contain the respective application-specific parts. Don't be confused by the somehow outdated naming: S5 always refers to the hierarchical search and Radio/ERP/ABP refer to the radio pulsar search - the usual historical reasons ;-)
That's an instance of EinsteinS5R3Adapter and a member of StarsphereS5R3. This is the interface to the BOINC client and the shared memory segment used to pass real-time search information from the science application to the graphics application. As this information is different for S5 and ABP, there're two implementations of the abstract class BOINCClientAdapter.
Yes, both are implementations of AbstractGraphicsEngine (but forget about "being an m_EinsteinAdapter").
Correct!
Also correct. That's the reason why there's a framework. You don't have to care about anything in the "starsphere" folder (almost, see next topic), just create your own and use what's in "framework". Starsphere should only serve as an example of how to use the framework.
HewsonSphere should be abstract/virtual only if you have one or more children that specialize it. Otherwise it's a single concrete class implementing AbstractGraphicsEngine.
Considering the Einstein[APP]Adapter classes: it's not inheritance, it's a composition. But I suppose that's clear by now, isn't it? So this is the only part of the "starsphere" directory that could be of interest to you. When you want to use the information provided by the science apps mentioned above, you need the Einstein[APP]Adapter classes.
Background: the framework is meant to be useful for all BOINC projects, therefore it doesn't contain anything project-specific. Unfortunately this is not 100% true, however, because of the intended plugin concept that's not yet implemented. So for the time being GraphicsEngineFactory contains these tiny project-related bits :-/ A working plugin-concept would let the factory query all available plugins for their identifiers (engine/application) dynamically, so that this information would not have to be stored/maintained manually in its header as it is today (see below).
No, right now you need to specify both, an "engine" and an "application". Both are are needed to identify a specific graphics application (can be the same in your case). The "application" IDs are meant to differentiate between separate implementations of the graphics code for, say, SxRx and ABPx.
I hope all this makes some sense to you. Let me know if you have more questions. BTW, are you aware of the available documentation (doxygen)?
Best,
Oliver
Einstein@Home Project
RE: Ok, here we
)
I see now. In true OO flavour. Very much like a Java interface.
Got that.
Ditto.
Yup.
Mind you, there are a couple or seven things I will pinch from the Starsphere area. Those star co-ordinate lists for one. But I'll chop and trim them into my own interface.
Yup, I'll keep it simplest pro-tem. Can always generalise later.
Got that.
So quite general. There may be all sorts of weird and wonderful science apps in the future. Weird and wonderful BOINC projects ....
[ 'Hello factory! I'm a HewsonSphere and I work with the EinsteinS5R3 ....' ]
We never did the factory paradigm either. But I can see the difference between concrete factory class objects producing object instances that are ultimately derived from virtual classes vs. an abstract factory class per se. ( I spent half a day up the wrong street on that one ). Phew! 'Virtual' really does mean "to be defined later in a class ultimately derived from this one". Let me guess - somewhere in the world someone has written a factory that creates other factories ....... :-)
Got that.
Blush .... :-) Well caught. I read it after I posted. Today's lesson is : Read The Fine Manual !! :-)
Looking at the resource compiler ( orc.cpp ) - you want better filename checking? I'll make that a side project. Shame standard library C++ doesn't do regex. Mind you if the wrong filename is given it'll fall over pretty quick anyway. And you're likely to be invoking from a makefile, so if the filename is wrong you'd have rather bigger problems.
Cheers, Mike.
( edit ) For that matter, I'll pinch your comment/documentation style too. It could be Doxygen'ed later!
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Thinking out loud. No need to
)
Thinking out loud. No need to answer. :-)
There's considerable freedom with the resource compiler. A nifty deal. For example :
- pick an image, say, that you want to use in some way within the screensaver animation.
- think of the form you'll need it in when it will be called/used by some Open GL functionality. Like an array of RGBA values ( three colors plus alpha - the blending/transparency factor ).
- but there are many choices, primarily related to how quick/efficient you want the rendering and in what manner - vertex series, a raster image, a texture map, even a line stippling pattern perhaps. Whatever floats your boat. Mentally I work from an idea of the proposed rendering technique ( so you need to study OpenGL!! ) back through to the best/suitable format to have it stored within the executable.
- give the data a symbolic name ( as a C++ string ) that you will use programmatically to represent it. The resource compiler will associate that string with the C++ type vector. That's essentially a byte array, but with STL vector functionality to call upon ( in particular it's resizable and all that memory management stuff entailed therein ).
- in a '*.orc' file ( 'resources.orc' currently ) supply the association, as described, between the above symbolic name and the actual file name from which the bytes will be retrieved. Excepting comments, denoted by '#" at line start, the lines in this file are of type 'TheSymbolicName|TheFileNameToGetByteDataFrom'.
- this association is kept in a map ( associative array ResourceCompiler::m_ResourceFileMap ) which is used by the ResourceCompiler to drag the data in when called to do so ( ie. the ResourceCompiler::compile() member function ).
- this creates another file of style 'SomethingOrOther.cpp' which then joins your compilation. That name would/should/could be provided in a makefile. Currently :
line 49 :
'RESOURCESPEC = resources'
lines 101 - 104:
# resource compiler
$(RESOURCESPEC).o: $(STARSPHERE_SRC)/$(RESOURCESPEC).orc
$(STARSPHERE_INSTALL)/bin/orc $(STARSPHERE_SRC)/$(RESOURCESPEC).orc $(RESOURCESPEC).cpp
$(CXX) -g $(CPPFLAGS) -c $(RESOURCESPEC).cpp -o $(RESOURCESPEC).o
so this keeps the 'resource cache' naming coherent across the project.
- now there's another map ( ResourceCompiler::m_ResourceDataMap ) correlating the symbolic name you chose originally and the actual byte data ( as a vector ) that you want to be using during your rendering process(es). ResourceCompiler::m_ResourceCodeFile keeps track of the source code file that contains the C++ code produced during ResourceCompiler::compile().
- note the 'SomethingOrOther.cpp' file now contains data from possibly many files : as many as were specified in the '*.orc' file initially.
Phew!! :-)
- NOW the programmatic method for accessing the data is to have a ResourceFactory.
- it picks up on the following members within 'SomethingOrOther.cpp' : c_ResourceIdentifiers, c_ResourceIndex and c_ResourceStorage. These array names were declared as 'extern' when ResourceCompiler::compile() wrote the file ( 'extern' lets you define a symbol in one compilation unit/file but refer to it from another ). See lines 90 thru 107 of ResourceCompiler.cpp .... in other words the ResourceCompiler class actually writes C++ code with 'hard' data declarations.
- the ResourceFactory instance returns pointers to instantiations of type Resource. And Resource has these two public member functions :
- Resource::data() to return a const vector * ( the data from the original file )
- Resource::identifier() to return a string ( the name you chose to represent it )
- but note well : when you invoke ResourceFactory::createInstance( const string identifier ) then identifier has to be the same as the one specified in the *.orc file used to compile the resources.
- all the identifier's have been kept coherent with the content of their respective initial data files throughout the construction chain. A really nifty job Oliver!! :-)
Cheers, Mike.
( edit ) and there's const-ness about liberally all the way through, but you can cast around that if you dare.
( edit ) And I'll have to dust off my Josuttis. Again. :-)
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Hi Mike, RE: Phew!
)
Hi Mike,
Just to clarify the terminology differences between Java and C++: Java uses the standard terms "interface" and "abstract class" while C++ (IMHO just being C with an OO add-on) does it differently.
In C++ an abstract class is a class that contains at least one abstract method (declared as "pure virtual" (see below), not defined) that's to be defined in an implementing child in order to be instantiated - just like Java but with a different declaration. However, an interface is again just declared as a class but this time it contains only abtract methods.
Be careful when you notice the keyword "virtual": virtual just means that this (declared and defined) method is allowed to be overwritten/substituted by a child class. However, if a virtual declaration ends with "= 0" then this method is an abtract method, or "pure virtual" in C++ terms. Have a look at XMLProcessorInterface.h and AbstractGraphicsEngine.h as an example.
Right, the focus was to embed safely any kind of resource (e.g. fonts, images) in the final executable. ORC's file name checking is, say, sufficient. It might indeed just lead to a build problem that's triggered immediately when there's an error in the Makefile.
Recommended :-)
Best,
Oliver
Einstein@Home Project
RE: Thinking out loud. No
)
Just one comment required: you got it!
Oliver
Einstein@Home Project
RE: Just to clarify the
)
In Java everything is a class/object, but no multiple inheritance. In C++ maybe/maybe not.
Thank you kindly. I stand corrected. Yes the C++/Java terminology difference is significant. Hey, I'm learning stuff! :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: In Java everything is
)
Nope, in Java an interface is an interface, not a class. Java provides an explicit entity (and a keyword) while C++ doesn't.
Oliver
Einstein@Home Project
RE: RE: Be careful when
)
Also note that in Java, all methods are virtual, and you can't change that. In C++, you get to choose.