NAG CPP Interface
Frequently Asked Questions

Settings help

CPP Name Style:



Below you will find answers to the questions we are asked the most about the NAG CPP Interface

Where can I download the NAG CPP Interface?
You can download the latest version of the NAG CPP Interface from here.
We recommended that you always use the latest version of the NAG CPP Interface however if this is not possible, then a full list of available versions can be obtained from here.
How do I give feedback?
Feedback on all NAG products is always welcome, this is particularly true for the NAG CPP Interface, and is the primary purpose of this initial offering.
Please send all comments and suggestions to the NAG Technical Support Service.
Do I need a licence to use the NAG CPP Interface?
the NAG CPP Interface is supplied as source code and therefore is not licence managed as such. However, it makes use of the algorithmic engine powering the NAG Library which does require a valid licence to work.
Will I get the same results using the NAG CPP Interface as I do using the CL interfaces?
All routines introduced into the CL interfaces on or after Mark 9 make use of the same algorithmic engine as the NAG CPP Interface, routines introduced before Mark 9 may not.
For routines that use the algorithmic engine we would expect the NAG CPP Interface and the CL interfaces to give the same answer, modulo small differences due to the way any data is supplied. For other routines we would expect the results to be equivalent.
Will I get the same results using the NAG CPP Interface as I do using the FL interfaces?
All functions accessed via the FL interfaces use the same algorithmic engine as the NAG CPP Interface. As such we would expect all functions to give the same answer, modulo small differences due to the way any data is supplied.
Am I free to alter the source files supplied with the NAG CPP Interface?
Yes. However, it should be borne in mind that the more a header is changed, the less likely NAG are able to help if any issues arise.
Why does the NAG CPP Interface support data containers of type X, but not of type Y?
Due to finite resources there is a limit to the number of different data containers we can actively support. However, if you have a particular type of container that you would like us to support please contact the NAG Technical Support Service and we will see what we can do.
The function I want is not in the NAG CPP Interface, where is it?
The initial offering for the NAG CPP Interface consists of only a small subset of routines and is primarily to elicit feedback on the design before rolling out across the whole NAG Library, as such the functions included were chosen to cover a range of interface features rather than as being suitable for a particular purpose.
If you have a particular function that you are desperate to use please contact the NAG Technical Support Service and we will see what we can do.
Can I use my own custom data container as arguments to functions?
Yes. The functions in the NAG CPP Interface are implemented in such a way that non-scalar arguments will accept any data type as long as that data type has a number of standard methods implemented. These methods are detailed in Using Arbitrary Data Containers.
If you are unable or unwilling to implement the required standard methods in your data container then it can still be used as an argument to function, however it will take a bit more work. In these cases you will need to supply a specialisation to a number of classes. See Non-standard Data Containers for more information.
Can I use my own custom data container as arguments to a callback?
Yes. However you will need to supply a specialisation of nagcpp::data_handling::convert_nag_array_to_user_t for your custom data container. See As Arguments to a Callback Function for more information.
Will the interfaces change between releases?
Possibly. Unlike the FL interfaces, the interface for the functions supplied in the NAG CPP Interface may change between releases. Whilst we do not expect a given function to change often, if at all, we do not want to rule out the possibility. This allows us more flexibility should an interface improvement or simplification become possible.
In all cases where an interface has changed we will endeavour to supply an overload of the new interface that matches the old one to aid backwards compatibility.