Oh, yes. Why not?Quote:
Make new return NULL on error instead of throwing an exception?
I defined MAX_PATH 260 at the beginning of the code as it is in <windef.h>.
Thanks for searchings dwks. I am reading them.
Printable View
Oh, yes. Why not?Quote:
Make new return NULL on error instead of throwing an exception?
I defined MAX_PATH 260 at the beginning of the code as it is in <windef.h>.
Thanks for searchings dwks. I am reading them.
That's probably a bad idea, in case the value ever changes (not that it will!). I'd go (if you still want to use it):Quote:
I defined MAX_PATH 260 at the beginning of the code as it is in <windef.h>.
After you include windef.h, of course.Code:#ifndef MAX_PATH
#define MAX_PATH 260
#endif
So we should always use C++ casting.
[EDIT]
Including windef.h means losing portability. So what can be done?Code:#ifndef MAX_PATH
#define MAX_PATH 260
#endif
Couple of notes:
I can't see how managing the memory allocations yourself could be easier than letting the library do it. With a vector, for example, you wouldn't need to count the items in the file before loading them.Code://It doesn't use vector maybe for simplfication (?)
Why do you feel it is necessary to make this a member of the class? It is only used in one function.Code:ifstream *fileOfNumbers;
This might still crash if the file was empty.Code:int Numbers::Ave()
{
return(Sum()/numCount);
}
In C++, yes. In C, of course, there's only one option. :)Quote:
So we should always use C++ casting.
This might crash as well.
Any code that assumes at least one number exists might crash.Code:int Numbers::Mid()
{
sort(nums, nums + numCount);
return (nums[numCount/2]);
}
I will correct this problem using isOK.Quote:
Any code that assumes at least one number exists might crash.
For limiting its access.Quote:
Why do you feel it is necessary to make this a member of the class? It is only used in one function.
I do this to practice memory allocation.Quote:
I can't see how managing the memory allocations yourself could be easier than letting the library do it.
Aren't things such as "stdafx.h" and _tmain Microsoft compiler specific anyway?Quote:
Including windef.h means losing portability. So what can be done?
If the constructor fails, you'll have a completely unusable object - without a means to try loading another file. So you might just as well let the exception leave the constructor: user gets a valid object or nothing.Quote:
Quote:
Any code that assumes at least one number exists might crash.
I will correct this problem using isOK.
But I'm not that fond of using exceptions...
How? If it is used locally in one function, its access would be even more limited? Your class is a wrapper around a numeric array, the ifstream is just a tool to get that array loaded from file.Quote:
Quote:
Why do you feel it is necessary to make this a member of the class? It is only used in one function.
For limiting its access.
That's a valid reason. But may-be update the comment then :)Quote:
Quote:
I can't see how managing the memory allocations yourself could be easier than letting the library do it.
I do this to practice memory allocation.
I don't know why I thought I can't throw exceptions from constructor (or it is a bad idea)!!! So it is possible, isn't it?Quote:
So you might just as well let the exception leave the constructor: user gets a valid object or nothing.
Aha, now I understant you. I thought you say it should be global. You are right if the class design remains the same.Quote:
How? If it is used locally in one function, its access would be even more limited? Your class is a wrapper around a numeric array, the ifstream is just a tool to get that array loaded from file.