I'm having problems with global variables in the project's compiler search directories. Any global variables used there get dereferenced into what they point to instead of staying as the global variable name. This is troublesome on shared projects with different development environments and having to edit the project file every update. I am using svn 6862 but believe the problem has been present for a couple of weeks now. Example:I just tested it on linux with a simple "Hello world" - project and the variables are not dereferenced, if I save the project.
Global Variable: libfoo
base: ~/code/lib/foo
include: ~/code/lib/foo/include
Then setting Project->Build Options->Search Directories->Compiler to: $(#libfoo.include) it will shortly change to ~/code/lib/foo/include
It seems to only affect the project's overall search directories, and only in the Compiler category. Individual build targets are unaffected.
I'm having problems with global variables in the project's compiler search directories. Any global variables used there get dereferenced into what they point to instead of staying as the global variable name. This is troublesome on shared projects with different development environments and having to edit the project file every update. I am using svn 6862 but believe the problem has been present for a couple of weeks now. Example:
Global Variable: libfoo
base: ~/code/lib/foo
include: ~/code/lib/foo/include
Then setting Project->Build Options->Search Directories->Compiler to: $(#libfoo.include) it will shortly change to ~/code/lib/foo/include
It seems to only affect the project's overall search directories, and only in the Compiler category. Individual build targets are unaffected.
Yes. I have this problem too, as I have reported before atAccidentally I found that I have this problem (thanks to svn :)), too.
http://forums.codeblocks.org/index.php/topic,13639.msg92113.html#msg92113 (http://forums.codeblocks.org/index.php/topic,13639.msg92113.html#msg92113)
- <Add directory="$(#unittest_pp.include)" />
+ <Add directory="/home/obfuscated/projects/unittest-cpp/UnitTest++/src" />
I still ca not reproduce it here on debian with latest trunk and latest debugger-branch.Yes. I have this problem too, as I have reported before atAccidentally I found that I have this problem (thanks to svn :)), too.
http://forums.codeblocks.org/index.php/topic,13639.msg92113.html#msg92113 (http://forums.codeblocks.org/index.php/topic,13639.msg92113.html#msg92113)CodeI'm running dbg branch r6864 on gentoo linux 64bit.- <Add directory="$(#unittest_pp.include)" />
+ <Add directory="/home/obfuscated/projects/unittest-cpp/UnitTest++/src" />
I'm not sure what is causing it... But I think, that I've not edited the changed project.
Edit: I remembered that I've added some files with 'Ctrl + Shift + N', then clicking on the add to project button
Probably the broken case is very special, because this is not happening all the time for me.Still not reproducible.
I've a workspace with many projects (4).
Jens, have you tried with a project in a workspace?
For the record: I recall I had this effect at least once, too. However, I thought it was my fault - but in fact that's exactly what happened.
Unfortunately I cannot reproduce, too. :-(
Anybody with a sample project / step-by-step instructions please step forward!
//BUGBUG
wxWidgets wizard fails when using "Cygwin GCC" compiler after the "library settings" step. And on the next step too.
I found a bug in the code completion. a minimal example is found below.It does not crash her (debian 64-bit, latest trunk, no cc modifications).
I want to write fooIter->length();
However after writing fooIter->l the program crashes without an error message.
#include <iostream>
#include <vector>
using namespace std;
int main()
{
vector<string> fooArray;
vector<string>::iterator fooIter;
fooIter=fooArray.begin();
fooIter->
return 0;
}
Bug report: If you have a project with different targets, using different compilers for different platform targets, then Code::Blocks crashes on Linux if you mention a non-existent default compiler (msvc8) outside the target descriptions. This used to not crash, so I have a few of these cases....
Confirmed and fixed in trunk (svn r6898).
Yes. I have this problem too, as I have reported before atAccidentally I found that I have this problem (thanks to svn :)), too.
http://forums.codeblocks.org/index.php/topic,13639.msg92113.html#msg92113 (http://forums.codeblocks.org/index.php/topic,13639.msg92113.html#msg92113)CodeI'm running dbg branch r6864 on gentoo linux 64bit.- <Add directory="$(#unittest_pp.include)" />
+ <Add directory="/home/obfuscated/projects/unittest-cpp/UnitTest++/src" />
I'm not sure what is causing it... But I think, that I've not edited the changed project.
Edit: I remembered that I've added some files with 'Ctrl + Shift + N', then clicking on the add to project button
Index: src/plugins/codecompletion/codecompletion.cpp
===================================================================
--- src/plugins/codecompletion/codecompletion.cpp (revision 6942)
+++ src/plugins/codecompletion/codecompletion.cpp (working copy)
@@ -1183,8 +1183,9 @@
{
for (size_t i = 0; i < targets.GetCount(); ++i)
{
- Manager::Get()->GetMacrosManager()->ReplaceMacros(targets[i]);
- wxFileName fn(targets[i], wxEmptyString);
+ wxString includePath = targets[i];
+ Manager::Get()->GetMacrosManager()->ReplaceMacros(includePath);
+ wxFileName fn(includePath, wxEmptyString);
if (fn.IsRelative())
{
const wxArrayString oldDirs = fn.GetDirs();
Index: src/sdk/uservarmanager.cpp
===================================================================
--- src/sdk/uservarmanager.cpp (revision 6942)
+++ src/sdk/uservarmanager.cpp (working copy)
@@ -611,6 +611,9 @@
wxArrayString sets = cfg->EnumerateSubPaths(cSets);
wxArrayString vars = cfg->EnumerateSubPaths(cSets + currentSet + _T("/"));
+ sets.Sort();
+ vars.Sort();
+
selSet->Clear();
selSet->Append(sets);
selVar->Clear();
1. Close C::B if it is openDammed! You made it. That was really annoying for me, too.
2. Double click on a project in explorer/total commander
3. Open a .cpp file and type #include "|<- press ctrl + space
4. Open the build options and you have your global vars broken....
The reason this breaks is because wxArrayString::operator[] is declared like this:
wxString& operator[](size_t nIndex) const { return Item(nIndex); }
What were they thinking :(
The references returned by Item, Last or operator[] are not constant, so the array elements may be modified in place like this
array.Last().MakeUpper();
p.p.s. I'm talking to the wx guys about this... and until this problem is fixed I advise anyone to not use wxArrayString and to check all the code using it, because there is a chance you have hidden bugs in your code...
(00:33:31) heinz: obfuscated: it's a balance between making it harder to shoot yourself in the foot and actually saving bytes and cycles.:shock: :? :x
Use it, but read (and understand) the documentation (as always) !!Yeah, yeah, no one reads the docs for such things...
The wx guys think the same:Why is the API broken ?Quote(00:33:31) heinz: obfuscated: it's a balance between making it harder to shoot yourself in the foot and actually saving bytes and cycles.:shock: :? :x
But the API is broken (in my opinion) and it is really surprising way to do it, no matter if they are proud that they've save 3 bytes + 3 cycles.Use it, but read (and understand) the documentation (as always) !!Yeah, yeah, no one reads the docs for such things...
And if operator[] would not change target[ i ] (in our case), the whole code in cc would not make any sense !!If you get a const object you expect that you can modify its get and you rely on the compiler to stop you from doing stupid things.
If you get a const object you expect that you can modify [...]This is true, but I have to agree with Jens: As you know declaring a member function as const tells the compiler only, that the member function will not modify the internal object's data which does not happen, indeed. So internally it's not modified thus it's externally const which is correct. So it's really our fault if we modify the reference externally. The only feasible "solution" for wxWidgets would be to add another method that returns a const wxString...
The problem with this method is that it breaks this rule: http://www.faqs.org/docs/artu/ch11s01.htmlYou have a const literally for everything. I've learned the meaning of const once (during studies) as the following:
That is why I've said 'the API is broken'.
const int* const my_method(const int* const&) const;According to this the const only tells you "wxArrayString does not modify it's internal members when you use the operator method []". This is true, even in out case. If we modify the reference we get that this has nothing to do with it anymore, as the call to the operator is done, so the validity of the const rule.
- the var pointed to by the returned ptr won't be changable
- the returned ptr itself won't be changable
- the var pointed to by the given ptr won't be changable (by the method)
- the given ptr itself won't be changable (by the method)
- the object the method belongs to won't be changed (during method call)
Let the wx guys decide if/how to react.They would do nothing, they like it the way it is now :x :twisted:
OK, I have the steps to reproduce:
1. Close C::B if it is open
2. Double click on a project in explorer/total commander
3. Open a .cpp file and type #include "|<- press ctrl + space
4. Open the build options and you have your global vars broken....
The next one :)
If the patch has been commited, you could compile CB to get this bug out ?Should work.