|
Yes, it will give you a lot of experience. I have worked on similar products, and file system drivers, such as those used by Faronics to control applicaiton execution and so on are some of the most complex to write.
==============================
Nothing to say.
|
|
|
|
|
I am currently writing a game in C++ using OpenGL and I wonder which is the best way to deal with errors, once they occur (especially in games).
Note: I am currently using possibility 2, but I'm not really happy with it.
1. Exceptions - At first glance they seem to be the perfect for all kinds of errors, but I found out that exceptions can produce heck of a lot of overhead and extra time cost and IMO they're making the code ugly.
2. Return values - It's said that checking success using return values is deprecated since C++'s built-in exception handling. I can't share that opinion, but retrieving a return value and checking it doesn't seem to be an 'elegant' way of doing this and isn't beautiful as well (due to thousands of if and/or switch statements.
3. Return value + global error indicator - This one's really deprecated, even though I somehow liked the errno thingy in C 
So, what do you use/what would you use and what would you recommend for my needs?
Thanks in advance.
PS: Do I have some kind of natural aversion to exceptions or are they really not the greatest invention since sliced bread?
|
|
|
|
|
I think in error handling, performance should not be of concern. So, the "I'm writing a game, everything must be fast!" argument doesn't work here. Errors should always be the exception! 
Exceptions really help you to write smaller code. When using return values, you have to check them every time. If you forget to do so, you might miss an error. So they are really prone to bugs!
Exceptions on the other hand can't be simply ignored, and I think that's good.
|
|
|
|
|
TomasRiker2 wrote: Errors should always be the exception!
Well said! Can I quote you on this? 
|
|
|
|
|
forkbomber wrote: ...but I found out that exceptions can produce heck of a lot of overhead and extra time cost...
See here.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
that sir is an *excellent* link to a great detail of information.
Charlie Gilley
<italic>You're going to tell me what I want to know, or I'm going to beat you to death in your own house.
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Joe's articles usually are.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Use exceptions for errors you can't recover from e.g:
- Wrong OpenGL version, throw an exception
- No memory - runtime throws an exception for you
- Can't find a critical game resource, a fall back texture, shader or something else that really must be there
- Some muppet's deleted a delay loaded DLL
- Steam doesn't initialise and you're using it for copy protection
- You can't open any file to save the game - throw an exception
Use return values for things you can recover from, e.g:
- Network connection flakey - you don't want your game to crash 'cause your cheap hosting server in Borneo is offline due to Orang-utan attack
- Can't find a game resource that you have a fallback for
- Steam can't share a file, back off and try again
- You can't open a save game file, back off and try again with a different name
If you're code looks ugly you're not using exceptions for critical errors and you've got exception handlers all over the place.
Ideally for yummy, perfect code you should only have exception handlers:
- At the top level of your code - around main, WinMain or whatever for your platform
- Around thread entry/exit functions
- Around window procedures/GUI callbacks
So basically:
- Exceptions are for critical errors
- Exception handlers only appear when your code is about to disapear UP the call stack into the OS, otherwise madness and the end of western civilisation will result.
Exceptions being really expensive is a myth. See one of the previous posts for details, or hey, measure it yourself.
|
|
|
|
|
Hey there and thanks to everybody for clearing things up.
I'm going to use exceptions now.
|
|
|
|
|
Without directly referencing your enumeration, these are the things you should consider:
1. You can't avoid exceptions completely as some DLLs may throw them, so you at least need to be able to catch them
2. Exceptions provide a built-in mechanism to pass messages and an error identifier, and you can easily extend exception objects to hold additional data.
3. Exceptions will pass control to the level of the next higher try block in the call stack, without having to forward a return values up through several function calls.
4. You can't 'forget' to check for an exception like you can forget to check an error return: provided you catch all exceptions in your main function, you can at the very least issue a meaningful error message before having to exit the program. In fact, exceptions are the only way to 100% prevent a 'silent death' of your application, and will prevent most cases of 'hanging' (except for those caused by infinite loops, and then only those cases where you didn't think to check on preconditions and throw an exception if not met...)
Note that the last point (being almost always able to catch an error before the app breaks down) may also allow you to recover sufficient status information for saving the game and resuming at that point! I would say that is a pretty strong point from the PoV of the gamer.
|
|
|
|
|
I have a Delphi application which Creates a shared memory uses CreateFileMapping, OpenFileMapping, MapViewOfFile functions.
Now I wanted to share the same memory for my MFC application. I used the OpenFileMapping, MapViewOfFile functions.
I created a structure exactly same in size as the Delphi application and mapped the structure object.
sample code:
HANDLE hMapObject2;
hMapObject2 = OpenFileMapping( FILE_MAP_ALL_ACCESS, FALSE, "PP101U3_SHARED");
if( !hMapObject2 )
{
AfxMessageBox("Failed to open Simpack DataBase");
return( 0 );
}
Simpack = ( struct SIMPACKDB *) MapViewOfFile( hMapObject2, FILE_MAP_ALL_ACCESS, 0, 0, 0 );
if( !Simpack )
{
AfxMessageBox("Failed to create Simpack File Map View");
return(0);
}
Esim->SPV1 = Simpack->SP_Z;I am able to read the values exactly correct for all the member variables in the structure.
But when I try to write value in the shared memory, its not changing. It shows the previous value immediately.
The value of Simpack->SP_Z[15] is 0.5010 as read
from the shared memory which is set by the Delphi application.
When I set or write the value of the same variable to the shared memory using the code:
Simpack->SP_Z[15] = 0.6123;it shows the previous value 0.5010. When I change the same variables value in the Delphi application it changes and shows the changed value here in the MFC application.
Please help me how to write the values in the shared memory. Is there anything wrong in the code?
|
|
|
|
|
It could be an issue of caching ...
Try to declare the structure instance with "volatile" and see if that helps.
|
|
|
|
|
Hi german "volatile" will not work. The memory must be created without cache. Try to find the "no cache"flat. And there is a better way: you can also use a segment like the following to share data:
#pragma data_seg("Share")
BOOL existed = FALSE;
#pragma data_seg()
#pragma comment(linker, "/section:Share,rws")
IMPORTANT: the no cache flag is also needed here.
please refer to MSDN, to find the flag.
|
|
|
|
|
CreateFileMapping
DWORD flProtect,
or SEC_NOCACHE
And
#pragma comment(linker, "/section:Share,rwsk")
both will work.
|
|
|
|
|
hello guys... I am trying to get and set the data in the combo box using GetItemDataPtr and SetItemDataPtr. I am facing problem when I use the function GetItemDataPtr . It return bad pointer. Here is what I do to add string
int iPosition = 0;
CString sName;
sName = "Ali";
for (int nIndex = 0; nIndex < 5; nIndex++)
{
iPosition = m_ComboNames->AddString(sName);
ASSERT (iPosition != CB_ERR);
ComboNames->SetItemDataPtr(iPosition, (void*)sName);
}
and to get the data from the combo box I do as under.
int index = m_Combo->GetCurSel();
CString str;
LPVOID ptr;
if(index != LB_ERR)
{
ptr = m_Combo->GetItemDataPtr(index);
str = (CString)ptr;
MessageBox(str );
}
As stated ealier, it shows very strange characters. How can I cast my ptr properly in order to get the value right? thnx for any input.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
Probably your CString object, to which you store a pointer, doesn't exist any more when you're reading the pointer back. It looks like "sName" is declared locally and will get destroyed once the scope is exited.
Then your pointer points to a region of memory that now contains something else.
You can store a pointer to a CString inside your ComboBox. But you have to create this CString instance with new and not locally on the stack!
And don't forget to delete it later when you don't need it any more.
|
|
|
|
|
you are right this time.
but the problem is simple and basic.
|
|
|
|
|
Is sName a global or member variable?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
DavidCrow wrote: Is sName a global or member variable?
Its a local variable within the function.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
Which means it goes away when the function ends. Make it a global or member variable.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
I fail to understand your code; you have a loop setting 5 ComboBox items to the same value (all pointing to sName). What good will that do? When the ItemData collection gets filled with stuff, I expect (1) this stuff to be persisted in memory, and (2) to be all different so you can use it to discriminate the combobox items.
Furthermore, I don't consider the name of a ComboBox item a good candidate for ItemData, as it is already stored inside the Combobox anyway, and there must be an easy way to get it back, without you keeping it around in some data structures yourself. IMO valid candidates for ItemData are e.g. numeric values (say ints), when the combobox itself displays their textual representation (which may vary due to localisation).
modified 18-May-12 11:39am.
|
|
|
|
|
I have 2 different structures test1 and test2
struct test1
{
float IV [300];
char FAIL [200];
char FD [600];
float NENTH [600];
float NKVAL [30][600];
float NLEVEL [600];
int COUNT;
int CTIME;
};
struct test2
{
float RIV [300];
float RXX [100];
char RFAIL [200];
char RFD [600];
float RTB [50];
float RNENTH [600];
char GCD [200];
float RNKVAL [30][600];
char MTBD [600];
float RNLEVEL [600];
int RCOUNT;
int RCTIME;
};
The 2 structure objects are:
struct test1 *sim1;
struct test2 *sim2;
sim1 = new test1();
sim2 = new test2();
Now I want the sim1->IV to exactly point to sim2->RIV
and sim1->NENTH to exactly point to sim2->RNENTH.
So at any point of time, sim1->IV[i] should be same as sim2->RIV[i] where i is any of the valid index range and similarly for NENTH and RNENTH.
Any one know how to acheive this please provide me the code.
C.B.Mohankumar
|
|
|
|
|
manoharbalu wrote: Now I want the sim1->IV to exactly point to sim2->RIV
so you need to do this:
struct test1
{
float *IV;
...
and when you create a test1 object, you have to set the pointer to a test2's RIV array:
sim1 = new test1();
sim2 = new test2();
sim1->IV = &sim2->RIV[0];
|
|
|
|
|
manoharbalu wrote: Now I want the sim1->IV to exactly point to sim2->RIV
and sim1->NENTH to exactly point to sim2->RNENTH.
If you need a pointer then use a pointer:
struct test1
{
float * IV;
float * NENTH;
};
test1 *sim1;
test2 *sim2;
sim2 = new test2();
sim1 = new test1();
sim1->IV = sim2->RIV;
sim1->NENTH = sim2->RNENTH;
Veni, vidi, vici.
|
|
|
|
|
You have something over 20,000 floats in each of your structures; are you really sure this is what you want?
Programming is work, it isn't finger painting. Luc Pattyn
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
