Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Which C++ cast to use for T * to T *__restrict?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 Prune   Members   -  Reputation: 223

Like
1Likes
Like

Posted 03 January 2014 - 10:49 PM

For example, I have a char * and I want to cast it to a char *__restrict.

Visual C++ 2012 seems to be OK with either static_cast or const_cast, and doesn't require a reinterpret_cast, but which one is really correct to use?


"But who prays for Satan? Who, in eighteen centuries, has had the common humanity to pray for the one sinner that needed it most?" --Mark Twain

~~~~~~~~~~~~~~~Looking for a high-performance, easy to use, and lightweight math library? http://www.cmldev.net/ (note: I'm not associated with that project; just a user)

Sponsor:

#2 Matias Goldberg   Crossbones+   -  Reputation: 3713

Like
4Likes
Like

Posted 04 January 2014 - 12:03 AM

__restrict is a non-standard extension specific for MSVC. So, anything that works will do; when casting act as if the __restrict wouldn't be there, unless the compiler complains (i.e. don't use reinterpret_cast when you could use static_cast, and try to avoid const_cast and C casts).

 

If you're thinking into porting to other compilers, look at other compiler's requirements (i.e. on gcc, it is __restrict__)


Edited by Matias Goldberg, 04 January 2014 - 12:04 AM.


#3 Hodgman   Moderators   -  Reputation: 31920

Like
5Likes
Like

Posted 04 January 2014 - 12:27 AM

As above, __restrict isn't a C++ keyword; it's a MSVC++ keyword wink.png so there's no right answer to this question.

 

I'd probably just use a C-style cast, because it's sure to work.

As a complete guess though, I would think that const_cast may be correct, because (I would guess that) restrict would be a cv-qualifier (i.e. you use const_cast to change volatile as well as changing const; so if restrict was in the same group as const/volatile, then it would make sense to use const_cast).



#4 samoth   Crossbones+   -  Reputation: 5037

Like
6Likes
Like

Posted 04 January 2014 - 09:36 AM

Do you need a cast at all? I'm pretty sure the compiler will implicitly cast T* to T* restrict, such as when a function takes a restrict pointer. I've never used a cast for any such thing and never gotten as much as a warning.

 

On the other hand, casting from a restrict pointer to a non-restrict pointer is something you most probably don't want to do ever, so again, no cast needed.

 

Restrict pointers are a promise that your pointers do not alias anything else in the same scope, so the compiler can optimize more aggressively and leave out loads/stores that it would otherwise have to do in order to ensure correctness. Casting away restrict means first making a promise and then finding a "legal" way to break the promise anyway. In my opinion, that is just asking for trouble. Never lie to the compiler and never try to trick it. I'd rather not use anything like restrict in the first place in such a case.



#5 King Mir   Members   -  Reputation: 2050

Like
3Likes
Like

Posted 04 January 2014 - 04:35 PM

On the other hand, casting from a restrict pointer to a non-restrict pointer is something you most probably don't want to do ever, so again, no cast needed.
 
Restrict pointers are a promise that your pointers do not alias anything else in the same scope, so the compiler can optimize more aggressively and leave out loads/stores that it would otherwise have to do in order to ensure correctness. Casting away restrict means first making a promise and then finding a "legal" way to break the promise anyway. In my opinion, that is just asking for trouble. Never lie to the compiler and never try to trick it. I'd rather not use anything like restrict in the first place in such a case.

Casting away restrict does not violate the semantics of restrict. It doesn't make the pointer alias with something. What is does is it removes information passed to the compiler. It may be necessary to implicitly remove __restrict when calling a function with that pointer that does not have a restrict version. And when a __restrict version exists, casting from restrict would de-optimize the code, which may be useful for debugging. In principle, it may also deoptimize any non-call code using the cast pointer within the function, but function analysis is likely to see though such a cast, and still treat the pointer as __restrict.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS