User forums > Help

using code profiler in C - crash! (svn 7071)

<< < (4/5) > >>

oBFusCATed:
Pecan:
wxTreeItemId() and wxTreeItemId(0) should be equivalent, as far as I can see in the wxTreeItemId's code.
And the docs/header file say that the user is not allowed to call the latter.
The user may call only IsOk and probably to default construct an object.

See here for the source of wxTreeItemId: http://svn.wxwidgets.org/viewvc/wx/wxWidgets/branches/WX_2_8_BRANCH/include/wx/treebase.h?view=markup

Also look at the first post for the errors.
As you can see, the compiler sees two constructors:
wxTreeItemId(void*) and wxTreeItemId(long), this is ambiguous on 64bit machines, because sizeof(void*) == sizeof(long) and sizeof(int) != sizeof(long).
So id = 0, requires a cast and the compiler have two equally valid options.

Stahta01:
Why not? The binary wxGTK package for CentoOS 5.5  is compiled with this option and with my patch C::B works without problems.

stahta01:

--- Code: ---#if WXWIN_COMPATIBILITY_2_4
74 // deprecated: only for compatibility, don't work on 64 bit archs
75 wxTreeItemId(long item) { m_pItem = wxUIntToPtr(item); }
76 operator long() const { return (long)wxPtrToUInt(m_pItem); }
77 #else // !WXWIN_COMPATIBILITY_2_4

--- End code ---

I can read and I am guessing the wx devs know what is right about their code.

Tim S.

oBFusCATed:
OK, And have you seen some lines above it that the only methods allowed are the default constructor
(it is not written as allowed, but I guess it is, I will write a bug report for it thought:) ) and the IsOk?
And wxTreeItemId(void *) is not one of them, so the C::B's usage is wrong (I'll contact wx guys to
hear what they think about it).

Can someone test my patch and verify that CodeSnippets is working with it. I don't use it and can't do so, unfortunately.

Jenna:

--- Quote from: oBFusCATed on March 30, 2011, 04:06:02 pm ---OK, And have you seen some lines above it that the only methods allowed are the default constructor
(it is not written as allowed, but I guess it is, I will write a bug report for it thought:) ) and the IsOk?
And wxTreeItemId(void *) is not one of them, so the C::B's usage is wrong (I'll contact wx guys to
hear what they think about it).

Can someone test my patch and verify that CodeSnippets is working with it. I don't use it and can't do so, unfortunately.

--- End quote ---
I don't use it also.

About the constructor:

--- Quote from: http://docs.wxwidgets.org/2.8/wx_wxtreeitemid.html#wxtreeitemidconstr ---wxTreeItemId::wxTreeItemId

wxTreeItemId()

Default constructor. wxTreemItemIds are not meant to be constructed explicitly by the user; they are returned by the wxTreeCtrl functions instead.
--- End quote ---

oBFusCATed:
Jens you are correct, here is the explanation from the #wxwidgets in irc.freenode.com


--- Quote ---(2011-03-30 22:25:13) obfuscated: hi, can I do something like "class Something { wxTreeItemId storeForLater; }; " or this is not allowed?
(2011-03-30 22:26:46) DavidGH: obfuscated: You can't reliably do that, as a wxTreeItemId isn't guaranteed to live for long
(2011-03-30 22:27:13) DavidGH: As soon as a tree is recreated, or (I think) an item inserted, the old ids become invalid
(2011-03-30 22:27:36) obfuscated: so, how do you store something like a pointer to an item?
(2011-03-30 22:28:05) DavidGH: You don't. You search the tree each time you want it
(2011-03-30 22:28:52) DavidGH: Of course it depends on your situation: if you are certain that the tree won't be altered in the course of your function...

--- End quote ---

Navigation

[0] Message Index

[#] Next page

[*] Previous page