1

I'm trying to cast qint16 (int16) to double with mydouble = (double) myInt16; and I get 

error: invalid cast from type 'qint16* {aka short int*}' to type 'double'

How can I convert a int16 to double ?

Ariyan
  • 14,760
  • 31
  • 112
  • 175

2 Answers2

2

Based on the code you've shown, you don't have an int. You have a pointer to an int. Dereference it, as follows:

// Assume src points to a short int
double mydbl = *src;

The conversion from integer to double will be automatic, but you have to dereference the pointer.

Logicrat
  • 4,438
  • 16
  • 22
  • I'd do something more like: double mydbl = 0.0; if (src){ mydbl = static_cast(*src); } – George Mar 22 '16 at 17:40
  • @George That's a lot of typing to achieve the same goal. I suppose it's a matter of style, but I think clarity is served by going with the automatic conversion. ;) – Logicrat Mar 22 '16 at 17:43
  • @George, apparently, you are being paid by the symbol. There is no other reason to use the code you've provided. – SergeyA Mar 22 '16 at 17:43
  • 1
    Logicrat, it is not the matter of the style. @George 's code is a terrible syntax bloat, with cargo-cult of checking null pointer and missing error handling. Never do it like this. – SergeyA Mar 22 '16 at 17:44
  • @SergeyA I never would. – Logicrat Mar 22 '16 at 17:48
  • Checking for null pointers is bad now? Apparently you've never worked on a system that doesn't support exceptions ... I'll admit that the static cast is a bit much. – George Mar 22 '16 at 17:49
  • @George, yes, checking for null pointers is bad and cargocult with a few exceptions. Those notably are functions like `printf()` and cases when having null pointer is a valid scenario - i.e. contract allows for null pointers specifically. In all other cases, null pointer is just one (and rarely achievable in optimized C++ code) example of bad pointer, and it makes zero sense to code around it. – SergeyA Mar 22 '16 at 17:51
  • @SergeyA I try to avoid using raw pointers altogether unless I have to. And who knows whether or not his scenario is one where having a null pointer is a valid scenario? He didn't say if it was or not. Not everybody has access to boost::optional or the time to roll their own equivalent, either. Besides, a pointer that can never be null should be a reference instead. – George Mar 22 '16 at 18:00
  • @SergeyA, I don't need to. I can use std::shared_ptr instead. Why would you want to store raw pointers in a container? And before you say "I never said anything about storing raw pointers in a container", I never said anything about trying to store references in one, either. – George Mar 22 '16 at 18:07
  • @George, no, this is exactly what I said. I am storing raw pointers in the container - provided they are non-owning pointers. It is a much better practice than storing shared_ptrs in the same containers. – SergeyA Mar 22 '16 at 18:13
  • @SergeyA, much better if you like memory leaks. A better alternative would be the boost pointer container library, but again, not everybody has access to boost. – George Mar 22 '16 at 18:15
  • @George, why would I have a memory leak if the pointers are non-owning? Looks like you need some refresher: http://stackoverflow.com/questions/33149996/is-using-pointers-in-c-always-bad – SergeyA Mar 22 '16 at 18:16
  • @SergeyA, If they're non-owning, fine, *if* you can guarantee that the non-owning pointers die before the owning ones do. Otherwise, you're in trouble again. It seems to me like a weak_ptr would be a better choice than a raw pointer. – George Mar 22 '16 at 18:25
  • @George, you are saying 'guarantee' as if it's black magic. But there is none. `class MyData { std::vector > storage; std::map by_name; std::map by_id; public: add_data(const Payload& ); };`. There is nothing to guarantee, and `weak_ptr` is totally unapplicable here. I could use `shared_ptr`, but why would I pay the **heavy** penalty (every copy of shared_ptr is a memory barrier!). Raw pointers all the way. – SergeyA Mar 22 '16 at 18:30
  • @SergeyA, the issue with what you're talking about is, if you forget to remove an entry from by_name when it is removed from storage, then you have a dangling raw pointer. If you can guarantee that everywhere you remove an entry from storage, you also remove it from by_name, then you're good... until someone else adds code to remove an item from storage elsewhere and *they* forget to remove it from by_name. Then you're once again left with a dangling pointer and a likely crash. Me, I don't like crashes, but if that's the type of thing you enjoy, go nuts. – George Mar 22 '16 at 18:44
  • @George - Re: "Why would you want to store raw pointers in a container?" Because I've designed my application to manage lifetimes so that I don't need the code bloat that comes from "smart" pointers. For example, a container that holds pointers to objects with static lifetime should hold raw pointers. – Pete Becker Mar 22 '16 at 18:48
  • @Pete Becker sure, if you design your application to do that, that's fine. It isn't clear from SergeyA's example whether that's the case or not. Another way that might work, depending on your application, is to use the boost pointer containers. They're low-overhead, too. – George Mar 22 '16 at 18:53
2

From the error, myInt16 is a pointer to short int. So simply use:

double mydouble = *myInt16;

And the short int will automatically be promoted to double.

Paul Evans
  • 27,315
  • 3
  • 37
  • 54