Jump to content
  • Advertisement
Sign in to follow this  
Sync Views

Some questions

This topic is 3790 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hopefully these are all pretty basic :) 1)Is there an easy way to turn a number into a hexedecimal string? EDIT:or binary eg 255 goes to "FF" or "1111" 2)When useing direct3d is there a way to draw onto a texture rather than the screen? 3)Is there any real purpose to the "volatile" keyword? I found out that it tells the compiler the varible may be changed in unprictable ways but no where seems to clearly state when a varible should be declared volatile and when not. 4)Is there any reason to declare a varible constant other than to be sure that nothing changes it? 5)There are loads of tutorials about creating a window but how can I change a windows window ive already made? (eg caption, size etc) 6)I noticed that d3d seems to loose all it's textures if the program is minimised. Is there a way to tell if it was minimised so that they can be reloaded? 7)Is ther any purpose now for the "inline" keyword these days or do compilers automaticaly make functions inline if it will improve proformance? [Edited by - Sync Views on February 6, 2008 12:00:14 PM]

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by Sync Views
1)Is there an easy way to turn a number into a hexedecimal string?


#include <iostream>
#include <sstream>

int main()
{
std::stringstream ss;
ss << std::hex << 255;
std::string s;
ss >> s;
std::cout << s;
}



Quote:
Original post by Sync Views
3)Is there any real purpose to the "volatile" keyword? I found out that it tells the compiler the varible may be changed in unprictable ways but no where seems to clearly state when a varible should be declared volatile and when not.

When multiple threads access the same variable.

Quote:
Original post by Sync Views
4)Is there any reason to declare a varible constant other than to be sure that nothing changes it?

Isn't that a great reason by itself? Appart from that, maybe the compiler can optimize better. But that's not the primary goal of using the const keyword.

Quote:
Original post by Sync Views
7)Is ther any purpose now for the "inline" keyword these days

Unlikely.

Share this post


Link to post
Share on other sites
Quote:

When multiple threads access the same variable.


Not quite. The original purpose of volatile was, AFAIK, to represent memory-mapped hardware. Thus the compiler shouldn't cache the value of the variable - the hardware may have changed the value.

For threads, using volatile might sometimes appear to work. But on modern, multi-core (and more importantly from what I understand - multi-cache) processors, volatile is not enough. Use real threading primitives and operations if you want guarantees.

Share this post


Link to post
Share on other sites
2) Use SetRenderTarget() to change render targets.

4) integral const variables initialized at compile time can be used as integral constant expressions, so can be used as array sizes, etc.

5) SetWindowText(), MoveWindow()

6) Functions like Present() will return D3DERR_DEVICELOST if the device has been lost and you need to do things like restore your textures.

7) If for some reason you want to define a function in a header, inline will prevent the linker from complaining about multiple definitions.

Share this post


Link to post
Share on other sites
Quote:
Original post by rip-off
For threads, using volatile might sometimes appear to work. But on modern, multi-core (and more importantly from what I understand - multi-cache) processors, volatile is not enough. Use real threading primitives and operations if you want guarantees.

Keep in mind that if you use threading primitives and such, you may still need volatile. (You may not if you use functions that take volatile pointer arguments, but it'd still be necessary, for example, if you want to synchronize access to a shared global integer value with mutexes.)

Share this post


Link to post
Share on other sites
Quote:
Original post by rip-off

Not quite. The original purpose of volatile was, AFAIK, to represent memory-mapped hardware. Thus the compiler shouldn't cache the value of the variable - the hardware may have changed the value.


More importantly, compiler isn't allowed to re-arrange the instructions that interact with variable.

Assumptions that hold for single-threaded code don't for concurrent. Looking at assembly of optimizing compiler is a good way to understand just how badly the order of instructions is changed in an attempt to optimize pipelining.

Marking a variable volatile will generally result in worst-case performance for all code that accesses that variable, since it almost completely ignores cache and pipeline.

Quote:
For threads, using volatile might sometimes appear to work. But on modern, multi-core (and more importantly from what I understand - multi-cache) processors, volatile is not enough. Use real threading primitives and operations if you want guarantees.


Volatile is used merely as a limited atomic access guarantee. It doesn't, in any way, deal with concurrent access issues.

Simplest way to imagine it is that if two cores write to an int, by the time one
core writes the first byte out of 3, the other one reads the value, resulting in a nonsensical value.

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
if two cores write to an int, by the time one core writes the first byte out of 3

Isn't writing an int to memory atomic, simply by the definition of an int (integral value)?

Share this post


Link to post
Share on other sites
Quote:
Original post by DevFred
Isn't writing an int to memory atomic, simply by the definition of an int (integral value)?

Not really. Integral value means member of the set of integers, not that reads and writes are atomic. It's entirely possible to have a non-atomic integer write. Example, in MSVC:

#pragma pack(1)
struct Foo {
short a;
int b;
};

Here, b lacks 4 byte alignment so could actually span multiple cache lines. Writing to multiple cache lines is pretty much as non-atomic as you can get.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!