Hottest Forum Q&A on CodeGuru
Introduction:
Lots of hot topics are covered in the Discussion Forums on CodeGuru. If you missed the forums this week, you missed some interesting ways to solve a problem. Some of the hot topics this week include:
- Should I throw an exception in a constructor?
- How do I refresh the treecontrol when expanding subitems?
- Why do I get an access violation?
- Why do I get a warning while assigning a value from std::vector<unsigned int> to an unsigned int?
- How large a value can a STL map hold?
|
Thread:avi123 is calling a function in his constructor. The function does some processing and returns a result. But here, he needs to check whether the function fails or succeeded. So, what is, in your view, the best way to achieve this?
I have a constructor that calls a function which returns a value if the function fails what can I do to stop constructing the object? How do I notify the client who created the object that there was a failure? Client side:
CMyClass myClass;
and myClass constructor do that:
MyClass::MyClass
(
Init1();
Init2();
}
What if Init1() or Init2() fails?
One solution is to throw an exception in the constructor. But, it is not a elegant solution. You should always take care if you are throwing an exception in a constructor. How many classes do you know that throw an exception in the constructor? The better solution is to create a function such as Initialize()m which can be called prior to using the object. This function can return BOOL or bool to indicate success/failure, or a DWORD error code, or throw an exception, and so forth. If Initialize fails, further operations on the object should not be performed. This can look something like this:
CYourClass Yadda;
if( Yadda.Initialize() )
{
UseYadda( Yadda );
}
else
{
// Handle failure to initialize...
}
or
CYourClass Yadda;
try
{
Yadda.Initialize();
UseYadda( Yadda );
}
catch( CWhateverExceptionYouWant& rTheEx )
{
// Handle exception...
}
|
Vince Martinez does have some problems with his TreeControl. This problem has been discovered by several users.
I am having problems with my CTreeCtrl that is displayed in a FormView. I am using the +/- buttons to allow expansion/colapse of the tree branches. It is used with a tab control and other controls, for reference. *grin* The problem is that when I have several branches expanded to the point where I get a vertical scroll bar and a child node is selected, the control does not properly refresh when the +/- button is clicked to collapse the branch and the scrollbars go away (the area below the newly selected parent node is grey). If I have a parent node selected when it is collapsed, the display updates correctly. Also, if I have the tooltips enabled for the control and I click and hold on the scroll bar to drag it up and down, I get grey bars on the control if the cursor crossed into the Tree client area and a tool tip temporarily displays. I have tried to turn the control's redraw off during expansion/collapse. That clears up the grey display problem, but the scrollbar area and frame do not refresh then. I tinkered with the parent window's refresh as well, and got even closer...but now I am stumped. Close but no cigar. *grin* Anyone have any ideas or suggestions? (Note: my FormView is a child window in a CSplitterWnd, in case that may be a factor.)
If you take a look at the tab order (command Layout > Tab Order (or press Ctrl+D)), you will see that the tree control comes before other controls. The problem is solved when you number the controls so that the tree control comes later in the list than the Tab control. It will be drawn last and that might clear up the problem.
|
wind0965 is working with an application in VB and a DLL in VC. He has created a DLL in VC that is called from the VB application. The VB application compiles without any problems. But while running the app, it crashes!
I have a DLL to be used under Visual Basic, and the DLL was done in C(using Visual C++). When I compile the project in Visual Basic, it works. But after I made a .EXE file in VB and ran it. The system said: "Unhandled exception in *.exe(*.Dll): 0xC0000005: Access Violation. " And it was the same when I debugged it in the Visual C++(6.0) environment. Do you have any idea?
The only solution could be to run the app in the debugger mode and to trace what causes the crash.
wind0965 did this and has found the problem. The VB calls one function in a DLL, and the parameters are defined as integers in the DLL. Of course, I defined these parameters as Integer in VB, too. But this is the case. When I change them into Long(Integer), the error never occurs. In VC++, an int is 4 bytes. In VB6, an int is 2 bytes. Regardless of the values held by a variable of type int, those are the memory requirements of that type. VB interpreted the int as 2 bytes, and VC++ was "reading" 4 bytes to get the value. Change your VB function declaration to indicate that the param is a Long (4 bytes), or change your VC++ function to take a short (2 bytes).
|
makeshiftwings want to assign a value from std::vector<unsigned int> to an unsigned int, but unfortunately he gets a warning that some data can be lost during the conversion. But why does he get this warning?
Hi... I'm far from a master of STL, but I seem to be having some odd behavior with a vector<unsigned int> that I'm using. Basically, if I do this:
std::vector<unsigned int> vec; unsigned int b = *(vec.begin());
I get a warning at the assignment of b of type: warning C4267: 'initializing' : conversion from 'size_t' to 'unsigned int', possible loss of data I'm using VS.NET 2003 with its regular STL (not STLPort). I guess when creating a vector of unsigned int's, it's somehow getting confused and thinking that it's a vector of size_t's ? Is this normal behavior? Should I be concerned ? Will this warning disappear if I start using STLPort (I'd rather not) ? And if it's unfixable, is a size_t the same size as an unsigned int on Win32, Mac, and Linux? I'm trying to make sure my app stays cross-platform.
The code works without any warning in VC6 and also in VC++ .NET V7.1. The problem could be in one of the included headers—maybe in windows.h. It could be that the windows.h screwed up one of the definitions that was used in the vector and map classes. Either move the windows.h header first before all the headers, or get rid of it.
#include <vector>
#include <map>
#include <windows.h>
int main()
{
std::multimap<size_t, int> somemap;
std::vector<unsigned int> vec;
unsigned int b = vec.front();
return 0;
}
But, unfortunaly, the warning is still displayed and cannot be resolved. It seems to be a bug in the VS.NET version.
|
raul_figous asked a very interesting question. He needs to know how large a value an STL map can hold.
Can anyone give an estimate figure how much value STL map can hold. The max_size that it occupies in the memory? Can anyone give a sample example for this where maximum value is stored and tested for benchmark? Also what is the complexity for inserting, deleting, and searching when using maps?
In the first instance, a map allocates its contents on the stack. But, if you allocate your elements on the heap, the bulk will be on the heap and only limited by your machine. An example would be SQL Server: Every index underneath is stored in a map. Maps, like all STL structures, are very convenient in their use.
Because this topic goes very deeply, I suggest you to take a look at the whole thread.
This article was originally published on November 17, 2003
