Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
New code completion remarks/issues
ollydbg:
a bug in rev 5984 (Windows) , if you open the CB project, and try to find the declaration of "set", you will find only three entries.
I just test a nightly build of 20091010, the set class was correctly recognized.
see the screenshot below:
Edit:
To simplify the bug, you can just copy the code in
d:\MinGW\lib\gcc\mingw32\4.4.1\include\c++\bits\stl_set.h
to a console project, delete all the #include directive and #if statement, and the code should like below:
--- Code: ---
_GLIBCXX_BEGIN_NESTED_NAMESPACE(std, _GLIBCXX_STD_D)
/**
* @brief A standard container made up of unique keys, which can be
* retrieved in logarithmic time.
*
* @ingroup associative_containers
*
* Meets the requirements of a <a href="tables.html#65">container</a>, a
* <a href="tables.html#66">reversible container</a>, and an
* <a href="tables.html#69">associative container</a> (using unique keys).
*
* Sets support bidirectional iterators.
*
* @param Key Type of key objects.
* @param Compare Comparison function object type, defaults to less<Key>.
* @param Alloc Allocator type, defaults to allocator<Key>.
*
* The private tree data is declared exactly the same way for set and
* multiset; the distinction is made entirely in how the tree functions are
* called (*_unique versus *_equal, same as the standard).
*/
template<typename _Key, typename _Compare = std::less<_Key>,
typename _Alloc = std::allocator<_Key> >
class set
{
// concept requirements
typedef typename _Alloc::value_type _Alloc_value_type;
__glibcxx_class_requires(_Key, _SGIAssignableConcept)
__glibcxx_class_requires4(_Compare, bool, _Key, _Key,
_BinaryFunctionConcept)
__glibcxx_class_requires2(_Key, _Alloc_value_type, _SameTypeConcept)
public:
// typedefs:
//@{
/// Public typedefs.
typedef _Key key_type;
typedef _Key value_type;
typedef _Compare key_compare;
typedef _Compare value_compare;
typedef _Alloc allocator_type;
//@}
private:
typedef typename _Alloc::template rebind<_Key>::other _Key_alloc_type;
typedef _Rb_tree<key_type, value_type, _Identity<value_type>,
key_compare, _Key_alloc_type> _Rep_type;
_Rep_type _M_t; // Red-black tree representing set.
public:
//@{
/// Iterator-related typedefs.
typedef typename _Key_alloc_type::pointer pointer;
typedef typename _Key_alloc_type::const_pointer const_pointer;
typedef typename _Key_alloc_type::reference reference;
typedef typename _Key_alloc_type::const_reference const_reference;
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// DR 103. set::iterator is required to be modifiable,
// but this allows modification of keys.
typedef typename _Rep_type::const_iterator iterator;
typedef typename _Rep_type::const_iterator const_iterator;
typedef typename _Rep_type::const_reverse_iterator reverse_iterator;
typedef typename _Rep_type::const_reverse_iterator const_reverse_iterator;
typedef typename _Rep_type::size_type size_type;
typedef typename _Rep_type::difference_type difference_type;
//@}
// allocation/deallocation
/**
* @brief Default constructor creates no elements.
*/
set()
: _M_t() { }
/**
* @brief Creates a %set with no elements.
* @param comp Comparator to use.
* @param a An allocator object.
*/
explicit
set(const _Compare& __comp,
const allocator_type& __a = allocator_type())
: _M_t(__comp, __a) { }
......
......
--- End code ---
and see the parser works ok or not.
[attachment deleted by admin]
ollydbg:
A further test give the bad result, see the screen shot below:
The parser result is totally wrong.
I personally suspect this bug is introduced by the patch of reading the "template" argument of "visualfc", I'm still examining. Enable PARSERTHREAD_DEBUG_OUTPUT and see the output.
ollydbg:
For example, the code in parserthread.cpp
--- Code: --- if (token == _T("template"))
{
wxString args = m_Tokenizer.GetToken(false,true);
token = m_Tokenizer.GetToken();
if (args == _T("<>"))
{
m_Str.Clear();
wxString name = m_Tokenizer.GetToken();
args = m_Tokenizer.PeekToken(false,true);
m_Tokenizer.UngetToken();
}
if (token==ParserConsts::kw_class)
{
m_Str.Clear();
if (m_Options.handleClasses)
HandleClass(ctClass,args);
else
SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
continue;
}
else if (token==ParserConsts::kw_struct)
{
m_Str.Clear();
if (m_Options.handleClasses)
HandleClass(ctStructure,args);
else
SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
continue;
}
else
{
m_Tokenizer.UngetToken();
}
}
--- End code ---
It is really hard to understand the function call like "m_Tokenizer.GetToken(false,true);" , I think the function should still keep the consistent prototype like( simple and easy to understand) :
GetToken()
PeekToken()
I still can't understand what does these prototype means:
--- Code: --- wxString GetToken(bool bGetValue = false, bool bTemplate = false);
wxString PeekToken(bool bGetValue = false, bool bTemplate = false);
--- End code ---
:(
MortenMacFly:
--- Quote from: ollydbg on December 20, 2009, 02:20:02 pm ---I still can't understand what does these prototype means:
--- Code: --- wxString GetToken(bool bGetValue = false, bool bTemplate = false);
wxString PeekToken(bool bGetValue = false, bool bTemplate = false);
--- End code ---
:(
--- End quote ---
Agreed, the interface could be more clear. Please PM visualfc so he can have a look into...
ollydbg:
--- Quote from: MortenMacFly on December 20, 2009, 02:50:47 pm ---
--- Quote from: ollydbg on December 20, 2009, 02:20:02 pm ---I still can't understand what does these prototype means:
--- Code: --- wxString GetToken(bool bGetValue = false, bool bTemplate = false);
wxString PeekToken(bool bGetValue = false, bool bTemplate = false);
--- End code ---
:(
--- End quote ---
Agreed, the interface could be more clear. Please PM visualfc so he can have a look into...
--- End quote ---
Thanks, that's great that we have the same consideration :D.
Yes, I have notified him.
Currently, a workaround is to remove the "handling template related code". :D
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version