Todo List

Member atm::HumidAirRayleighModel::EvaluateRayleighScattering (const utl::Point &xA, const utl::Point &xB, const double angle, const double distance, const std::vector< double > &wLength) const

Add error calculation

Member atm::NonParametricXMLMieModel::EvaluateMieAttenuation (const utl::Point &xInit, const utl::Point &xFinal, const std::vector< double > &wLength) const

Propagation of uncertainties of the parameters.

Member atm::ParametricXMLMieModel::EvaluateMieAttenuation (const utl::Point &xInit, const utl::Point &xFinal, const std::vector< double > &wLength) const

Propagation of uncertainties of the parameters.

Member atm::ParametricXMLRayleighModel::EvaluateRayleighAttenuation (const utl::Point &xInit, const utl::Point &xFinal, const std::vector< double > &wLength) const

Calculate the error propagation of xRayleigh

Member atm::ParametricXMLRayleighModel::EvaluateRayleighScattering (const utl::Point &xA, const utl::Point &xB, const double angle, const double distance, const std::vector< double > &wLength) const

Add error calculation

Member atm::ParametricXMLRayleighModel::GDistance (const utl::Point &xA, const utl::Point &xB) const

This function eventually have to be moved to the ParametricProfileModel (waiting to see if it is used somewhere else)

Class Block

Implement support to test padding requirements when configuring the software. Alternatively, think of a way to determine the size of a corsika block with padding at run-time and use C++'s placement new to deal with padding offsets.

Deal with byte-ordering issues to makes showers transferable between MSB and LSB architectures.

Class det::IdOnlyCreator

As stated by the comment client code shouldn't use this class, it's meant to be used only within the detector hierarchy. This fact isn't actually enforce by some language construct. Reciprocal friendship (between the class that uses ComponentGroup and the contained class) could be used and then this policy could be implemented on the first class as a private member), at first this was discarded.

Class det::MPositionable< Config >

All the non template-dependant code may be put in a superclass and the template dependant code be kept here. Then the template MPositionable would derive from the former. In this way some bloat (of the generated object files) may be avoided. See next todo about Boost's shared_ptr. See Scott Meyers' "Effective C++", item 44 "Factor parameter-independent code out of templates".

Note that the template argument is used as the callback mechanism to resolve particular datum. This class could be made non-template in two ways. The first is obviously to have, in Java parlance, an interface defined with the callback method, and so accept objects deriving from it. Another posibility is to borrow the idea of Boost's shared pointers; that is to define that interface privately, have a private implementation of it and then wrap with the second the objects received by a templated constructor. See "My Most Important C++ Aha! Moments...Ever" by Scott Meyers http://www.artima.com/cppsource/top_cpp_aha_moments.html "External Polymorphism" by Chris Cleeland et al. http://www.cs.wustl.edu/~schmidt/PDF/External-Polymorphism.pdf "The shared_ptr Class" by Danny Kalev http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=239 and of course Boost's docs & srcs.

This class could be split into two clases:

A pure abstract interface with the required methods that make a "positionable" (GetPosition, GetLocalCoordinateSystem). In relation to this note that users of this class won't be likely to be treated polymorphically, so this interface may not be needed.
A base implementation of the former. Given this, the clients could choose between mixing-in the functionality via (posibly multiple) inheritance (the choice favored by the current single class implementation) or composition plus method-call delegation (in an idiom more typical of Java). What would be also necesary in this second approach is to change the stategy for GetReferenceCoordinateSystem, what should be done is something like giving directly a reference to that system via the nested-object's constructor (in addition to the current reference to this, used to resolve GetData). Another possibility (instead of a 2nd argument in constructor) would be to split even more the classes, and put GetReferenceCoordinateSystem in less specific interface, that would be extended by the original interface, implemented by the delegatee class and required by the delegate (in it's constructor). Of course, given the use of templates (for GetData resolution) that interface with GetReferenceCoordinateSystem may be implicitly required on the type, that is, C++ parlance, a concept.

In the light of the first usage (within a hierarchy of det::DetectorComponent) another last posibility would be to define a type to mix "positionable" with "component", let's say something like PositionableDetectorComponent: in this way multiple inheritance would be avoided.

This class doesn't handle UTM points. For that case, in addition to the 3 components band & zone are required (and there's no coordinate type). Up to now the neccesity was only to work with derived coordinate systems (which is materialized by the presence of the GetReferenceCoordinateSystem method).

Member det::XXMLManager< Info >::FindMatchingBranch (const utl::Branch &parent, const std::string &compName, Matcher &matcher, bool isReportingErrors)

This can be policied away. The double functionality should be polished a little to be refactor a function.

Member det::XXMLManager< Info >::FindModelBranch (const utl::Branch &componentModels, const utl::Branch &compBranch, const std::string &name) const

This may be put in a policy.

Member det::XXMLManager< Info >::Initialize ()

Fill a set a configurable property tags, so as to have a quick 'not found' if the query goes to a non-sensical property name, or to do some prefetching (these two conditions can be, of course, be treated as two differebt issues).

Class evt::ComponentGroup< Component >

The friend declation that may be needed to be granted to checked_delete reveals the implementation of this class. It's somewhat the same that happens in this Event hierarchy with utl::LameShadowPtr in the sense that the class that will be buried inside the ShadowPtr gives friendship to ShadowPtr because it happens that ShadowPtr it's used to contain that class' instances in the parent object within the hierarchy. Another possibility is to leave the destructors public (but, of course, keeping restricted the means of construction), it doesn't seem likely that, by chance, the destructor is called from client code. Another last possibility (in the case of having to grant friendship to a type) would have been to allow typedef-names in friend declaration, so that an appropiate alias is declared and then friendship is declared using that alias: so that the real underlying type is hidden. Unfortunately up to now it isn't allowed, see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1791.pdf

Class evt::LaserData

insert a dedicated Light Profile?

Class evt::RadioSimulation

a lot

Class evt::SimRadioPulse

a lot

Class FdElectronicsSimulatorOG::FdElectronicsSimulator

Virtual channels need to be reprogrammed. The electronics noise does not scale with the VCgain ratio!!!

Class G4StationPrimaryGenerator

Units and coordinate systems need to be checked

Class G4TankPrimaryGenerator

Units and coordinate systems need to be checked

Class G4XTankPrimaryGenerator

Units and coordinate systems need to be checked

Class io::REASFile

readin of single simulation from .reas file

Class io::REASH5File

readin of single simulation from .reas file

Class mdet::MHierarchyInfo

The raw const char* const may be replaced with containers from http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/classes.html

Class mdet::Module

Maybe a boost::zip_iterator to allow simultaneous iteration.

Class mdet::Pixel

So far, only cross-talk. Other properties that may be added (once properly defined) here are: gain, MuonBackground, SPESpectra, SPEShift.

Class mdet::Scintillator

Check some library for geometrical stuff (ROOT or some other CERN related stuff). Anyway, it seems better to hide that concern to the clients of this class.

Class SiPM::h

No dark rate simulation

Class utl::ConsecutiveEnumFactory< EnumType, last, tags, NoConversionPolicy, first >

Better diagnosis based on the actual enumeration type name.

Maybe is useful to default the tags to null, and so handle properly the situation.

Telescope::CachePixelCalibrations() handles a situation like this. It seems better to avoid that style.

It seems better to have the convertion be defined "next to" the list of enumerators,and avoid client code (Telescope in this case) to explicitly "know" the full list. Anyway in this case there is a pretty tight relation between both classes.
Declares a double to be filled by GetPixelData which is the usual templated proxy function for managers. I do not see why not an int?
Then C-style casts the double value to int. By the way, it does so in the ugly way "(int)value" instead of "int(value)". See Offline's style guide for C++ code.
Then does an in-place exhaustive switch-case over the enumeration.
Has a default to unkown that allows "trash" in the configuration data (when there is also a precise value for unknown).

For compile-time checking consider the use of Boost library, in particular boost/type_traits/is_enum.hpp and boost/concept_check.hpp. By now it does not seem worth of it (mainly due that as of Boost v1.34.1 is_enum is broken under some compilers).

Can the case of non-consecutive values be handled (without passing as a template argument an array with the values)?. In this case of passing the values via an another arg, it seems that it cannot be used to determine the case: one can think (at least I did) that this new argument can defaulted to null, and then if the user does not supply it an special implementation (assuming consecutive values) can be instantiated thanks to a class/struct specialization for null pointers. The problems seems to be item 5 paragraph 2 of section 14.3.2 (Template non-type arguments) of the ISO/IEC 14882 C++ Standard where it is said: "Although 0 is a valid template-argument for a non-type template-parameter of integral type, it is not a valid template-argument for a non-type template-parameter of pointer type". In any case, it seems little risky to allow a default parameter, given thet its omission would imply the asumption of consecutiveness. So it would be better to code a separate class with the following template signature: template< typename EnumType, unsigned int NumEnum, const EnumType Values[], const char* const Tags[], class NoConversionPolicy = ThrowPolicy<EnumType, utl::IOFailureException>, >

Class utl::ErrorLogger

General routing

Improve message formating

Member utl::NucleusProperties::GetMass () const override

Replace this with a more precise expression

Class utl::ReferenceEllipsoid

Calculate tangent plane at a given point in a given coordinate system.

Member utl::ReferenceEllipsoid::GetEllipsoidIDFromString (const std::string &str)

Should use a static array of strings (if the number of ellipsoids grows).