litwindow-users

[litwindow-users] vs 2005 compilation

[yrs90 <yr...@ya...>]

Ok, I've rebuild wxWidgets-2.5.5, LitWindow and my project using the VS 2005
Express Beta 2 compiler.  The compiler generates floods of warnings, most
having to do with either macro redefinitions in conflicting header files or
deprecated functions, but the libraries all seem to build successfully.  By
the way, macro redefinitions occur between the SDK specstrings.h and the VS
8 sal.h.  The two are supposed to play together so I've assumed that its not
a problem.

I spent about 8 painstaking and painful hours resolving linking issues. The
most troublesome problems were related to having some mixed library versions
that I couldn't locate.

Now it compiles and links, but upon execution I get a debug assertion
stating "vector iterators incompatible".  The assertion is from the
following portion of #include <vector>

#if _HAS_ITERATOR_DEBUGGING
       void _Compat(const _Myt& _Right) const
               {       // test for compatible iterator pair
               if (this->_Mycont == 0 || this->_Mycont != _Right._Mycont)
                       {
                       _DEBUG_ERROR("vector iterators incompatible");
                       _SCL_SECURE_INVALID_ARGUMENT;
                       }
               }
#endif /* _HAS_ITERATOR_DEBUGGING */

If I ignore the first assertion, I get an assertion expression of ("SCL
Secure Invalid Argument", 0).

Any idea how to resolve this assertion?  Is this a library problem too?


---
[This E-mail scanned for viruses by Declude Virus]

RE: [litwindow-users] vs 2005 compilation

[yrs90 <yr...@ya...>]

> Now it compiles and links, but upon execution I get a debug assertion
> stating "vector iterators incompatible".  
> Any idea how to resolve this assertion?  Is this a library problem too?

Okay I can localize the assertion to the rule that assigns the vector to the
listctrl when handled by Start().  With the rule commented out or with
Start() commented out (not so surprising really), I can start the program
without any assertions.

My rule is of the form
	RULE("xrcListCtrl", make_expr<accessor>("m_myVector"))

where m_myVector, although embedded in a class, is of the form

class MyListItems;
vector<MyListItems> m_myVector;
IMPLEMENT_ADAPTER_CONTAINER(vector<MyListItems>)

The assertion occurs in RapidUI::Start at line reading
	(*i)(*this);

The iterator used is defined
	RulesList::const_iterator i;

Time for a break.

Regards,
Joel


---
[This E-mail scanned for viruses by Declude Virus]

[litwindow-users] Re: vs 2005 compilation

[Hajo K. <mai...@ha...>]

yrs90 wrote:
> Ok, I've rebuild wxWidgets-2.5.5, LitWindow and my project using the VS 2005
> Express Beta 2 compiler.  The compiler generates floods of warnings, most
> having to do with either macro redefinitions in conflicting header files or
> deprecated functions, but the libraries all seem to build successfully.  By
> the way, macro redefinitions occur between the SDK specstrings.h and the VS
> 8 sal.h.  The two are supposed to play together so I've assumed that its not
> a problem.
> 
> I spent about 8 painstaking and painful hours resolving linking issues. The
> most troublesome problems were related to having some mixed library versions
> that I couldn't locate.

Oh dear. I'd break it off then.

> Any idea how to resolve this assertion?  Is this a library problem too?

Looks very much like it, I'd say.

I have got a question. You are using the free 2003 tools. They come 
without the debugging libraries you say. But you could still generate 
debugging information with the compiler, couldn't you? Then I would 
suggest you continue to use the free tools, add the debug symbols 
compiler switch and compile and link the whole thing. You don't need to 
link with the debugging libraries to be able to debug. All you need is 
debug symbols.

Then you can use the VC 2005 IDE debugger to debug the code you've 
generated with the free tools.

Hajo

RE: [litwindow-users] Re: vs 2005 compilation

[yrs90 <yr...@ya...>]

> > Any idea how to resolve this assertion?  Is this a library problem too?
> Looks very much like it, I'd say.

I'm thinking that this might not be a library problem.  I've been tracing
through the function and I watch it iterate through the name space looking
for "Items".  

I conjectured that this might be related to something I mishandled in
wxCtrlListAdapter, so I've now tried it with a wxListBox and the same thing
happens.  The following uses wxListBox. (wxListCtrl followed the same path.)

The problem occurs after the symbol is successfully located in
lwListAdapterBase.  It has started to unwind.  The failure occurs as at
rc==currentAggregate.end() at line 465 of dataadapterimp.cpp.  During the
operator== function, the iterator check occurs and, in this case, fails.

The iterator rc was just returned from find_identifier via "return
nested_rc". It is at the wxListBoxAdapter level comparing to the iterator
returned on lwListAdapterBase.

rc.it._Mycont == 0x877804 while the currentAggregate.end().it._Mycont ==
0x877b04.  Since the two values of _Mycont are not equal the assertion
occurs.

The usual course is that it still turns out to be something I've done. :)
Still, any thoughts?


> I have got a question. You are using the free 2003 tools. They come 
> without the debugging libraries you say. But you could still generate 
> debugging information with the compiler, couldn't you? Then I would 
> suggest you continue to use the free tools, add the debug symbols 
> compiler switch and compile and link the whole thing. You don't need to 
> link with the debugging libraries to be able to debug. All you need is 
> debug symbols.

This is a great idea!  The only thing is that I don't know how to extract
the symbols from the obj files without the linkers help.

Regards,
Joel


---
[This E-mail scanned for viruses by Declude Virus]

[litwindow-users] Re: vs 2005 compilation

[Hajo K. <mai...@ha...>]

yrs90 wrote:

> I'm thinking that this might not be a library problem.  I've been tracing
> through the function and I watch it iterate through the name space looking
> for "Items".  

Hm, silly question. Did you rebuild the litwindow library with the new 
tools?

> 
> This is a great idea!  The only thing is that I don't know how to extract
> the symbols from the obj files without the linkers help.

You don't have to. Just pass the relevant 'generate debug symbols' 
switch to the compiler and also pass the 'create program database' 
switch to the linker.

All you need is the program database.

Regards

Hajo

RE: [litwindow-users] Re: vs 2005 compilation

[yrs90 <yr...@ya...>]

> Did you rebuild the litwindow library with the new tools?

I did indeed.

I'm starting to understand the code a little better. The code does what it's
intended to do. I think the assertion was introduced to catch people who
compare different objects by accident.  In this case, the fact that they are
different objects is what we want to know.  If the find had failed the
original iterator would have been returned.  I think one possible solution
(assuming support for VS8 in debug mode is important) is to introduce a
first order check that asks if they iterators point to different objects.  I
am trying to decipher how to query the iterator type now.

> You don't have to. Just pass the relevant 'generate debug symbols' 
> switch to the compiler and also pass the 'create program database' 
> switch to the linker.

This is good to know. Thanks.

Regards,
Joel



---
[This E-mail scanned for viruses by Declude Virus]

[litwindow-users] Re: vs 2005 compilation

[Hajo K. <mai...@ha...>]

Hi,

> 
> The problem occurs after the symbol is successfully located in
> lwListAdapterBase.  It has started to unwind.  The failure occurs as at
> rc==currentAggregate.end() at line 465 of dataadapterimp.cpp.  During the
> operator== function, the iterator check occurs and, in this case, fails.

now I get it. It is actually a valid assert and has nothing to do with 
your code.

The assert fails if you are trying to compare iterators that belong to 
different containers.

Indeed the iterators here belong to different containers, but I did that 
on purpose. Hmm, seems that this is non standard. That is a bother. Why 
one shouldn't be allowed to do that is beyond me.

What I am doing here is the following: I am searching for the symbol you 
passed in. find_identifier returns an iterator to that symbol. But it 
searches for it in many different containers so the iterator returned 
might belong to a different container. Every adapter has its own base 
container, but every member and every inherited structure inside an 
adapter has a container of its own.

I will think about that and come up with a solution.

I am glad that you've found out how to continue, though.

BTW, can you please compile and run the unittests? They are meant to 
catch errors such as these.

Regards

Hajo