Code::Blocks - User contributions [en]

Code::Completion Rewrite

2008-03-16T03:16:41Z

Stevenkaras:

Here you'll find some discussion on the Code::Completion rewrite, and some useful links to related materials online.

== Background ==
The current Code::Completion plug-in has some flaws, and is currently development frozen.
The current plug-in lacks full support for:
# function and class templates
# default arguments in some cases
# some of the more complicated c++ mucky business

== Current Effort ==
=== Structure ===
The current C::C is a monolithic library of features, which could be de-coupled and split up for use in multiple plugins, providing extra functionality and flexibility in the future.
Therefore, I propose the C::C be broken up into the following components:

* Code::SymbolTable
** Provide a list of valid symbols in the workspace, along with relevant scope information
* Code::Completion
** Provide Auto-complete features
* Code::SymbolOutline
** Provide Symbol browser, find symbol, function jump features
* Code::Refactoring
** Provide code refactoring features
* Code::Documentation
** Provide automatic code generation features

=== Code::Completion ===
==== Purpose Statement ====
The current Code::Completion plugin is outdated, and needs a complete rewrite.
The purpose of the Code::Completion plugin is thus:

* Provide a list of likely symbols in the current scope as possible solutions to the current symbol.
* Provide function tooltips
** Parameter list
** Relevant documentation
* Provide variable tooltips
** type and modifiers
** scope
* Provide preprocessor tooltips
** replacement value of a macro
** parameter list when applicable
* Provide completion features for class constructors
* Provide completion features for initializer lists

==== Process ====
* The user requests a completion of the current symbol.
** Call CC::EventSymbolHover
*** When the mouse hovers over a symbol after a timeout
** Call CC::EventSymbolTip
*** When the user types in any of the following: . :: ->
*** When the user presses the keystroke CTRL-SPACE
** Call CC::EventCallTip
*** When the user types in any of the following: ( ,
*** When the user presses the keystroke CTRL-SHIFT-SPACE
** Call CC::EventPreprocTip
*** When the user types in any of the following: < " when in preproc context (# at the start of the line)
* the C::C plugin determines the proper scope, when applicable (global, local, class)
* Compare the current symbol against the symbol table of proper scope.
* Provide a composite list to the user.

=== Code::SymbolTable ===
There will be 3 symbol lists:
* global namespace
* local scope (2 options)
** the local scope can be generated by smartly parsing the current file on every request
** keep a running count, and add/remove symbols from the table as the file is edited
* class scope

Here's a good link for further reading on the subject and the problems:
[http://en.wikipedia.org/wiki/C%2B%2B#Parsing_and_processing_C.2B.2B_source_code On Wikipedia]

==== Data Proposal ====

class symbol
{
string name; // name of the symbol
int id; // Id of the symbol, should be unique in the workspace
int file_id; // Id of file where the symbol has been declared
int filepos_begin; // Position where declaration of the symbol starts
int filepos_end; // Position where declaration of the symbol ends
int type; // Type of the symbol: macro / class / typedef / variable / function
flags modifiers; // Bitfield used to mark some extra properties of symbol
// like that it is static or inline
int value_type_id; // Id of symbol which represents c++ type of current symbol
// (like type of variable or type of returned value from function)
int extra_type_id; // Extra type used in some cases
list children; // List of child elements of this symbol (members in class etc)
list extra_lists[3]; // See table below
map extra_values; // int -> string map which can keep some extra data
}

class list_entry
{
int symbol_id; // ID of the symbol referenced
int storage_class; // Storage class of the symbol (private/protected/public)
}

Explanation of symbol::extra_lists[]
{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 1px solid gray;"
! type
! modifiers
! value_type_id
! extra_type
! children
! extra_lists[0]
! extra_lists[1]
! extra_lists[2]
|-

|-
| namespace
|
|
|
| declarations in namespace
|"using" namespaces
|
|
|-

|-
| class / struct / union
|
|
|
| members of class
| base classes
| template args
| friends of class
|-

|-
| variable
| extern, static, volatile, const
| type of variable
|
|
|
|
|
|-

|-
| function
| static, inline, const ...
| returned value
|
| arguments
| template arguments
|
|
|-

|-
| typedef
| pointer, array, reference, pointer_to_member
| base type
| type of class in pointer_to_member
|
|
|
|
|-

|-
| enum
|
|
|
| items in enum
|
|
|
|-

|-
| enum item
|
|
| id of enum
|
|
|
|
|-

|-
| macro
|
|
|
| macro parts
|
|
|
|-

|-
| macro part
| arg_to_string, va_args
| number of arg or -1
|
|
|
|
|
|-

|}

Comments:
* Such representation would require some extra "hidden" symbols - for example when some complex type is returned from function, extra symbol of typedef representing proper value would be required.
* Also in case of templates, typeid's should be threated in special way - negative value could mean to use template argument instead of some real type. Base types (the POD ones) should have some predefined type ids.

Questions:
* why are we storing filepos_end? Wouldn't it be much more useful to store declaration, definition info?

== More complex cases of C::C usage ==

Here we can put some more complex examples of c++ code where C::C may fail. Symbols that may be hard to find should be marked in bold

=== Fetching type of operator call ===

#include <string>
using namespace std;

int main(int,char**)
{
( string("first") + "second" + "third" ) . '''c_str'''();
return 0;
}

=== Template classes ===

template<typename T> class Template
{
public:
T& GetInstance() { return m_Instance; }
private:
T m_Instance;
};

class Parameter
{
public:
void PrintfText() { printf("Text"); }
};

int main(int,char**)
{
Template<Parameter> Object;
Object.GetInstance().'''PrintfText'''();
}

=== Automated deduction of template arguments from passed function arguments ===

#include <stdio.h>

class Class
{
public:
void SomeFunction() { printf("SomeFunction\n"); }
};

template< class T > T& Function( T& arg )
{
return arg;
}

int main( int, char** )
{
Class f;
Function(f).'''SomeFunction'''();
return 0;
}

=== Template arguments for templates ===

#include <stdio.h>

template< template<class> class InternalTemplate, typename Type > class Test
{
public:

InternalTemplate<Type> m_Member;
};

template< class T > class TestInt
{
public:

T m_IntMember;
};

class Class
{
public:

void Print() { printf("Class::Print\n"); }
};

int main( int, char** )
{
Test<TestInt,Class> Object;
Object.m_Member.'''m_IntMember'''.'''Print'''();
return 0;
}

=== Partial specializations ===

#include <stdio.h>

template< class T > class Template
{
public:
void Print() { printf("Generic specialization\n"); }
};

template<> class Template<float>
{
public:
void PrintFloat() { printf("Partial specialization\n"); }
};

int main(int,char**)
{
Template<int> TInt;
TInt.'''Print'''(); // PrintFloat() should not be available here

Template<float> TFloat;
TFloat.'''PrintFloat'''(); // Print() should not be available here

return 0;
}

=== Advanced template argument deduction ===

#include <stdio.h>

// Class encapsulating function without arguments
class Caller0
{
void (* m_Func )( void );

public:

Caller0( void (* Func )( void ) ) : m_Func(Func) {}

void Call0() { m_Func(); }
};

// Template for class encapsulating function with one argument
template < class T > class Caller1
{
void (* m_Func )( T );

public:

Caller1( void (* Func )( T ) ) : m_Func(Func) {}

void Call1() { m_Func( T() ); }
};

// Template for class encapsulating function with two arguments
template < class T1, class T2 > class Caller2
{
void (* m_Func )( T1, T2 );

public:

Caller2( void (* Func )( T1, T2 ) ) : m_Func(Func) {}

void Call2() { m_Func ( T1(), T2() ); }
};

// This one will be used for functions without arguments
Caller0 Invoke( void (* Func )( void ) )
{
return Caller0( Func );
}

// This one will be used for functions with one argument
template < class T > Caller1<T> Invoke( void (* Func )( T ) )
{
return Caller1<T>( Func );
}

// This one will be used for functions with two arguments
template < class T1, class T2 > Caller2<T1,T2> Invoke( void (* Func )( T1, T2 ) )
{
return Caller2<T1,T2> ( Func );
}

void Function0(void)
{
printf("Function0\n");
}

void Function1(float)
{
printf("Function1\n");
}

void Function2(int)
{
printf("Function2\n");
}

void Function3(int,float)
{
printf("Function3\n");
}

int main(int,char**)
{
Invoke( Function0 ).'''Call0'''();
Invoke( Function1 ).'''Call1'''();
Invoke( Function2 ).'''Call1'''();
Invoke( Function3 ).'''Call2'''();

Invoke( &Function0 ).'''Call0'''();
Invoke( &Function1 ).'''Call1'''();
Invoke( &Function2 ).'''Call1'''();
Invoke( &Function3 ).'''Call2'''();
return 0;
}

=== Hidden virtual functions ===

class Base
{
public:
virtual void stam(int);
};

class Derived : Base
{
public:
void stam(double, int);
};

main()
{
Base * pBase = new Derived;
pBase->'''stam('''
^ Function tip should show stam(double, int)
}

=== Macros hiding include files ===
in header.h
int x;
in main.cpp
#define myHeader "header.h"
#include myHeader

main()
{
int '''x''';
}

Code::Completion Rewrite

2008-03-16T02:09:27Z

Stevenkaras: /* Hidden virtual functions */

== Background ==
The current Code::Completion plug-in has some flaws, and is currently development frozen.
The current plug-in lacks full support for:
# function and class templates
# default arguments in some cases
# some of the more complicated c++ mucky business

== Current Effort ==
=== Structure ===
The current C::C is a monolithic library of features, which could be de-coupled and split up for use in multiple plugins, providing extra functionality and flexibility in the future.
Therefore, I propose the C::C be broken up into the following components:

* Code::SymbolTable
** Provide a list of valid symbols in the workspace, along with relevant scope information
* Code::Completion
** Provide Auto-complete features
* Code::SymbolOutline
** Provide Symbol browser, find symbol, function jump features
* Code::Refactoring
** Provide code refactoring features
* Code::Documentation
** Provide automatic code generation features

=== Code::Completion ===
==== Purpose Statement ====
The current Code::Completion plugin is outdated, and needs a complete rewrite.
The purpose of the Code::Completion plugin is thus:

* Provide a list of likely symbols in the current scope as possible solutions to the current symbol.
* Provide function tooltips
** Parameter list
** Relevant documentation
* Provide variable tooltips
** type and modifiers
** scope
* Provide preprocessor tooltips
** replacement value of a macro
** parameter list when applicable
* Provide completion features for class constructors
* Provide completion features for initializer lists

==== Process ====
* The user requests a completion of the current symbol.
** Call CC::EventSymbolHover
*** When the mouse hovers over a symbol after a timeout
** Call CC::EventSymbolTip
*** When the user types in any of the following: . :: ->
*** When the user presses the keystroke CTRL-SPACE
** Call CC::EventCallTip
*** When the user types in any of the following: ( ,
*** When the user presses the keystroke CTRL-SHIFT-SPACE
** Call CC::EventPreprocTip
*** When the user types in any of the following: < " when in preproc context (# at the start of the line)
* the C::C plugin determines the proper scope, when applicable (global, local, class)
* Compare the current symbol against the symbol table of proper scope.
* Provide a composite list to the user.

=== Code::SymbolTable ===
There will be 3 symbol lists:
* global namespace
* local scope (2 options)
** the local scope can be generated by smartly parsing the current file on every request
** keep a running count, and add/remove symbols from the table as the file is edited
* class scope

Here's a good link for further reading on the subject and the problems:
[http://en.wikipedia.org/wiki/C%2B%2B#Parsing_and_processing_C.2B.2B_source_code On Wikipedia]

==== Data Proposal ====

class symbol
{
string name; // name of the symbol
int id; // Id of the symbol, should be unique in the workspace
int file_id; // Id of file where the symbol has been declared
int filepos_begin; // Position where declaration of the symbol starts
int filepos_end; // Position where declaration of the symbol ends
int type; // Type of the symbol: macro / class / typedef / variable / function
flags modifiers; // Bitfield used to mark some extra properties of symbol
// like that it is static or inline
int value_type_id; // Id of symbol which represents c++ type of current symbol
// (like type of variable or type of returned value from function)
int extra_type_id; // Extra type used in some cases
list children; // List of child elements of this symbol (members in class etc)
list extra_lists[3]; // See table below
map extra_values; // int -> string map which can keep some extra data
}

class list_entry
{
int symbol_id; // ID of the symbol referenced
int storage_class; // Storage class of the symbol (private/protected/public)
}

Explanation of symbol::extra_lists[]
{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 1px solid gray;"
! type
! modifiers
! value_type_id
! extra_type
! children
! extra_lists[0]
! extra_lists[1]
! extra_lists[2]
|-

|-
| namespace
|
|
|
| declarations in namespace
|"using" namespaces
|
|
|-

|-
| class / struct / union
|
|
|
| members of class
| base classes
| template args
| friends of class
|-

|-
| variable
| extern, static, volatile, const
| type of variable
|
|
|
|
|
|-

|-
| function
| static, inline, const ...
| returned value
|
| arguments
| template arguments
|
|
|-

|-
| typedef
| pointer, array, reference, pointer_to_member
| base type
| type of class in pointer_to_member
|
|
|
|
|-

|-
| enum
|
|
|
| items in enum
|
|
|
|-

|-
| enum item
|
|
| id of enum
|
|
|
|
|-

|-
| macro
|
|
|
| macro parts
|
|
|
|-

|-
| macro part
| arg_to_string, va_args
| number of arg or -1
|
|
|
|
|
|-

|}

Comments:
* Such representation would require some extra "hidden" symbols - for example when some complex type is returned from function, extra symbol of typedef representing proper value would be required.
* Also in case of templates, typeid's should be threated in special way - negative value could mean to use template argument instead of some real type. Base types (the POD ones) should have some predefined type ids.

Questions:
* why are we storing filepos_end? Wouldn't it be much more useful to store declaration, definition info?

== More complex cases of C::C usage ==

Here we can put some more complex examples of c++ code where C::C may fail. Symbols that may be hard to find should be marked in bold

=== Fetching type of operator call ===

#include <string>
using namespace std;

int main(int,char**)
{
( string("first") + "second" + "third" ) . '''c_str'''();
return 0;
}

=== Template classes ===

template<typename T> class Template
{
public:
T& GetInstance() { return m_Instance; }
private:
T m_Instance;
};

class Parameter
{
public:
void PrintfText() { printf("Text"); }
};

int main(int,char**)
{
Template<Parameter> Object;
Object.GetInstance().'''PrintfText'''();
}

=== Automated deduction of template arguments from passed function arguments ===

#include <stdio.h>

class Class
{
public:
void SomeFunction() { printf("SomeFunction\n"); }
};

template< class T > T& Function( T& arg )
{
return arg;
}

int main( int, char** )
{
Class f;
Function(f).'''SomeFunction'''();
return 0;
}

=== Template arguments for templates ===

#include <stdio.h>

template< template<class> class InternalTemplate, typename Type > class Test
{
public:

InternalTemplate<Type> m_Member;
};

template< class T > class TestInt
{
public:

T m_IntMember;
};

class Class
{
public:

void Print() { printf("Class::Print\n"); }
};

int main( int, char** )
{
Test<TestInt,Class> Object;
Object.m_Member.'''m_IntMember'''.'''Print'''();
return 0;
}

=== Partial specializations ===

#include <stdio.h>

template< class T > class Template
{
public:
void Print() { printf("Generic specialization\n"); }
};

template<> class Template<float>
{
public:
void PrintFloat() { printf("Partial specialization\n"); }
};

int main(int,char**)
{
Template<int> TInt;
TInt.'''Print'''(); // PrintFloat() should not be available here

Template<float> TFloat;
TFloat.'''PrintFloat'''(); // Print() should not be available here

return 0;
}

=== Advanced template argument deduction ===

#include <stdio.h>

// Class encapsulating function without arguments
class Caller0
{
void (* m_Func )( void );

public:

Caller0( void (* Func )( void ) ) : m_Func(Func) {}

void Call0() { m_Func(); }
};

// Template for class encapsulating function with one argument
template < class T > class Caller1
{
void (* m_Func )( T );

public:

Caller1( void (* Func )( T ) ) : m_Func(Func) {}

void Call1() { m_Func( T() ); }
};

// Template for class encapsulating function with two arguments
template < class T1, class T2 > class Caller2
{
void (* m_Func )( T1, T2 );

public:

Caller2( void (* Func )( T1, T2 ) ) : m_Func(Func) {}

void Call2() { m_Func ( T1(), T2() ); }
};

// This one will be used for functions without arguments
Caller0 Invoke( void (* Func )( void ) )
{
return Caller0( Func );
}

// This one will be used for functions with one argument
template < class T > Caller1<T> Invoke( void (* Func )( T ) )
{
return Caller1<T>( Func );
}

// This one will be used for functions with two arguments
template < class T1, class T2 > Caller2<T1,T2> Invoke( void (* Func )( T1, T2 ) )
{
return Caller2<T1,T2> ( Func );
}

void Function0(void)
{
printf("Function0\n");
}

void Function1(float)
{
printf("Function1\n");
}

void Function2(int)
{
printf("Function2\n");
}

void Function3(int,float)
{
printf("Function3\n");
}

int main(int,char**)
{
Invoke( Function0 ).'''Call0'''();
Invoke( Function1 ).'''Call1'''();
Invoke( Function2 ).'''Call1'''();
Invoke( Function3 ).'''Call2'''();

Invoke( &Function0 ).'''Call0'''();
Invoke( &Function1 ).'''Call1'''();
Invoke( &Function2 ).'''Call1'''();
Invoke( &Function3 ).'''Call2'''();
return 0;
}

=== Hidden virtual functions ===

class Base
{
public:
virtual void stam(int);
};

class Derived : Base
{
public:
void stam(double, int);
};

main()
{
Base * pBase = new Derived;
pBase->'''stam('''
^ Function tip should show stam(double, int)
}

=== Macros hiding include files ===
in header.h
int x;
in main.cpp
#define myHeader "header.h"
#include myHeader

main()
{
int '''x''';
}

Code::Completion Rewrite

2008-03-16T01:47:39Z

Stevenkaras: /* Hidden virtual functions */ fixed formatting

Code::Completion Rewrite

2008-03-16T01:42:40Z

Stevenkaras: /* Code::SymbolTable */ Added Wikipedia reference

Code::Completion Rewrite

2008-03-16T01:38:20Z

Stevenkaras: /* More complex cases of C::C usage */ Removed numbers from section headers, added new case

== Background ==
The current Code::Completion plug-in has some flaws, and is currently development frozen.
The current plug-in lacks full support for:
# function and class templates
# default arguments in some cases
# some of the more complicated c++ mucky business

== Current Effort ==
=== Structure ===
The current C::C is a monolithic library of features, which could be de-coupled and split up for use in multiple plugins, providing extra functionality and flexibility in the future.
Therefore, I propose the C::C be broken up into the following components:

* Code::SymbolTable
** Provide a list of valid symbols in the workspace, along with relevant scope information
* Code::Completion
** Provide Auto-complete features
* Code::SymbolOutline
** Provide Symbol browser, find symbol, function jump features
* Code::Refactoring
** Provide code refactoring features
* Code::Documentation
** Provide automatic code generation features

=== Code::Completion ===
==== Purpose Statement ====
The current Code::Completion plugin is outdated, and needs a complete rewrite.
The purpose of the Code::Completion plugin is thus:

* Provide a list of likely symbols in the current scope as possible solutions to the current symbol.
* Provide function tooltips
** Parameter list
** Relevant documentation
* Provide variable tooltips
** type and modifiers
** scope
* Provide preprocessor tooltips
** replacement value of a macro
** parameter list when applicable
* Provide completion features for class constructors
* Provide completion features for initializer lists

==== Process ====
* The user requests a completion of the current symbol.
** Call CC::EventSymbolHover
*** When the mouse hovers over a symbol after a timeout
** Call CC::EventSymbolTip
*** When the user types in any of the following: . :: ->
*** When the user presses the keystroke CTRL-SPACE
** Call CC::EventCallTip
*** When the user types in any of the following: ( ,
*** When the user presses the keystroke CTRL-SHIFT-SPACE
** Call CC::EventPreprocTip
*** When the user types in any of the following: < " when in preproc context (# at the start of the line)
* the C::C plugin determines the proper scope, when applicable (global, local, class)
* Compare the current symbol against the symbol table of proper scope.
* Provide a composite list to the user.

=== Code::SymbolTable ===
There will be 3 symbol lists:
* global namespace
* local scope (2 options)
** the local scope can be generated by smartly parsing the current file on every request
** keep a running count, and add/remove symbols from the table as the file is edited
* class scope

Here's the current data proposal:

class symbol
{
string name; // name of the symbol
int id; // Id of the symbol, should be unique in the workspace
int file_id; // Id of file where the symbol has been declared
int filepos_begin; // Position where declaration of the symbol starts
int filepos_end; // Position where declaration of the symbol ends
int type; // Type of the symbol: macro / class / typedef / variable / function
flags modifiers; // Bitfield used to mark some extra properties of symbol
// like that it is static or inline
int value_type_id; // Id of symbol which represents c++ type of current symbol
// (like type of variable or type of returned value from function)
int extra_type_id; // Extra type used in some cases
list children; // List of child elements of this symbol (members in class etc)
list extra_lists[3]; // See table below
map extra_values; // int -> string map which can keep some extra data
}

class list_entry
{
int symbol_id; // ID of the symbol referenced
int storage_class; // Storage class of the symbol (private/protected/public)
}

Explanation of symbol::extra_lists[]
{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 1px solid gray;"
! type
! modifiers
! value_type_id
! extra_type
! children
! extra_lists[0]
! extra_lists[1]
! extra_lists[2]
|-

|-
| namespace
|
|
|
| declarations in namespace
|"using" namespaces
|
|
|-

|-
| class / struct / union
|
|
|
| members of class
| base classes
| template args
| friends of class
|-

|-
| variable
| extern, static, volatile, const
| type of variable
|
|
|
|
|
|-

|-
| function
| static, inline, const ...
| returned value
|
| arguments
| template arguments
|
|
|-

|-
| typedef
| pointer, array, reference, pointer_to_member
| base type
| type of class in pointer_to_member
|
|
|
|
|-

|-
| enum
|
|
|
| items in enum
|
|
|
|-

|-
| enum item
|
|
| id of enum
|
|
|
|
|-

|-
| macro
|
|
|
| macro parts
|
|
|
|-

|-
| macro part
| arg_to_string, va_args
| number of arg or -1
|
|
|
|
|
|-

|}

Comments:
* Such representation would require some extra "hidden" symbols - for example when some complex type is returned from function, extra symbol of typedef representing proper value would be required.
* Also in case of templates, typeid's should be threated in special way - negative value could mean to use template argument instead of some real type. Base types (the POD ones) should have some predefined type ids.

Questions:
* why are we storing filepos_end? Wouldn't it be much more useful to store declaration, definition info?

== More complex cases of C::C usage ==

Here we can put some more complex examples of c++ code where C::C may fail. Symbols that may be hard to find should be marked in bold

=== Fetching type of operator call ===

#include <string>
using namespace std;

int main(int,char**)
{
( string("first") + "second" + "third" ) . '''c_str'''();
return 0;
}

=== Template classes ===

template<typename T> class Template
{
public:
T& GetInstance() { return m_Instance; }
private:
T m_Instance;
};

class Parameter
{
public:
void PrintfText() { printf("Text"); }
};

int main(int,char**)
{
Template<Parameter> Object;
Object.GetInstance().'''PrintfText'''();
}

=== Automated deduction of template arguments from passed function arguments ===

#include <stdio.h>

class Class
{
public:
void SomeFunction() { printf("SomeFunction\n"); }
};

template< class T > T& Function( T& arg )
{
return arg;
}

int main( int, char** )
{
Class f;
Function(f).'''SomeFunction'''();
return 0;
}

=== Template arguments for templates ===

#include <stdio.h>

template< template<class> class InternalTemplate, typename Type > class Test
{
public:

InternalTemplate<Type> m_Member;
};

template< class T > class TestInt
{
public:

T m_IntMember;
};

class Class
{
public:

void Print() { printf("Class::Print\n"); }
};

int main( int, char** )
{
Test<TestInt,Class> Object;
Object.m_Member.'''m_IntMember'''.'''Print'''();
return 0;
}

=== Partial specializations ===

#include <stdio.h>

template< class T > class Template
{
public:
void Print() { printf("Generic specialization\n"); }
};

template<> class Template<float>
{
public:
void PrintFloat() { printf("Partial specialization\n"); }
};

int main(int,char**)
{
Template<int> TInt;
TInt.'''Print'''(); // PrintFloat() should not be available here

Template<float> TFloat;
TFloat.'''PrintFloat'''(); // Print() should not be available here

return 0;
}

=== Advanced template argument deduction ===

#include <stdio.h>

// Class encapsulating function without arguments
class Caller0
{
void (* m_Func )( void );

public:

Caller0( void (* Func )( void ) ) : m_Func(Func) {}

void Call0() { m_Func(); }
};

// Template for class encapsulating function with one argument
template < class T > class Caller1
{
void (* m_Func )( T );

public:

Caller1( void (* Func )( T ) ) : m_Func(Func) {}

void Call1() { m_Func( T() ); }
};

// Template for class encapsulating function with two arguments
template < class T1, class T2 > class Caller2
{
void (* m_Func )( T1, T2 );

public:

Caller2( void (* Func )( T1, T2 ) ) : m_Func(Func) {}

void Call2() { m_Func ( T1(), T2() ); }
};

// This one will be used for functions without arguments
Caller0 Invoke( void (* Func )( void ) )
{
return Caller0( Func );
}

// This one will be used for functions with one argument
template < class T > Caller1<T> Invoke( void (* Func )( T ) )
{
return Caller1<T>( Func );
}

// This one will be used for functions with two arguments
template < class T1, class T2 > Caller2<T1,T2> Invoke( void (* Func )( T1, T2 ) )
{
return Caller2<T1,T2> ( Func );
}

void Function0(void)
{
printf("Function0\n");
}

void Function1(float)
{
printf("Function1\n");
}

void Function2(int)
{
printf("Function2\n");
}

void Function3(int,float)
{
printf("Function3\n");
}

int main(int,char**)
{
Invoke( Function0 ).'''Call0'''();
Invoke( Function1 ).'''Call1'''();
Invoke( Function2 ).'''Call1'''();
Invoke( Function3 ).'''Call2'''();

Invoke( &Function0 ).'''Call0'''();
Invoke( &Function1 ).'''Call1'''();
Invoke( &Function2 ).'''Call1'''();
Invoke( &Function3 ).'''Call2'''();
return 0;
}

=== Hidden virtual functions ===

class Base
{
public:
virtual void stam(int);
};

class Derived : Base
{
public:
void stam(double, int);
};

main()
{
Base * pBase = new Derived;
pBase->'''stam('''
^ Function tip should show stam(double, int)
}

Code::Completion Rewrite

2008-03-16T01:27:52Z

Stevenkaras: /* Process */

== Background ==
The current Code::Completion plug-in has some flaws, and is currently development frozen.
The current plug-in lacks full support for:
# function and class templates
# default arguments in some cases
# some of the more complicated c++ mucky business

== Current Effort ==
=== Structure ===
The current C::C is a monolithic library of features, which could be de-coupled and split up for use in multiple plugins, providing extra functionality and flexibility in the future.
Therefore, I propose the C::C be broken up into the following components:

* Code::SymbolTable
** Provide a list of valid symbols in the workspace, along with relevant scope information
* Code::Completion
** Provide Auto-complete features
* Code::SymbolOutline
** Provide Symbol browser, find symbol, function jump features
* Code::Refactoring
** Provide code refactoring features
* Code::Documentation
** Provide automatic code generation features

=== Code::Completion ===
==== Purpose Statement ====
The current Code::Completion plugin is outdated, and needs a complete rewrite.
The purpose of the Code::Completion plugin is thus:

* Provide a list of likely symbols in the current scope as possible solutions to the current symbol.
* Provide function tooltips
** Parameter list
** Relevant documentation
* Provide variable tooltips
** type and modifiers
** scope
* Provide preprocessor tooltips
** replacement value of a macro
** parameter list when applicable
* Provide completion features for class constructors
* Provide completion features for initializer lists

==== Process ====
* The user requests a completion of the current symbol.
** Call CC::EventSymbolHover
*** When the mouse hovers over a symbol after a timeout
** Call CC::EventSymbolTip
*** When the user types in any of the following: . :: ->
*** When the user presses the keystroke CTRL-SPACE
** Call CC::EventCallTip
*** When the user types in any of the following: ( ,
*** When the user presses the keystroke CTRL-SHIFT-SPACE
** Call CC::EventPreprocTip
*** When the user types in any of the following: < " when in preproc context (# at the start of the line)
* the C::C plugin determines the proper scope, when applicable (global, local, class)
* Compare the current symbol against the symbol table of proper scope.
* Provide a composite list to the user.

=== Code::SymbolTable ===
There will be 3 symbol lists:
* global namespace
* local scope (2 options)
** the local scope can be generated by smartly parsing the current file on every request
** keep a running count, and add/remove symbols from the table as the file is edited
* class scope

Here's the current data proposal:

class symbol
{
string name; // name of the symbol
int id; // Id of the symbol, should be unique in the workspace
int file_id; // Id of file where the symbol has been declared
int filepos_begin; // Position where declaration of the symbol starts
int filepos_end; // Position where declaration of the symbol ends
int type; // Type of the symbol: macro / class / typedef / variable / function
flags modifiers; // Bitfield used to mark some extra properties of symbol
// like that it is static or inline
int value_type_id; // Id of symbol which represents c++ type of current symbol
// (like type of variable or type of returned value from function)
int extra_type_id; // Extra type used in some cases
list children; // List of child elements of this symbol (members in class etc)
list extra_lists[3]; // See table below
map extra_values; // int -> string map which can keep some extra data
}

class list_entry
{
int symbol_id; // ID of the symbol referenced
int storage_class; // Storage class of the symbol (private/protected/public)
}

Explanation of symbol::extra_lists[]
{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 1px solid gray;"
! type
! modifiers
! value_type_id
! extra_type
! children
! extra_lists[0]
! extra_lists[1]
! extra_lists[2]
|-

|-
| namespace
|
|
|
| declarations in namespace
|"using" namespaces
|
|
|-

|-
| class / struct / union
|
|
|
| members of class
| base classes
| template args
| friends of class
|-

|-
| variable
| extern, static, volatile, const
| type of variable
|
|
|
|
|
|-

|-
| function
| static, inline, const ...
| returned value
|
| arguments
| template arguments
|
|
|-

|-
| typedef
| pointer, array, reference, pointer_to_member
| base type
| type of class in pointer_to_member
|
|
|
|
|-

|-
| enum
|
|
|
| items in enum
|
|
|
|-

|-
| enum item
|
|
| id of enum
|
|
|
|
|-

|-
| macro
|
|
|
| macro parts
|
|
|
|-

|-
| macro part
| arg_to_string, va_args
| number of arg or -1
|
|
|
|
|
|-

|}

Comments:
* Such representation would require some extra "hidden" symbols - for example when some complex type is returned from function, extra symbol of typedef representing proper value would be required.
* Also in case of templates, typeid's should be threated in special way - negative value could mean to use template argument instead of some real type. Base types (the POD ones) should have some predefined type ids.

Questions:
* why are we storing filepos_end? Wouldn't it be much more useful to store declaration, definition info?

== More complex cases of C::C usage ==

Here we can put some more complex examples of c++ code where C::C may fail. Symbols that may be hard to find should be marked in bold

=== 1: Fetching type of operator call ===

#include <string>
using namespace std;

int main(int,char**)
{
( string("first") + "second" + "third" ) . '''c_str'''();
return 0;
}

=== 2: Template classes ===

template<typename T> class Template
{
public:
T& GetInstance() { return m_Instance; }
private:
T m_Instance;
};

class Parameter
{
public:
void PrintfText() { printf("Text"); }
};

int main(int,char**)
{
Template<Parameter> Object;
Object.GetInstance().'''PrintfText'''();
}

=== 3: Automated deduction of template arguments from passed function arguments ===

#include <stdio.h>

class Class
{
public:
void SomeFunction() { printf("SomeFunction\n"); }
};

template< class T > T& Function( T& arg )
{
return arg;
}

int main( int, char** )
{
Class f;
Function(f).'''SomeFunction'''();
return 0;
}

=== 4. Template arguments for templates ===

#include <stdio.h>

template< template<class> class InternalTemplate, typename Type > class Test
{
public:

InternalTemplate<Type> m_Member;
};

template< class T > class TestInt
{
public:

T m_IntMember;
};

class Class
{
public:

void Print() { printf("Class::Print\n"); }
};

int main( int, char** )
{
Test<TestInt,Class> Object;
Object.m_Member.'''m_IntMember'''.'''Print'''();
return 0;
}

=== 5. Partial specializations ===

#include <stdio.h>

template< class T > class Template
{
public:
void Print() { printf("Generic specialization\n"); }
};

template<> class Template<float>
{
public:
void PrintFloat() { printf("Partial specialization\n"); }
};

int main(int,char**)
{
Template<int> TInt;
TInt.'''Print'''(); // PrintFloat() should not be available here

Template<float> TFloat;
TFloat.'''PrintFloat'''(); // Print() should not be available here

return 0;
}

=== 6. Advanced template argument deduction ===

#include <stdio.h>

// Class encapsulating function without arguments
class Caller0
{
void (* m_Func )( void );

public:

Caller0( void (* Func )( void ) ) : m_Func(Func) {}

void Call0() { m_Func(); }
};

// Template for class encapsulating function with one argument
template < class T > class Caller1
{
void (* m_Func )( T );

public:

Caller1( void (* Func )( T ) ) : m_Func(Func) {}

void Call1() { m_Func( T() ); }
};

// Template for class encapsulating function with two arguments
template < class T1, class T2 > class Caller2
{
void (* m_Func )( T1, T2 );

public:

Caller2( void (* Func )( T1, T2 ) ) : m_Func(Func) {}

void Call2() { m_Func ( T1(), T2() ); }
};

// This one will be used for functions without arguments
Caller0 Invoke( void (* Func )( void ) )
{
return Caller0( Func );
}

// This one will be used for functions with one argument
template < class T > Caller1<T> Invoke( void (* Func )( T ) )
{
return Caller1<T>( Func );
}

// This one will be used for functions with two arguments
template < class T1, class T2 > Caller2<T1,T2> Invoke( void (* Func )( T1, T2 ) )
{
return Caller2<T1,T2> ( Func );
}

void Function0(void)
{
printf("Function0\n");
}

void Function1(float)
{
printf("Function1\n");
}

void Function2(int)
{
printf("Function2\n");
}

void Function3(int,float)
{
printf("Function3\n");
}

int main(int,char**)
{
Invoke( Function0 ).'''Call0'''();
Invoke( Function1 ).'''Call1'''();
Invoke( Function2 ).'''Call1'''();
Invoke( Function3 ).'''Call2'''();

Invoke( &Function0 ).'''Call0'''();
Invoke( &Function1 ).'''Call1'''();
Invoke( &Function2 ).'''Call1'''();
Invoke( &Function3 ).'''Call2'''();
return 0;
}

Code::Completion Rewrite

2008-03-16T01:25:53Z

Stevenkaras: /* Code::SymbolTable */

== Background ==
The current Code::Completion plug-in has some flaws, and is currently development frozen.
The current plug-in lacks full support for:
# function and class templates
# default arguments in some cases
# some of the more complicated c++ mucky business

== Current Effort ==
=== Structure ===
The current C::C is a monolithic library of features, which could be de-coupled and split up for use in multiple plugins, providing extra functionality and flexibility in the future.
Therefore, I propose the C::C be broken up into the following components:

* Code::SymbolTable
** Provide a list of valid symbols in the workspace, along with relevant scope information
* Code::Completion
** Provide Auto-complete features
* Code::SymbolOutline
** Provide Symbol browser, find symbol, function jump features
* Code::Refactoring
** Provide code refactoring features
* Code::Documentation
** Provide automatic code generation features

=== Code::Completion ===
==== Purpose Statement ====
The current Code::Completion plugin is outdated, and needs a complete rewrite.
The purpose of the Code::Completion plugin is thus:

* Provide a list of likely symbols in the current scope as possible solutions to the current symbol.
* Provide function tooltips
** Parameter list
** Relevant documentation
* Provide variable tooltips
** type and modifiers
** scope
* Provide preprocessor tooltips
** replacement value of a macro
** parameter list when applicable
* Provide completion features for class constructors
* Provide completion features for initializer lists

==== Process ====
* The user requests a completion of the current symbol.
** Call CC::EventSymbolHover
*** When the mouse hovers over a symbol after a timeout
** Call CC::EventSymbolTip
*** When the user types in any of the following: . :: ->
*** When the user presses the keystroke CTRL-SPACE
** Call CC::EventCallTip
*** When the user types in any of the following: (
*** When the user presses the keystroke CTRL-SHIFT-SPACE
** Call CC::EventPreprocTip
*** When the user types in any of the following: < " when in preproc context (# at the start of the line)
* the C::C plugin determines the proper scope, when applicable (global, local, class)
* Compare the current symbol against the symbol table of proper scope.
* Provide a composite list to the user.

=== Code::SymbolTable ===
There will be 3 symbol lists:
* global namespace
* local scope (2 options)
** the local scope can be generated by smartly parsing the current file on every request
** keep a running count, and add/remove symbols from the table as the file is edited
* class scope

Here's the current data proposal:

class symbol
{
string name; // name of the symbol
int id; // Id of the symbol, should be unique in the workspace
int file_id; // Id of file where the symbol has been declared
int filepos_begin; // Position where declaration of the symbol starts
int filepos_end; // Position where declaration of the symbol ends
int type; // Type of the symbol: macro / class / typedef / variable / function
flags modifiers; // Bitfield used to mark some extra properties of symbol
// like that it is static or inline
int value_type_id; // Id of symbol which represents c++ type of current symbol
// (like type of variable or type of returned value from function)
int extra_type_id; // Extra type used in some cases
list children; // List of child elements of this symbol (members in class etc)
list extra_lists[3]; // See table below
map extra_values; // int -> string map which can keep some extra data
}

class list_entry
{
int symbol_id; // ID of the symbol referenced
int storage_class; // Storage class of the symbol (private/protected/public)
}

Explanation of symbol::extra_lists[]
{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 1px solid gray;"
! type
! modifiers
! value_type_id
! extra_type
! children
! extra_lists[0]
! extra_lists[1]
! extra_lists[2]
|-

|-
| namespace
|
|
|
| declarations in namespace
|"using" namespaces
|
|
|-

|-
| class / struct / union
|
|
|
| members of class
| base classes
| template args
| friends of class
|-

|-
| variable
| extern, static, volatile, const
| type of variable
|
|
|
|
|
|-

|-
| function
| static, inline, const ...
| returned value
|
| arguments
| template arguments
|
|
|-

|-
| typedef
| pointer, array, reference, pointer_to_member
| base type
| type of class in pointer_to_member
|
|
|
|
|-

|-
| enum
|
|
|
| items in enum
|
|
|
|-

|-
| enum item
|
|
| id of enum
|
|
|
|
|-

|-
| macro
|
|
|
| macro parts
|
|
|
|-

|-
| macro part
| arg_to_string, va_args
| number of arg or -1
|
|
|
|
|
|-

|}

Comments:
* Such representation would require some extra "hidden" symbols - for example when some complex type is returned from function, extra symbol of typedef representing proper value would be required.
* Also in case of templates, typeid's should be threated in special way - negative value could mean to use template argument instead of some real type. Base types (the POD ones) should have some predefined type ids.

Questions:
* why are we storing filepos_end? Wouldn't it be much more useful to store declaration, definition info?

== More complex cases of C::C usage ==

Here we can put some more complex examples of c++ code where C::C may fail. Symbols that may be hard to find should be marked in bold

=== 1: Fetching type of operator call ===

#include <string>
using namespace std;

int main(int,char**)
{
( string("first") + "second" + "third" ) . '''c_str'''();
return 0;
}

=== 2: Template classes ===

template<typename T> class Template
{
public:
T& GetInstance() { return m_Instance; }
private:
T m_Instance;
};

class Parameter
{
public:
void PrintfText() { printf("Text"); }
};

int main(int,char**)
{
Template<Parameter> Object;
Object.GetInstance().'''PrintfText'''();
}

=== 3: Automated deduction of template arguments from passed function arguments ===

#include <stdio.h>

class Class
{
public:
void SomeFunction() { printf("SomeFunction\n"); }
};

template< class T > T& Function( T& arg )
{
return arg;
}

int main( int, char** )
{
Class f;
Function(f).'''SomeFunction'''();
return 0;
}

=== 4. Template arguments for templates ===

#include <stdio.h>

template< template<class> class InternalTemplate, typename Type > class Test
{
public:

InternalTemplate<Type> m_Member;
};

template< class T > class TestInt
{
public:

T m_IntMember;
};

class Class
{
public:

void Print() { printf("Class::Print\n"); }
};

int main( int, char** )
{
Test<TestInt,Class> Object;
Object.m_Member.'''m_IntMember'''.'''Print'''();
return 0;
}

=== 5. Partial specializations ===

#include <stdio.h>

template< class T > class Template
{
public:
void Print() { printf("Generic specialization\n"); }
};

template<> class Template<float>
{
public:
void PrintFloat() { printf("Partial specialization\n"); }
};

int main(int,char**)
{
Template<int> TInt;
TInt.'''Print'''(); // PrintFloat() should not be available here

Template<float> TFloat;
TFloat.'''PrintFloat'''(); // Print() should not be available here

return 0;
}

=== 6. Advanced template argument deduction ===

#include <stdio.h>

// Class encapsulating function without arguments
class Caller0
{
void (* m_Func )( void );

public:

Caller0( void (* Func )( void ) ) : m_Func(Func) {}

void Call0() { m_Func(); }
};

// Template for class encapsulating function with one argument
template < class T > class Caller1
{
void (* m_Func )( T );

public:

Caller1( void (* Func )( T ) ) : m_Func(Func) {}

void Call1() { m_Func( T() ); }
};

// Template for class encapsulating function with two arguments
template < class T1, class T2 > class Caller2
{
void (* m_Func )( T1, T2 );

public:

Caller2( void (* Func )( T1, T2 ) ) : m_Func(Func) {}

void Call2() { m_Func ( T1(), T2() ); }
};

// This one will be used for functions without arguments
Caller0 Invoke( void (* Func )( void ) )
{
return Caller0( Func );
}

// This one will be used for functions with one argument
template < class T > Caller1<T> Invoke( void (* Func )( T ) )
{
return Caller1<T>( Func );
}

// This one will be used for functions with two arguments
template < class T1, class T2 > Caller2<T1,T2> Invoke( void (* Func )( T1, T2 ) )
{
return Caller2<T1,T2> ( Func );
}

void Function0(void)
{
printf("Function0\n");
}

void Function1(float)
{
printf("Function1\n");
}

void Function2(int)
{
printf("Function2\n");
}

void Function3(int,float)
{
printf("Function3\n");
}

int main(int,char**)
{
Invoke( Function0 ).'''Call0'''();
Invoke( Function1 ).'''Call1'''();
Invoke( Function2 ).'''Call1'''();
Invoke( Function3 ).'''Call2'''();

Invoke( &Function0 ).'''Call0'''();
Invoke( &Function1 ).'''Call1'''();
Invoke( &Function2 ).'''Call1'''();
Invoke( &Function3 ).'''Call2'''();
return 0;
}

Code::Completion Rewrite

2008-03-16T01:23:19Z

Stevenkaras: /* Process */

== Background ==
The current Code::Completion plug-in has some flaws, and is currently development frozen.
The current plug-in lacks full support for:
# function and class templates
# default arguments in some cases
# some of the more complicated c++ mucky business

== Current Effort ==
=== Structure ===
The current C::C is a monolithic library of features, which could be de-coupled and split up for use in multiple plugins, providing extra functionality and flexibility in the future.
Therefore, I propose the C::C be broken up into the following components:

* Code::SymbolTable
** Provide a list of valid symbols in the workspace, along with relevant scope information
* Code::Completion
** Provide Auto-complete features
* Code::SymbolOutline
** Provide Symbol browser, find symbol, function jump features
* Code::Refactoring
** Provide code refactoring features
* Code::Documentation
** Provide automatic code generation features

=== Code::Completion ===
==== Purpose Statement ====
The current Code::Completion plugin is outdated, and needs a complete rewrite.
The purpose of the Code::Completion plugin is thus:

* Provide a list of likely symbols in the current scope as possible solutions to the current symbol.
* Provide function tooltips
** Parameter list
** Relevant documentation
* Provide variable tooltips
** type and modifiers
** scope
* Provide preprocessor tooltips
** replacement value of a macro
** parameter list when applicable
* Provide completion features for class constructors
* Provide completion features for initializer lists

==== Process ====
* The user requests a completion of the current symbol.
** Call CC::EventSymbolHover
*** When the mouse hovers over a symbol after a timeout
** Call CC::EventSymbolTip
*** When the user types in any of the following: . :: ->
*** When the user presses the keystroke CTRL-SPACE
** Call CC::EventCallTip
*** When the user types in any of the following: (
*** When the user presses the keystroke CTRL-SHIFT-SPACE
** Call CC::EventPreprocTip
*** When the user types in any of the following: < " when in preproc context (# at the start of the line)
* the C::C plugin determines the proper scope, when applicable (global, local, class)
* Compare the current symbol against the symbol table of proper scope.
* Provide a composite list to the user.

=== Code::SymbolTable ===
There will be 3 symbol lists:
# global namespace
# local scope
# class scope

Here's the current data proposal:

class symbol
{
string name; // name of the symbol
int id; // Id of the symbol, should be unique in the workspace
int file_id; // Id of file where the symbol has been declared
int filepos_begin; // Position where declaration of the symbol starts
int filepos_end; // Position where declaration of the symbol ends
int type; // Type of the symbol: macro / class / typedef / variable / function
flags modifiers; // Bitfield used to mark some estra properties of symbol
// like that it is static or inline
int value_type_id; // Id of symbol which represents c++ type of current symbol
// (like type of variable or type of returned value from function)
int extra_type_id; // Extra type used in some cases
list children; // List of child elements of this symbol (members in class etc)
list extra_lists[3]; // See table below
map extra_values; // int -> string map which can keep some extra data
}

class list_entry
{
int symbol_id; // ID of the symbol referenced
int storage_class; // Storage class of the symbol (private/protected/public)
}

Explanation of symbol::extra_lists[]
{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 1px solid gray;"
! type
! modifiers
! value_type_id
! extra_type
! children
! extra_lists[0]
! extra_lists[1]
! extra_lists[2]
|-

|-
| namespace
|
|
|
| declarations in namespace
|"using" namespaces
|
|
|-

|-
| class / struct / union
|
|
|
| members of class
| base classes
| template args
| friends of class
|-

|-
| variable
| extern, static, volatile, const
| type of variable
|
|
|
|
|
|-

|-
| function
| static, inline, const ...
| returned value
|
| arguments
| template arguments
|
|
|-

|-
| typedef
| pointer, array, reference, pointer_to_member
| base type
| type of class in pointer_to_member
|
|
|
|
|-

|-
| enum
|
|
|
| items in enum
|
|
|
|-

|-
| enum item
|
|
| id of enum
|
|
|
|
|-

|-
| macro
|
|
|
| macro parts
|
|
|
|-

|-
| macro part
| arg_to_string, va_args
| number of arg or -1
|
|
|
|
|
|-

|}

Comments:
* Such representation would require some extra "hidden" symbols - for example when some complex type is returned from function, extra symbol of typedef representing proper value would be required.
* Also in case of templates, typeid's should be threated in special way - negative value could mean to use template argument instead of some real type. Base types (the POD ones) should have some predefined type ids.

Questions:
* why are we storing filepos_end? Wouldn't it be much more useful to store declaration, definition info?

== More complex cases of C::C usage ==

Here we can put some more complex examples of c++ code where C::C may fail. Symbols that may be hard to find should be marked in bold

=== 1: Fetching type of operator call ===

#include <string>
using namespace std;

int main(int,char**)
{
( string("first") + "second" + "third" ) . '''c_str'''();
return 0;
}

=== 2: Template classes ===

template<typename T> class Template
{
public:
T& GetInstance() { return m_Instance; }
private:
T m_Instance;
};

class Parameter
{
public:
void PrintfText() { printf("Text"); }
};

int main(int,char**)
{
Template<Parameter> Object;
Object.GetInstance().'''PrintfText'''();
}

=== 3: Automated deduction of template arguments from passed function arguments ===

#include <stdio.h>

class Class
{
public:
void SomeFunction() { printf("SomeFunction\n"); }
};

template< class T > T& Function( T& arg )
{
return arg;
}

int main( int, char** )
{
Class f;
Function(f).'''SomeFunction'''();
return 0;
}

=== 4. Template arguments for templates ===

#include <stdio.h>

template< template<class> class InternalTemplate, typename Type > class Test
{
public:

InternalTemplate<Type> m_Member;
};

template< class T > class TestInt
{
public:

T m_IntMember;
};

class Class
{
public:

void Print() { printf("Class::Print\n"); }
};

int main( int, char** )
{
Test<TestInt,Class> Object;
Object.m_Member.'''m_IntMember'''.'''Print'''();
return 0;
}

=== 5. Partial specializations ===

#include <stdio.h>

template< class T > class Template
{
public:
void Print() { printf("Generic specialization\n"); }
};

template<> class Template<float>
{
public:
void PrintFloat() { printf("Partial specialization\n"); }
};

int main(int,char**)
{
Template<int> TInt;
TInt.'''Print'''(); // PrintFloat() should not be available here

Template<float> TFloat;
TFloat.'''PrintFloat'''(); // Print() should not be available here

return 0;
}

=== 6. Advanced template argument deduction ===

#include <stdio.h>

// Class encapsulating function without arguments
class Caller0
{
void (* m_Func )( void );

public:

Caller0( void (* Func )( void ) ) : m_Func(Func) {}

void Call0() { m_Func(); }
};

// Template for class encapsulating function with one argument
template < class T > class Caller1
{
void (* m_Func )( T );

public:

Caller1( void (* Func )( T ) ) : m_Func(Func) {}

void Call1() { m_Func( T() ); }
};

// Template for class encapsulating function with two arguments
template < class T1, class T2 > class Caller2
{
void (* m_Func )( T1, T2 );

public:

Caller2( void (* Func )( T1, T2 ) ) : m_Func(Func) {}

void Call2() { m_Func ( T1(), T2() ); }
};

// This one will be used for functions without arguments
Caller0 Invoke( void (* Func )( void ) )
{
return Caller0( Func );
}

// This one will be used for functions with one argument
template < class T > Caller1<T> Invoke( void (* Func )( T ) )
{
return Caller1<T>( Func );
}

// This one will be used for functions with two arguments
template < class T1, class T2 > Caller2<T1,T2> Invoke( void (* Func )( T1, T2 ) )
{
return Caller2<T1,T2> ( Func );
}

void Function0(void)
{
printf("Function0\n");
}

void Function1(float)
{
printf("Function1\n");
}

void Function2(int)
{
printf("Function2\n");
}

void Function3(int,float)
{
printf("Function3\n");
}

int main(int,char**)
{
Invoke( Function0 ).'''Call0'''();
Invoke( Function1 ).'''Call1'''();
Invoke( Function2 ).'''Call1'''();
Invoke( Function3 ).'''Call2'''();

Invoke( &Function0 ).'''Call0'''();
Invoke( &Function1 ).'''Call1'''();
Invoke( &Function2 ).'''Call1'''();
Invoke( &Function3 ).'''Call2'''();
return 0;
}

Code::Completion Rewrite

2008-03-16T01:22:42Z

Stevenkaras: /* Process */

== Background ==
The current Code::Completion plug-in has some flaws, and is currently development frozen.
The current plug-in lacks full support for:
# function and class templates
# default arguments in some cases
# some of the more complicated c++ mucky business

== Current Effort ==
=== Structure ===
The current C::C is a monolithic library of features, which could be de-coupled and split up for use in multiple plugins, providing extra functionality and flexibility in the future.
Therefore, I propose the C::C be broken up into the following components:

* Code::SymbolTable
** Provide a list of valid symbols in the workspace, along with relevant scope information
* Code::Completion
** Provide Auto-complete features
* Code::SymbolOutline
** Provide Symbol browser, find symbol, function jump features
* Code::Refactoring
** Provide code refactoring features
* Code::Documentation
** Provide automatic code generation features

=== Code::Completion ===
==== Purpose Statement ====
The current Code::Completion plugin is outdated, and needs a complete rewrite.
The purpose of the Code::Completion plugin is thus:

* Provide a list of likely symbols in the current scope as possible solutions to the current symbol.
* Provide function tooltips
** Parameter list
** Relevant documentation
* Provide variable tooltips
** type and modifiers
** scope
* Provide preprocessor tooltips
** replacement value of a macro
** parameter list when applicable
* Provide completion features for class constructors
* Provide completion features for initializer lists

==== Process ====
# The user requests a completion of the current symbol.
## Call CC::EventSymbolHover
### When the mouse hovers over a symbol after a timeout
## Call CC::EventSymbolTip
### When the user types in any of the following: . :: ->
### When the user presses the keystroke CTRL-SPACE
## Call CC::EventCallTip
### When the user types in any of the following: (
### When the user presses the keystroke CTRL-SHIFT-SPACE
## Call CC::EventPreprocTip
### When the user types in any of the following: < " when in preproc context (# at the start of the line)
# the C::C plugin determines the proper scope, when applicable (global, local, class)
# Compare the current symbol against the symbol table of proper scope.
# Provide a composite list to the user.

=== Code::SymbolTable ===
There will be 3 symbol lists:
# global namespace
# local scope
# class scope

Here's the current data proposal:

class symbol
{
string name; // name of the symbol
int id; // Id of the symbol, should be unique in the workspace
int file_id; // Id of file where the symbol has been declared
int filepos_begin; // Position where declaration of the symbol starts
int filepos_end; // Position where declaration of the symbol ends
int type; // Type of the symbol: macro / class / typedef / variable / function
flags modifiers; // Bitfield used to mark some estra properties of symbol
// like that it is static or inline
int value_type_id; // Id of symbol which represents c++ type of current symbol
// (like type of variable or type of returned value from function)
int extra_type_id; // Extra type used in some cases
list children; // List of child elements of this symbol (members in class etc)
list extra_lists[3]; // See table below
map extra_values; // int -> string map which can keep some extra data
}

class list_entry
{
int symbol_id; // ID of the symbol referenced
int storage_class; // Storage class of the symbol (private/protected/public)
}

Explanation of symbol::extra_lists[]
{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 1px solid gray;"
! type
! modifiers
! value_type_id
! extra_type
! children
! extra_lists[0]
! extra_lists[1]
! extra_lists[2]
|-

|-
| namespace
|
|
|
| declarations in namespace
|"using" namespaces
|
|
|-

|-
| class / struct / union
|
|
|
| members of class
| base classes
| template args
| friends of class
|-

|-
| variable
| extern, static, volatile, const
| type of variable
|
|
|
|
|
|-

|-
| function
| static, inline, const ...
| returned value
|
| arguments
| template arguments
|
|
|-

|-
| typedef
| pointer, array, reference, pointer_to_member
| base type
| type of class in pointer_to_member
|
|
|
|
|-

|-
| enum
|
|
|
| items in enum
|
|
|
|-

|-
| enum item
|
|
| id of enum
|
|
|
|
|-

|-
| macro
|
|
|
| macro parts
|
|
|
|-

|-
| macro part
| arg_to_string, va_args
| number of arg or -1
|
|
|
|
|
|-

|}

Comments:
* Such representation would require some extra "hidden" symbols - for example when some complex type is returned from function, extra symbol of typedef representing proper value would be required.
* Also in case of templates, typeid's should be threated in special way - negative value could mean to use template argument instead of some real type. Base types (the POD ones) should have some predefined type ids.

Questions:
* why are we storing filepos_end? Wouldn't it be much more useful to store declaration, definition info?

== More complex cases of C::C usage ==

Here we can put some more complex examples of c++ code where C::C may fail. Symbols that may be hard to find should be marked in bold

=== 1: Fetching type of operator call ===

#include <string>
using namespace std;

int main(int,char**)
{
( string("first") + "second" + "third" ) . '''c_str'''();
return 0;
}

=== 2: Template classes ===

template<typename T> class Template
{
public:
T& GetInstance() { return m_Instance; }
private:
T m_Instance;
};

class Parameter
{
public:
void PrintfText() { printf("Text"); }
};

int main(int,char**)
{
Template<Parameter> Object;
Object.GetInstance().'''PrintfText'''();
}

=== 3: Automated deduction of template arguments from passed function arguments ===

#include <stdio.h>

class Class
{
public:
void SomeFunction() { printf("SomeFunction\n"); }
};

template< class T > T& Function( T& arg )
{
return arg;
}

int main( int, char** )
{
Class f;
Function(f).'''SomeFunction'''();
return 0;
}

=== 4. Template arguments for templates ===

#include <stdio.h>

template< template<class> class InternalTemplate, typename Type > class Test
{
public:

InternalTemplate<Type> m_Member;
};

template< class T > class TestInt
{
public:

T m_IntMember;
};

class Class
{
public:

void Print() { printf("Class::Print\n"); }
};

int main( int, char** )
{
Test<TestInt,Class> Object;
Object.m_Member.'''m_IntMember'''.'''Print'''();
return 0;
}

=== 5. Partial specializations ===

#include <stdio.h>

template< class T > class Template
{
public:
void Print() { printf("Generic specialization\n"); }
};

template<> class Template<float>
{
public:
void PrintFloat() { printf("Partial specialization\n"); }
};

int main(int,char**)
{
Template<int> TInt;
TInt.'''Print'''(); // PrintFloat() should not be available here

Template<float> TFloat;
TFloat.'''PrintFloat'''(); // Print() should not be available here

return 0;
}

=== 6. Advanced template argument deduction ===

#include <stdio.h>

// Class encapsulating function without arguments
class Caller0
{
void (* m_Func )( void );

public:

Caller0( void (* Func )( void ) ) : m_Func(Func) {}

void Call0() { m_Func(); }
};

// Template for class encapsulating function with one argument
template < class T > class Caller1
{
void (* m_Func )( T );

public:

Caller1( void (* Func )( T ) ) : m_Func(Func) {}

void Call1() { m_Func( T() ); }
};

// Template for class encapsulating function with two arguments
template < class T1, class T2 > class Caller2
{
void (* m_Func )( T1, T2 );

public:

Caller2( void (* Func )( T1, T2 ) ) : m_Func(Func) {}

void Call2() { m_Func ( T1(), T2() ); }
};

// This one will be used for functions without arguments
Caller0 Invoke( void (* Func )( void ) )
{
return Caller0( Func );
}

// This one will be used for functions with one argument
template < class T > Caller1<T> Invoke( void (* Func )( T ) )
{
return Caller1<T>( Func );
}

// This one will be used for functions with two arguments
template < class T1, class T2 > Caller2<T1,T2> Invoke( void (* Func )( T1, T2 ) )
{
return Caller2<T1,T2> ( Func );
}

void Function0(void)
{
printf("Function0\n");
}

void Function1(float)
{
printf("Function1\n");
}

void Function2(int)
{
printf("Function2\n");
}

void Function3(int,float)
{
printf("Function3\n");
}

int main(int,char**)
{
Invoke( Function0 ).'''Call0'''();
Invoke( Function1 ).'''Call1'''();
Invoke( Function2 ).'''Call1'''();
Invoke( Function3 ).'''Call2'''();

Invoke( &Function0 ).'''Call0'''();
Invoke( &Function1 ).'''Call1'''();
Invoke( &Function2 ).'''Call1'''();
Invoke( &Function3 ).'''Call2'''();
return 0;
}

Code::Completion Rewrite

2008-03-16T01:09:07Z

Stevenkaras: /* Purpose Statement */

== Background ==
The current Code::Completion plug-in has some flaws, and is currently development frozen.
The current plug-in lacks full support for:
# function and class templates
# default arguments in some cases
# some of the more complicated c++ mucky business

== Current Effort ==
=== Structure ===
The current C::C is a monolithic library of features, which could be de-coupled and split up for use in multiple plugins, providing extra functionality and flexibility in the future.
Therefore, I propose the C::C be broken up into the following components:

* Code::SymbolTable
** Provide a list of valid symbols in the workspace, along with relevant scope information
* Code::Completion
** Provide Auto-complete features
* Code::SymbolOutline
** Provide Symbol browser, find symbol, function jump features
* Code::Refactoring
** Provide code refactoring features
* Code::Documentation
** Provide automatic code generation features

=== Code::Completion ===
==== Purpose Statement ====
The current Code::Completion plugin is outdated, and needs a complete rewrite.
The purpose of the Code::Completion plugin is thus:

* Provide a list of likely symbols in the current scope as possible solutions to the current symbol.
* Provide function tooltips
** Parameter list
** Relevant documentation
* Provide variable tooltips
** type and modifiers
** scope
* Provide preprocessor tooltips
** replacement value of a macro
** parameter list when applicable
* Provide completion features for class constructors
* Provide completion features for initializer lists

==== Process ====
# Generate a list of all valid symbols in the current scope
## Take global list from C::SymbolTable
## Add in local scope parsed on the fly
# Reduce that list to what is likely
# Show that list to the user in some fashion
# Insert the proper solution on user request
=== Code::SymbolTable ===
There will be 3 symbol lists:
# global namespace
# local scope
# class scope

Here's the current data proposal:

class symbol
{
string name; // name of the symbol
int id; // Id of the symbol, should be unique in the workspace
int file_id; // Id of file where the symbol has been declared
int filepos_begin; // Position where declaration of the symbol starts
int filepos_end; // Position where declaration of the symbol ends
int type; // Type of the symbol: macro / class / typedef / variable / function
flags modifiers; // Bitfield used to mark some estra properties of symbol
// like that it is static or inline
int value_type_id; // Id of symbol which represents c++ type of current symbol
// (like type of variable or type of returned value from function)
int extra_type_id; // Extra type used in some cases
list children; // List of child elements of this symbol (members in class etc)
list extra_lists[3]; // See table below
map extra_values; // int -> string map which can keep some extra data
}

class list_entry
{
int symbol_id; // ID of the symbol referenced
int storage_class; // Storage class of the symbol (private/protected/public)
}

Explanation of symbol::extra_lists[]
{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
|- style="background: #ececec; border: 1px solid gray;"
! type
! modifiers
! value_type_id
! extra_type
! children
! extra_lists[0]
! extra_lists[1]
! extra_lists[2]
|-

|-
| namespace
|
|
|
| declarations in namespace
|"using" namespaces
|
|
|-

|-
| class / struct / union
|
|
|
| members of class
| base classes
| template args
| friends of class
|-

|-
| variable
| extern, static, volatile, const
| type of variable
|
|
|
|
|
|-

|-
| function
| static, inline, const ...
| returned value
|
| arguments
| template arguments
|
|
|-

|-
| typedef
| pointer, array, reference, pointer_to_member
| base type
| type of class in pointer_to_member
|
|
|
|
|-

|-
| enum
|
|
|
| items in enum
|
|
|
|-

|-
| enum item
|
|
| id of enum
|
|
|
|
|-

|-
| macro
|
|
|
| macro parts
|
|
|
|-

|-
| macro part
| arg_to_string, va_args
| number of arg or -1
|
|
|
|
|
|-

|}

Comments:
* Such representation would require some extra "hidden" symbols - for example when some complex type is returned from function, extra symbol of typedef representing proper value would be required.
* Also in case of templates, typeid's should be threated in special way - negative value could mean to use template argument instead of some real type. Base types (the POD ones) should have some predefined type ids.

Questions:
* why are we storing filepos_end? Wouldn't it be much more useful to store declaration, definition info?

== More complex cases of C::C usage ==

Here we can put some more complex examples of c++ code where C::C may fail. Symbols that may be hard to find should be marked in bold

=== 1: Fetching type of operator call ===

#include <string>
using namespace std;

int main(int,char**)
{
( string("first") + "second" + "third" ) . '''c_str'''();
return 0;
}

=== 2: Template classes ===

template<typename T> class Template
{
public:
T& GetInstance() { return m_Instance; }
private:
T m_Instance;
};

class Parameter
{
public:
void PrintfText() { printf("Text"); }
};

int main(int,char**)
{
Template<Parameter> Object;
Object.GetInstance().'''PrintfText'''();
}

=== 3: Automated deduction of template arguments from passed function arguments ===

#include <stdio.h>

class Class
{
public:
void SomeFunction() { printf("SomeFunction\n"); }
};

template< class T > T& Function( T& arg )
{
return arg;
}

int main( int, char** )
{
Class f;
Function(f).'''SomeFunction'''();
return 0;
}

=== 4. Template arguments for templates ===

#include <stdio.h>

template< template<class> class InternalTemplate, typename Type > class Test
{
public:

InternalTemplate<Type> m_Member;
};

template< class T > class TestInt
{
public:

T m_IntMember;
};

class Class
{
public:

void Print() { printf("Class::Print\n"); }
};

int main( int, char** )
{
Test<TestInt,Class> Object;
Object.m_Member.'''m_IntMember'''.'''Print'''();
return 0;
}

=== 5. Partial specializations ===

#include <stdio.h>

template< class T > class Template
{
public:
void Print() { printf("Generic specialization\n"); }
};

template<> class Template<float>
{
public:
void PrintFloat() { printf("Partial specialization\n"); }
};

int main(int,char**)
{
Template<int> TInt;
TInt.'''Print'''(); // PrintFloat() should not be available here

Template<float> TFloat;
TFloat.'''PrintFloat'''(); // Print() should not be available here

return 0;
}

=== 6. Advanced template argument deduction ===

#include <stdio.h>

// Class encapsulating function without arguments
class Caller0
{
void (* m_Func )( void );

public:

Caller0( void (* Func )( void ) ) : m_Func(Func) {}

void Call0() { m_Func(); }
};

// Template for class encapsulating function with one argument
template < class T > class Caller1
{
void (* m_Func )( T );

public:

Caller1( void (* Func )( T ) ) : m_Func(Func) {}

void Call1() { m_Func( T() ); }
};

// Template for class encapsulating function with two arguments
template < class T1, class T2 > class Caller2
{
void (* m_Func )( T1, T2 );

public:

Caller2( void (* Func )( T1, T2 ) ) : m_Func(Func) {}

void Call2() { m_Func ( T1(), T2() ); }
};

// This one will be used for functions without arguments
Caller0 Invoke( void (* Func )( void ) )
{
return Caller0( Func );
}

// This one will be used for functions with one argument
template < class T > Caller1<T> Invoke( void (* Func )( T ) )
{
return Caller1<T>( Func );
}

// This one will be used for functions with two arguments
template < class T1, class T2 > Caller2<T1,T2> Invoke( void (* Func )( T1, T2 ) )
{
return Caller2<T1,T2> ( Func );
}

void Function0(void)
{
printf("Function0\n");
}

void Function1(float)
{
printf("Function1\n");
}

void Function2(int)
{
printf("Function2\n");
}

void Function3(int,float)
{
printf("Function3\n");
}

int main(int,char**)
{
Invoke( Function0 ).'''Call0'''();
Invoke( Function1 ).'''Call1'''();
Invoke( Function2 ).'''Call1'''();
Invoke( Function3 ).'''Call2'''();

Invoke( &Function0 ).'''Call0'''();
Invoke( &Function1 ).'''Call1'''();
Invoke( &Function2 ).'''Call1'''();
Invoke( &Function3 ).'''Call2'''();
return 0;
}

Code::Completion Rewrite

2008-03-11T16:09:19Z

Stevenkaras: /* Current Effort */

Code::Completion Rewrite

2008-03-11T16:07:44Z

Stevenkaras: /* Code::SymbolTable */

Code::Completion Rewrite

2008-03-11T15:44:23Z

Stevenkaras: /* Current Effort */

Code::Completion Rewrite

2008-03-11T15:14:40Z

Stevenkaras: /* Code::SymbolTable */

Code::Completion Rewrite

2008-03-11T15:10:48Z

Stevenkaras: /* More complex cases of C::C usage */

Using STLFilt with MinGW

2008-03-11T15:09:54Z

Stevenkaras: /* Code */

Welcome to the '''Sandbox''' where you can edit until your heart's content. Check out the 'edit' link at the top of this page to play around in here.

== Italic Text ==

Look at the ''italic text''.

== Bold Text ==

Look at the '''bold text'''.

== Lists ==

*Lists are easy.
**Really easy.

== Images ==

Some images....

[[Image:Chk.png]]
[[Image:Nop.png]]

== Links ==

Links to other pages, external sites. etc

Link to page in this wiki
[[Installing Code::Blocks from source]]

Link with no title
[http://www.google.com]
Link with title
[http://www.google.com The Google Search engine]

Link to category (note the initial colon)
[[:Category:Installation\Build Instructions]]

To categorize a page, remove the initial colon like this: <nowiki>[[Category:Installation\Build_Instructions]]</nowiki>

== Code ==
Code should have a space at the start of the line

Don't forget to put a space on blank lines, or the boxes get broken up.

Like this!

Using STLFilt with MinGW

2008-03-11T15:09:43Z

Stevenkaras: /* Code */

Using STLFilt with MinGW

2008-03-11T15:08:53Z

Stevenkaras: /* Code */

Using STLFilt with MinGW

2008-03-11T15:08:11Z

Stevenkaras:

Code::Completion Rewrite

2008-03-11T15:06:06Z

Stevenkaras: /* More complex cases of C::C usage */

Code::Completion Rewrite

2008-03-11T15:05:37Z

Stevenkaras: /* More complex cases of C::C usage */

Code::Completion Rewrite

2008-03-11T15:04:20Z

Stevenkaras: /* More complex cases of C::C usage */

Code::Completion Rewrite

2008-03-11T15:02:27Z

Stevenkaras: /* Current Effort */

Code Completion Rewrite

2008-03-11T04:22:11Z

Stevenkaras: Code Completion Rewrite moved to Code::Completion Rewrite: Name semantics

#REDIRECT [[Code::Completion Rewrite]]

Code::Completion Rewrite

2008-03-11T04:22:10Z

Stevenkaras: Code Completion Rewrite moved to Code::Completion Rewrite: Name semantics

Installing Code::Blocks from source on Windows

2008-03-11T03:54:44Z

Stevenkaras: /* wxWidgets */

[[Category:Installing Code::Blocks]]
[[Category:Installing Code::Blocks from source]]
== Prerequisites ==

'''Note for RC2 users'''

The older Code::Blocks RC2 does not support global compiler variables which were added after RC2 was released and is unable to read project files generated with post-RC2 versions.
To build Code::Blocks, you need a post-RC2 build, such as any of the ''nightly builds'' obtainable by [/index.php?board=20.0 searching the forum].

=== MinGW compiler ===

At the present time, Code::Blocks only compiles successfully with the MinGW compiler (or any other gcc for that matter). You will need a complete, working [[MinGW installation]].

Since November 2007 MinGW-GCC 4.2.1

=== wxWidgets ===

[http://wxwidgets.org/ wxWidgets.org]

Code::Blocks officially supports wxWidgets 2.6.3 (although any 2.6+ version probably works).<br/>
Download: [http://prdownloads.sourceforge.net/wxwindows/wxMSW-2.6.3-1.zip wxMSW-2.6.3-1.zip].

Code::Blocks uses
* since May 2007 wxWidgets 2.8.4<br/>Download: [http://prdownloads.sourceforge.net/wxwindows/wxMSW-2.8.4.zip wxMSW-2.8.4.zip]

* since November 2007 wxWidgets 2.8.6 <br/>Download: [http://prdownloads.sourceforge.net/wxwindows/wxMSW-2.8.6.zip wxMSW-2.8.6.zip]

* since 28 November 2007 wxWidgets 2.8.7 <br/>Download: [http://prdownloads.sourceforge.net/wxwindows/wxMSW-2.8.7.zip wxMSW-2.8.7.zip]

For latest infos check forum: [/index.php?topic=3299.0 Important changes to the nightly builds]

You do ''not'' need MSYS (''in fact, if you have MSYS, make sure it is not in your PATH when building wxWidgets'').

=== SVN client ===

In order to check out the Code::Blocks sources you will need a SVN client.
For convenience, it is recommended that you install [http://tortoisesvn.net/downloads TortoiseSVN] on your machine, as this is a lot more comfortable. However, if you get a bad feeling when some program is messing with your Explorer menu, then you can use the [http://subversion.tigris.org/project_packages.html svn command-line client] equally well.

It is generally a good idea to install the command-line client (and adding it to PATH) even if you use TortoiseSVN for convenience. The <tt>autorevision</tt> tool which is used during the build of Code::Blocks makes use of the <tt>svn</tt> binary if it is available. This is preferrable to the manual parsing of the entries file that is used as fallback.

Please do note that working copies checked out with the 1.4 version of Subversion are no longer compatible with earlier versions (Subversion will transparently update existing repositories).

The builtin fallback mechanism in <tt>autorevision</tt> has been updated to the new 1.4 format and will no longer work with the old format.<br>
Therefore, if you use a Subversion client from the 1.0-1.3 line, you ''must'' put the commandline tool into <tt>PATH</tt> for a successful build.<br>
If you use Subversion 1.4, then it is good practice nevertheless, but you can do without, too.

=== zip.exe ===

You'll also need a working 'zip' program.
If you have the version listed on our [https://wiki.codeblocks.org/index.php?title=Mingw#Other_developer_tools tools page], you'll be fine.

The zip program coming with cygwin will ''not'' work properly. You do ''not'' need WinZip.

Make sure the zip binary is in your PATH so the <tt>update.bat</tt> script will be able to find it (alternatively, you can edit the batch file, setting the ZIPCMD variable to something else).

The easiest way is to put zip.exe into <tt>bin</tt> inside your MinGW installation directory (that folder is normally in the path).

=== Code::Blocks sources ===

You will also (obviously) need the Code::Blocks sources.

Using ''TortoiseSVN'', make a folder where you want to store the sources, right-click on the folder, and select "SVN Checkout...".

In the top box, enter svn://svn.berlios.de/codeblocks/trunk and hit the OK button.

Using ''svn'', you have to open a command prompt ("DOS Window"). Make a folder, change directory, and run svn:

mkdir codeblocks-head
cd codeblocks-head
svn checkout svn://svn.berlios.de/codeblocks/trunk

== Building ==

=== Unicode Build ===

==== Compile wxWidgets in Unicode mode ====

After unpacking the zip file to a directory of your choice, open a cmd prompt, and navigate to the folder build/msw inside the wxWidgets folder. Use the following commands to compile wxWidgets:

set path=c:\mingw\bin;c:\mingw\mingw32\bin
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 clean
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1

This assumes your MinGW installation is in C:\mingw. Use a different path if you installed MinGW somewhere else.

You will see a lot of warning messages during compilation. Don't worry, this is normal, you are compiling wxWidgets. The build process may take 10-30 minutes, depending on your computer's speed.

''remark: If you want to use wxWidgets not only for building Code::Blocks, but also for writing wxWidgets programs, and if you want to use the debugger in those programs, you have to compile a debug build of wxWidgets as well.''
''Use the same commands as for the release build, but replace "release" by "debug".''

'''Optional:'''

To reduce the size of your wxWidgets library, you can disable features which are not used by Code::Blocks. However, you should not do this unless you know what you are doing. You have to delete the generated setup.h from lib/gcc_dll/msw/wx before building, because your changes to include/wx/msw will otherwise not be honoured.

==== Compile Code::Blocks ====

Open the project CodeBlocks.cbp. You will be prompted to define the global variable $(#wx). Enter the location where you unpacked wxWidgets.

Hit the blue gear and lean back. Compilation may take 3-5 minutes, depending on the speed of your computer.

After the compilaton has finished, copy <tt>lib\gcc_dll\wxmsw26u_gcc_custom.dll</tt> from the wxWidgets directory to the <tt>src\devel</tt> directory inside the Code::Blocks source folder (it will also work if you keep a copy of that library in your Windows folder or anywhere in your system path, but this is generally not recommended because you can get into dll hell).

Run <tt>src\update.bat</tt> (located in the root source directory). This will pack the resource files and copy libraries and plugins to their correct locations.
The stripped ("production") executable is found in <tt>output</tt> together with all libraries and data files. If you want a version with debug symbols instead (caution: huge size!), use the one found in the <tt>devel</tt> folder.<br>
Congratulations, you own a freshly built version of Code::Blocks!

For future updates, go into the Code::Blocks root directory and run <tt>svn update</tt> (or use TurtoiseSVN to the same effect).<br/>
Then open and build the project as described before (and any contrib plugins that you wish to use), and re-run <tt>src\update.bat</tt>.

==== Install Code::Blocks ====

Copy the folder output to where you want Code::Blocks to reside.

==== Compile contributed (or your own) plugins ====

The workspace file ContribPlugins.workspace contains the project files for all contributed plugins. Open that workspace and compile the plugins which you would like to use (or select "Build Workspace" from the context menu if you want them all).<br/>
When you open the contrib plugins workspace, you will be asked to define the <tt>$(#cb)</tt> global compiler variable. This is the path that contains the sdk folder normally this is codeblocks\src. The build process uses this information to place the plugins and data files into the correct place. Enter the location of the Code::Blocks sources in the same way as for the <tt>$(#wx)</tt> variable earlier.

Don't forget to run update.bat again after building the contrib plugins.

=== ANSI Build ===

<div style="background-color: #f7d9d9; border: 1px solid #000">
<div style="margin: 5px;">

==== DEPRECATION WARNING: ====
As of February 2006, the official default build for Code::Blocks is '''Unicode''' (see above). Although ANSI builds are technically possible, we discourage their use unless there is a good reason.<br/>
''Support for ANSI builds is likely to be dropped after Version 1.0 is out.''

There is hardly any good argument against using a Unicode build if your OS supports Unicode, even if you do not understand any other language than English, as a Unicode version guarantees that it will be able to work with whatever languages you may possibly encounter in the future -- at a very reasonable cost.

However, if you absolutely don't care about Unicode or if you are bound to use Windows 95, then you may want to build an ANSI version nevertheless.

</div>
</div>

==== Compile wxWidgets in ANSI mode ====

After unpacking the zip file to a directory of your choice, open a cmd prompt, and navigate to the folder build/msw inside the wxWidgets folder. Use the following commands to compile wxWidgets

set path=c:\mingw\bin;c:\mingw\mingw32\bin
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=0 clean
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=0

This assumes your MinGW installation is in C:\mingw. Use a different path if you installed MinGW somewhere else.

You will see a lot of warning messages during compilation. Don't worry, this is normal, you are compiling wxWidgets. The build process may take 10-30 minutes, depending on your computer's speed.

'''Optional:'''

To reduce the size of your wxWidgets library, you can disable features which are not used by Code::Blocks. However, you should not do this unless you know what you are doing. You have to delete the generated setup.h from lib/gcc_dll/msw/wx before building, because your changes to include/wx/msw will otherwise not be honoured.

==== Compile Code::Blocks ====

Open the project CodeBlocks.cbp. You will be prompted to define the global variable $(#wx) if you have not used it before. Enter the location where you unpacked wxWidgets.

'''Important:''' The project file is set to compile an Unicode version of Code::Blocks by default. To make an ANSI build, you have to make the following two changes to build options before compiling:
1. In the "Compiler" tab, under "#defines", remove the entry wxUSE_UNICODE.
2. Under "Custom variables", set the variable WX_SUFFIX to empty (default value: u).

Hit the blue gear and lean back. Compilation may take 3-5 minutes, depending on the speed of your computer.

After the compilaton has finished, copy wxmsw26u_gcc_custom.dll from lib\gcc_dll inside the wxWidgets directory to the devel directory inside the Code::Blocks source folder (it will also work if you keep a copy of that library in your Windows folder or anywhere in your system path, but this is generally not recommended because you can get into [http://en.wikipedia.org/wiki/DLL_hell dll hell] ).
Run update.bat (located in the root source directory). This will pack the resource files and copy libraries and plugins to their correct locations.
The location of executable is src\output in C::B tree. From here you'll not need the nighty build anymore.

One little note for svn updates and rebuilds : just go into the codeblocks root directory and do '''svn update''' (or use Turtoise svn).

Then run the src/output/codeblocks.exe, reload project, build it, reload plugins workspace, build it, quit codeblocks and re-run update.bat. You'll have an up-to-date C::B in 3 minutes !

==== Install Code::Blocks ====

Copy the folder output to where you want Code::Blocks to reside.

==== Compile contributed (or your own) plugins ====

The workspace file ContribPlugins.workspace contains the project files for all contributed plugins. Open that workspace and compile the plugins which you would like to use (or select "Build Workspace" from the context menu if you want them all). Don't forget to run update.bat again after building the contrib plugins.

Installing the latest official version of Code::Blocks on Windows

2008-03-11T03:50:55Z

Stevenkaras:

[[Category:Installing Code::Blocks]]
[[Category:Installing the latest official version of Code::Blocks]]

=== Install steps ===

# [https://www.codeblocks.org/downloads/5 Download the Code::Blocks 8.02 installer]. If you know you don't have MinGW installed, download the package which has MinGW bundled.
# Run the installer, it's a standard installer for Windows; just press Next after reading each screen.
# If you're planning installing a compiler after you've installed Code::Blocks, read the information provided in the installer.
# If you downloaded the installer which doesn't come with MinGW, you may have to configure the compiler manually (usually Code::Blocks' autodetects the compiler).

Installing the latest official version of Code::Blocks on Windows

2008-03-11T03:49:27Z

Stevenkaras: /* Install steps */

[[Category:Installing Code::Blocks]]
[[Category:Installing the latest official version of Code::Blocks]]

::''NOTE: The current official version is outdated; we recommend [[Installing Code::Blocks nightly build on Windows|using the nightly builds]].''

::'''Warning:''' Due to bug discovered in RC2, do not install the SVN plugin if you don't have the SVN versioning system installed or Code::Blocks may crash. If you already installed the plugin by accident, please '''delete svn.dll''' from the "share\codeblocks\plugins" subdirectory.

=== Install steps ===

# [https://www.codeblocks.org/downloads/5 Download the Code::Blocks 8.02 installer]. If you know you don't have MinGW installed, download the package which has MinGW bundled.
# Run the installer, it's a standard installer for Windows; just press Next after reading each screen.
# If you're planning installing a compiler after you've installed Code::Blocks, read the information provided in the installer.
# If you downloaded the installer which doesn't come with MinGW, you may have to configure the compiler manually (usually Code::Blocks' autodetects the compiler).

Code::Completion Rewrite

2008-03-11T03:16:46Z

Stevenkaras: New page: == Background == The current Code::Completion plug-in has some flaws, and is currently development frozen. The current plug-in lacks full support for: # function and class templates # defa...