Automatically group member functions based on constness - c++

Can doxygen automatically create groups like "Accessors" and "Modifiers", i.e. group member functions based on const-ness? If not, are these groups common enough that one should consider spending the effort to create them manually?

Related

How can you detect that instances from different WMI Classes are the same?

If I have two different classes for example Win32_PerfFormattedData_Tcpip_NetworkInterface and Win32_PerfRawData_Tcpip_NetworkInterface can I somehow figure out if they return same instances?
In my example I know they return data for the same instance and if I select Name from those 2 classes I can get instance identifiers. But can I detect via WQL or something similar if two classes return data for the same instances?
It depends which WMI classes you want. There isn't a general way to do it for all WMI classes. Some have the relationship built while others do not. In the case for the performance counters and the raw vs formatted, yes the relationship exists but you need to query the class qualifier "AutoCook_RawClass".
For example class Win32_PerfFormatted_PerfDisk_LogicalDisk has a AutoCook_RawClass of Win32_PerfRawData_PerfDisk_LogicalDisk.
Alternatively, thought i'm not 100% sure it's always the case, I do believe that for the Win32_Perf stuff a simple string replacement of "Formatted" to "Raw" and vice versa will get you what you need.

Can Doxygen sort members of member groups alphabetically by name?

I am documenting a very large namespace (Fortran module holding a lot of global variables). At first I just configured Doxygen to alphabetize the output. Then I thought it would be useful to group the items into member groups. However I don't seem to be able to achieve both at once. If I use member groups, the elements are not sorted alphabetically. Is there a configuration to make it happen? I'm not talking about alphabetizing the groups -- the configuration for that seems well documented. Thanks.

How can I see all variables available inside a Velocity Template?

Is it possible to display all variables available inside a Velocity Template?
Let's say 1 developer pass 2 values to template: $headline and $body. Another developer has to deal with those 2 variables. How would he know names of those variables?
Right now we use 3 solutions:
we simply say what variables are present on templates
we agreed with all developers that all data we pass to template should be included into 1 map ($data)
developer that pass variables to templates has to update template as well and describe all the fields available on it.
I'm looking for way to do this correctly. Right now I'm not really satisfied with all approaches, but 2-nd looks like most preferable.
The short answer is:
$context.keys
The variables and "tools" are accessed by the templates via the velocity "context". If the context tool is available, you can request the list of variables via $context.keys. If not, you need to add the tool ContextTool to the context. How this is done depends on your application.
Although it's technically possible to list all keys in the context, I'm not sure it's also good practice in the situation you describe.

what would be the purpose of Automatic Variable in ILOG Jrules?

In the rule studio , while verbalizing a BOM object , there is checkbox called "Generate Automatic Variable" , what would be its purpose ? Is it a global variable ?
Automatic variables are there for you to access the working memory object directly via the verbalization.
It based on the usage you want to use :)
there is no better way than an other.
if you want to populate the working memory and let the engine deal with the manipulation then you can use automatic variables
If you want to control everything then use rule variable (pre conditions - starting with "definitions")
It can depend on how business users want to create/author rules, as well
The doc says:
Because objects in the working memory cannot be named or
verbalized, you must bind them to rule variables or automatic variables
by defining a pattern in the definitions of the rule artifact to manipulate
them
– At run time the rule engine cycles through all the objects in working memory to
find objects that match the definition of the rule variable
– The rule engine creates a separate rule instance for every match, which works
on the object that caused that particular rule instance to be created
• You can also use rule variables simply to enhance the way your rules
are written
– For example to reduce the length of your conditions or your actions when you
author rules, or to define a constant used in the rule
I have been using JRules for years and it all depends on the design you want to implement.
As a JRules instructor, I would say: Pick up what you prefer but personnally I don't use them. Except quick POCs.
Hope it helps
It is more like a global variable which can be accessed anywhere in the rule project.
Please Refer to the documentation especially the section about the setup of automatic variables

Most efficient way to add data to an instance

I have a class, let's say Person, which is managed by another class/module, let's say PersonPool.
I have another module in my application, let's say module M, that wants to associate information with a person, in the most efficient way. I considered the following alternatives:
Add a data member to Person, which is accessed by the other part of the application. Advantage is that it is probably the fastest way. Disadvantage is that this is quite invasive. Person doesn't need to know anything about this extra data, and if I want to shield this data member from other modules, I need to make it private and make module M a friend, which I don't like.
Add a 'generic' property bag to Person, in which other modules can add additional properties. Advantage is that it's not invasive (besides having the property bag), and it's easy to add 'properties' by other modules as well. Disadvantage is that it is much slower than simply getting the value directly from Person.
Use a map/hashmap in module M, which maps the Person (pointer, id) to the value we want to store. This looks like the best solution in terms of separation of data, but again is much slower.
Give each person a unique number and make sure that no two persons ever get the same number during history (I don't even want to have these persons reuse a number, because then data of an old person may be mixed up with the data of a new person). Then the external module can simply use a vector to map the person's unique number to the specific data. Advantage is that we don't invade the Person class with data it doesn't need to know of (except his unique nubmer), and that we have a quick way of getting the data specifically for module M from the vector. Disadvantage is that the vector may become really big if lots of persons are deleted and created (because we don't want to reuse the unique number).
In the last alternative, the problem could be solved by using a sparse vector, but I don't know if there are very efficient implementations of a sparse vector (faster than a map/hashmap).
Are there other ways of getting this done?
Or is there an efficient sparse vector that might solve the memory problem of the last alternative?
I would time the solution with map/hashmap and go with it if it performs good enough. Otherwise you have no choice but add those properties to the class as this is the most efficient way.
Alternatively, you can create a subclass of Person, basically forward all the interface methods to the original class but add all the properties you want and just change original Person to your own modified one during some of the calls to M.
This way module M will see the subclass and all the properties it needs but all other modules would think of it as just an instance of Person class and will not be able to see your custom properties.
The first and third are reasonably common techniques. The second is how dynamic programming languages such as Python and Javascript implement member data for objects, so do not dismiss it out of hand as impossibly slow. The fourth is in the same ballpark as how relational databases work. It is possible, but difficult, to make relational databases run the like the clappers.
In short, you've described 4 widely used techniques. The only way to rule any of them out is with details specific to your problem (required performance, number of Persons, number of properties, number of modules in your code that will want to do this, etc), and corresponding measurements.
Another possibility is for module M to define a class which inherits from Person, and adds extra data members. The principle here is that M's idea of a person differs from Person's idea of a person, so describe M's idea as a class. Of course this only works if all other modules operating on the same Person objects are doing so via polymorphism, and furthermore if M can be made responsible for creating the objects (perhaps via dependency injection of a factory). That's quite a big "if". An even bigger one, if nothing other than M needs to do anything life-cycle-ish with the objects, then you may be able to use composition or private inheritance in preference to public inheritance. But none of it is any use if module N is going to create a collection of Persons, and then module M wants to attach extra data to them.