I tried to output a long double to the console directly using qDebug() and indirectly via QString::number() but both do not accept long double.
Is it true that there is no easy way of printing a long double floating point number to the console using Qt? Why?!
You can provide your own overload of operator<<():
QDebug& operator<<(QDebug& d, long double f)
{
return d << static_cast<double>(f);
}
This won't show you any extra precision, of course, but may be what you need.
Be aware, however, that a future version of Qt might implement such a function, putting you in violation of the One-Definition Rule. To avoid this, you should guard it with an appropriate #if test for the exact Qt version (or range of versions) that you have verified do not provide a conflicting definition. Also, please consider contributing your implementation to Qt.
There's no overarching reason. At least as of Qt 5.6, nobody bothered to implement it. That's all.
Related
I have a C++ template function that looks like
template <class T>
void Item::SetValue(T value){
std::ostringstream oss;
oss << value;
this->value = oss.str();
}
It's been working fine for years until today when my OS (vxworks) threw an SPE exception at me. This basically means I was trying to do floating point arithmetic in a task context that doesn't allow it. This would be fine if I was indeed doing any floating point stuff, but I in fact am just passing a uint32_t to this function. However there are 100s of calls to this function elsewhere from other modules, so who knows what C++ has generated.
I need to know for sure this is the problem (I'm 99% sure) so I want to know if there's any way for me to figure out what function C++ compiler generated for that call. Is there any way?
I may have to ask a new question. I found in the debugger that it is using Item::SetValue<unsigned int> and that it is actually throwing the exception in std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char>>>::do_put (at least, i think). This is the instruction output, and it is failing in evstdd which is definitely in the SPE set. Still don't know why it wants to do any floating point stuff.
Is it possible that
oss << value
Will always treat value as a float, just in case? IE in std::num_put? I don't know how I'll get around this.
Instruction set
Yes, you can use type_traits
if(std::is_same_v(T, uint32_t)) { /*debug info*/ }
The classical solution is to add to the body of the function:
static_assert(!std::is_floating_point_v<T>);
I am relatively new to C++ - I leanerd it some 6+ years ago, but have never really used it until some months ago.
What is the scenario:
Considerably large system with a lot of modules.
Desired Output:
Modules (namely X) "expose" certain functions to be called over network and have the result sent back to the caller (namely Y)
The caller Y doesn´t know any info about X, despite what was exposed by the library (function name and parameters).
The calling of function in X from the library will have to happen through a string received from Y - or a set of strings, as there will be parameters as well.
Ideally what I want to have is something as generic as possible with variable return/paramaters types, or some kind of type-erasure - owing to the fact that I don´t know which functions each module will want to expose. I reckon its quite utopic to get something like that running in C++. But hopefully with pre-determined possible return/parameter types, it is feasible. The communication is not a problem for now, what matters is what should be done in the module side.
Question:
Would it be possible to accomplish such thing using C++ and Boost ? I would be really greateful if someone could give me some guidelines - literature/tutorials/(pseudo)code examples and so on and so forth. I am ofc not expecting a full solution here.
Possible solution:
I am a little bit lost as to which "functionalities" of the languages I can/should use - mainly due to my restrictions in the project.
I thought about using Variadic Templates and found the question below, which really helps, the only problem is that Variadic Templates are not supported in VS2010.
Generic functor for functions with any argument list
After some extensive research in the Web, the closest answer I got was this:
map of pointers to functions of different return types and signatures
The scenario is pretty much the same. The difference, however, seems to me that the OP already knows beforehand the return/parameters the functions he will be using. Due to my low reputation (I just joined) I unfortunately cannot ask/comment anything there.
TBH I didn´t get that well how to accomplish what the selected answer explains.
Using maps is a way, but I would have to store objects which contains function pointers (as also answered in the question), but as it is possible to see in the provided code by the user, it does have some hard-coded stuff which I wasn´t desiring to have.
Further clarifications:
Yes, I am restricted to use C++ AND VS2010 SP1.
No, despite Boost, I cannot use any other 3rd library - it would be great to be able to use some Reflection libraries such as CPGF http://www.cpgf.org/ (even though I am not 100% sure if thats what I really need)
Minor Edit:
- Scripting language bindings (such as LUA) are indeed a way to go, yet I didn´t want to include it in the project.
I hope someone can shed light on this problem!
Thanking in advance for any input!
Looks like you're needed a little reflection module. For example we have a struct of method info such as:
struct argument_info {
std::string name;
std::string type;
std::string value;
}
struct method_info {
std::string method_name;
std::string return_type;
std::list<argument_info> arguments;
}
then compile a dll with all exported functions
extern"C" __declspec(dllexport) void f1(int a, int b){/*...*/}
extern"C" __declspec(dllexport) int f1(std::string a, int b, char* c){ return x; }
in the interpreter's code:
void call_function(method_info mi, argument_info& t_return)
{
/* let g_mi be a map, where key is a std::string name of the method and the
value is method_info struct */
if(!g_mi->find(mi.method_name))
throw MethodNotFindException
if(g_mi[mi.method_name].arguments.size() != mi.arguments.size())
throw InvalidArgumentsCountException;
for(int i = 0; i < g_mi[mi.method_name].arguments.size(); i++)
{
if(g_mi[mi.method_name].arguments[i].type != mi.arguments[i].type)
throw InvalidArgumentException;
}
t_return = module->call(mi.arguments);
}
I hope it may help you.
I'm writing a C++ class that stores some double values in a vector (called mpValues) and calculates their average. When constructed, the value array is empty, so performing this calculation would return 0.0/0.0.
I decided that asking for the mean of zero values is a error. Therefore, it would be best to return NaN and display an error message, so that the user is made aware of that problem.
The code looks like this:
double Average::CalculateAverage() const
{
if(mpValues->size() == 0){
std::cerr << "Instance of Average at: " << this << " contains no values.\n"
<< "In this case the arithmetic mean is defined as NaN." <<std::endl;
return 0.0/0.0;
}
else{
...calculate the arithmetic mean
}
}
Is this a sensible approach, or do you have better suggestions? Usually, I wouldn't be so fussy, but this is a test for a job offer so I'd like to avoid bad decisions.
Thanks in advance!
The standard options are to return NaN, throw an exception, or return an option, such as boost::optional. There are advantages and disadvantages to each, which have been reviewed in detail by numerous people. Just do not display error messages within the function, since this violates the single responsibility principle.
You've already answered the question:
I decided that asking for the mean of zero values is an error.
Thus, there is no need to return NaN or handle zero division. You can create your own exception class (e.g. EmptyVectorError) and throw and catch it.
this is a C++ question, so we should give a C++ answer. From the single-responsibility principle (mentioned by Don Reba), we conclude that reporting an error from within your function is not really appropriate. There are two main options.
1 specify clearly that calling your average(container) with an empty container is undefined behaviour (UB). This is standard practice with many algorithms in the C++ std library. It allows you to ignore the possibility of an empty container and just return sum/size(). You may add assert(size()>0); (or similar) in debug mode.
2 explicitly allow for empty containers in the API (which I think is what you wanted to). In this case, returning sum/size() is inappropriate. It may return NaN or trigger a signal, depending on the error settings, but even a NaN is not easy to catch (I think isnan() is not a standard library function). So you must somehow return the undefined result in a clean way. This can be done by throwing an appropriate exception or by returning a type, such as boost::optional<> (suggested by usta), which explicitly allows for an undefined value that is not an error (unlike NaN with double).
I consider throwing an exception as the most appropriate way in C++ (if you go for option 2).
Change the return type to boost::optional<double>, I'd suggest.
Link to Doc
You have 2 options - either return NaN or throw an exception. What you should do, depends on the usage.
1) the client displays the mean only: then I would choose to simply return NaN. This way, the client is not forced to write error handling code for something he doesn't bother.
2) the client calculates new values using the mean: then it is difficult. By throwing an exception, you force him to handle it explicitly. This can be a good thing. On the other hand - the double value NaN can be used in calculations as far as I know. It also depends on the rest of your work. If you always use exceptions, you should use one as well. If you always use error codes, you should use NaN. If you mix - you should clean that up.
P.S.: I wouldn't write 0.0/0.0 but use std::numeric_limits instead. It's easier to read.
I'm trying to convert a double to float as well as various integer types inside a dll, which is used as a Game Maker extension. I don't need a sensible result if the double doesn't fit the range of the target types, so I simply used a static_cast.
Everything works as intended when I call this code from my own test C++ application, but when it's called from Game Maker, range errors raise SIGFPE for some reason, which leads Game Maker to terminate my program with an error message.
I don't need sensible results for out-of-range conversions, but crashing is a no-no. I tried using llround instead of a cast, but it also raises the signal.
I also tried catching the signal myself by using signal(SIGFPE, SIG_IGN); right before the conversion, but it didn't change the behaviour at all. Maybe the ominous comment in the mingw signal.h has something to do with that: "SIGFPE doesn't seem to work?"
I checked the source code of a different dll used in a Game Maker extension, and the binary provided by the author performs simple cast conversions without a problem. When I compile the source myself however, the SIGFPE problem is present again. I am guessing that the author used a different compiler, but I'd prefer to stay with mingw if possible.
So, how do I either perform these conversions safely, or prevent the signal from being generated when I perform them with a simple cast? I'm using mingw-g++ 4.5.0 to compile at the moment.
Here's the function where the problem happens:
template<typename ValueType>
static double writeIntValue(double handle, double value) {
boost::shared_ptr<Writable> writable = handles.find<Writable>(handle);
if(writable) {
// Execution reaches this point
ValueType converted = static_cast<ValueType>(value);
// Execution doesn't reach this point if e.g. ValueType
// is short and value is 40000
writable->write(reinterpret_cast<uint8_t *>(&converted), sizeof(converted));
}
return 0;
}
The good solution is to perform the conversion correctly by ensuring that the source value is within the range of the target type before casting. So my code from the question could be corrected like this:
ValueType converted;
if(value >= std::numeric_limits<ValueType>::max()) {
converted = std::numeric_limits<ValueType>::max();
} else if(value <= std::numeric_limits<ValueType>::min()) {
converted = std::numeric_limits<ValueType>::min();
} else {
converted = static_cast<ValueType>(value);
}
Another option is to use numeric_cast from the Boost libraries, which throws an exception if the source value is out of range, so it has defined behaviour for all conversions.
The documentation of the Boost Numeric Conversion library contains some helpful information about how the standard defined certain conversions.
Thanks to rve for providing the correct suggestion in his answer, but unfortunately his example code is flawed, and I wanted to add some additional pointers that helped me.
Since you are using a DLL, are you sure the DLL is compiled in the same way as the program expects it? Maybe some 32/64 bit mismatch?
Also, SIGFPE can also be raised when there is an under/overflow when converting.
You can enable/disable the signal raised by this overflow by setting the mask using _FPU_SETCW (it's in fpu_control.h) My guess is that Game Maker enables this and your test program not.
I never tried this and I'm not sure mingw also has this but I hope this helps a little.
edit:
Why not making sure an overflow does not happen?
Something like:
if (value > std::numeric_limits<ValueType>::max())
{
value = std::numeric_limits<ValueType>::max();
}
else if (value < std::numeric_limits<ValueType>::min())
{
value = std::numeric_limits<ValueType>::min();
}
ValueType converted = value;
probably it's not related with conversion itself but with trying to access invalid memory (maybe stack corruptions or something like that). can you provide some code snippet?
What's the best way to use NaNs in C++?
I found std::numeric_limits<double>::quiet_NaN() and std::numeric_limits<double>::signaling_NaN(). I'd like to use signaling_NaN to represent an uninitialized variable as follows:
double diameter = std::numeric_limits<double>::signaling_NaN();
This, however, signals (raises an exception) on assignment. I want it to raise an exception on use, not on assignment.
Is there any way to use signaling_NaN without raising an exception on assignment? Is there a good, portable alternative to signaling_NaN that will raise a floating point exception when used?
After looking into this some more, it looks like signaling_NaN is useless as provided. If floating point exceptions are enabled, then calling it counts as processing a signaling NaN, so it immediately raises an exception. If floating point exceptions are disabled, then processing a signaling NaN automatically demotes it to a quiet NaN, so signaling_NaN doesn't work either way.
Menkboy's code works, but trying to use signaling NaNs runs into other problems: there's no portable way to enable or disable floating point exceptions (as alluded to here and here), and if you're relying on exceptions being enabled, third party code may disable them (as described here).
So it seems like Motti's solution is really the best choice.
What signaling NAN means is that when the CPU encounters it a signal is fired, (hence the name). If you want to detect uninitialized variables then raising the warning level on your compiler usually detects all paths that use uninitalized values. Failing that you can use a wrapper class that stores a boolean saying if the value is initialized:
template <class T>
class initialized {
T t;
bool is_initialized;
public:
initialized() : t(T()), is_initialized(false) { }
initialized(const T& tt) : t(tt), is_initialized(true) { }
T& operator=(const T& tt) { t = tt; is_initialized = true; return t; }
operator T&() {
if (!is_initialized)
throw std::exception("uninitialized");
return t;
}
};
You can write a signalling NaN into a variable without triggering an exception with something like this (nb: untested)
void set_snan( double &d )
{
long long *bits = (long long *)&d;
*bits = 0x7ff0000080000001LL;
}
It'll work most places, but no, it's not 100% portable.
Well, looking after the definition of both quiet and signaling NaN, I can't really make out any difference.
You could use the code that is used in those functions yourself, maybe it prevents an exception that way, but seeing no exception in those two functions, I think it might be related to something else.
If you want to directly assign the NaN:
double value = _Nan._Double;
Simple answer:
Do something like this in the header file and use it everywhere else:
#define NegativeNaN log(-1)
If you wish to do some kind of manipulations on them better write some extended wrapper function around exp() like extended_exp() and so on!
Your C++ implementation may have an API for accessing the floating point environment to test for and clear certain floating point exceptions. See my answer to a related question for more information.