Code::Blocks
October 30, 2014, 07:11:54 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: The new Release 13.12 is out! You can download binaries for windows, mac and many major linux distros from  http://www.codeblocks.org/downloads/26 .
 
   Home   Help Search Login Register  :: WebsiteWiki  
Pages: 1 [2] 3  All   Go Down
  Send this topic  |  Print  
Author Topic: The 27 November 2010 build (6863) is out.  (Read 21553 times)
xawari
Advanced newcomer
*
Offline Offline

Posts: 31


programming, usability ctrl


WWW
« Reply #15 on: December 10, 2010, 05:02:54 pm »

//BUGBUG
wxWidgets wizard fails when using "Cygwin GCC" compiler after the "library settings" step. And on the next step too.
Logged

┌──────────────────────────────────────────────────────╖
in another thousand years we'll be machines or gods█
╘══════════════════════════════════════════════════════╝
Biplab
Developer
Lives here!
*****
Offline Offline

Posts: 1853


WWW
« Reply #16 on: December 10, 2010, 05:32:30 pm »

//BUGBUG
wxWidgets wizard fails when using "Cygwin GCC" compiler after the "library settings" step. And on the next step too.

Cygwin GCC is not supported by wxWidgets wizard.
Logged

Be a part of the solution, not a part of the problem.
wodraq
Newcomer
*
Offline Offline

Posts: 1


« Reply #17 on: December 16, 2010, 03:12:50 pm »

I found a bug in the code completion. a minimal example is found below.

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;
}
Logged
jens
Administrator
Lives here!
*****
Offline Offline

Posts: 6632



WWW
« Reply #18 on: December 16, 2010, 03:26:21 pm »

I found a bug in the code completion. a minimal example is found below.

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;
}

It does not crash her (debian 64-bit, latest trunk, no cc modifications).
Logged

Regards

Jens  Debian - nightlies (and release) : http://apt.jenslody.de/ Fedora [18 - 20]- and CentOS/RedHat [5, 6 & 7] - nightlies : http://rpm.jenslody.de/
cacb
Regular
***
Offline Offline

Posts: 259


« Reply #19 on: December 16, 2010, 10:18:57 pm »

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....

More to the point, I have 4 build targets, using the follwing compilers
W32_Debug   : msvc8  (Windows.... obviously)
W32_Release : msvc8
UX_Debug     : gcc      (Linux)
UX_Release   : gcc

A typical project files begins like this

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_project_file>
   <FileVersion major="1" minor="6" />
   <Project>
      <Option title="cpde_csv" />
      <Option pch_mode="2" />
      <Option compiler="msvc8" />   <== causes C::B crash on Linux
      <Option virtualFolders="libcsv\;" />
      <Build>
         <Target title="W32_Debug">
      ... etc.
 


The red line must be deleted, and all is well after that. However, it is a but tough to crash C::B on this issue, especially since the project file was (at least originally) wizard generated  Cool I have workspaces with quite a few project files with this issue and it is annoying to have to open each project separately just to figure out which project file causes C::B to crash ...
Logged
jens
Administrator
Lives here!
*****
Offline Offline

Posts: 6632



WWW
« Reply #20 on: December 16, 2010, 11:06:24 pm »

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).
Logged

Regards

Jens  Debian - nightlies (and release) : http://apt.jenslody.de/ Fedora [18 - 20]- and CentOS/RedHat [5, 6 & 7] - nightlies : http://rpm.jenslody.de/
cacb
Regular
***
Offline Offline

Posts: 259


« Reply #21 on: December 17, 2010, 06:34:13 pm »

Confirmed and fixed in trunk (svn r6898).

Many thanks  Cheesy !
Logged
oBFusCATed
Developer
Lives here!
*****
Offline Offline

Posts: 7671


« Reply #22 on: February 01, 2011, 11:12:06 pm »

Yes. I have this problem too, as I have reported before at
http://forums.codeblocks.org/index.php/topic,13639.msg92113.html#msg92113
Accidentally I found that I have this problem (thanks to svn Smiley), too.

Code:
-                       <Add directory="$(#unittest_pp.include)" />
+                       <Add directory="/home/obfuscated/projects/unittest-cpp/UnitTest++/src" />
I'm running dbg branch r6864 on gentoo linux 64bit.

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



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....

Here is the patch to fix it (extremely annoying... arghhhhhh):

Code:
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();

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 Sad

p.s. I've added sorting to the choice controls in the dialog, because it is annoying, too. Feel free to commit them separately
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...
Logged

<debugger plugin maintainer>
(most of the time I ignore long posts)
MortenMacFly
Administrator
Lives here!
*****
Offline Offline

Posts: 8680



« Reply #23 on: February 02, 2011, 06:44:17 am »

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....
Dammed! You made it. That was really annoying for me, too.
So it was indeed related to CC...

I'll try and comit as soon as possible. Thanks a lot! Cheesy
« Last Edit: February 02, 2011, 06:46:12 am by MortenMacFly » Logged

Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ
killerbot
Administrator
Lives here!
*****
Offline Offline

Posts: 4822


« Reply #24 on: February 02, 2011, 07:41:48 am »

while you are at it, could you provide it too on the debugger branch ?
Logged
jens
Administrator
Lives here!
*****
Offline Offline

Posts: 6632



WWW
« Reply #25 on: February 02, 2011, 08:12:50 am »

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 Sad

It's clearly stated at the top of the wxArrayString documentation.

So I think it's not a wxWidgets errror, but an incorrect use of the operator[]-function !

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();

EDIT:
By the way, it's the same for all array classes in wxWidgets !

EDIT II:
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...

Use it, but read (and understand) the documentation (as always) !!
« Last Edit: February 02, 2011, 08:17:45 am by jens » Logged

Regards

Jens  Debian - nightlies (and release) : http://apt.jenslody.de/ Fedora [18 - 20]- and CentOS/RedHat [5, 6 & 7] - nightlies : http://rpm.jenslody.de/
oBFusCATed
Developer
Lives here!
*****
Offline Offline

Posts: 7671


« Reply #26 on: February 02, 2011, 08:23:52 am »

The wx guys think the same:
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...
« Last Edit: February 02, 2011, 08:25:38 am by oBFusCATed » Logged

<debugger plugin maintainer>
(most of the time I ignore long posts)
jens
Administrator
Lives here!
*****
Offline Offline

Posts: 6632



WWW
« Reply #27 on: February 02, 2011, 09:09:29 am »

The wx guys think the same:
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...
Why is the API broken ?
It's defined as it is, and did not change without warning.
There is no need to have a const overload of operator[], even if many API's provide it, and wxWidgets devs could do it also, without loosing anything (I think).

If a user does not read the docs, he can not blame the software !

And if operator[] would not change target[ i ] (in our case), the whole code in cc would not make any sense !!
« Last Edit: February 02, 2011, 09:13:36 am by jens » Logged

Regards

Jens  Debian - nightlies (and release) : http://apt.jenslody.de/ Fedora [18 - 20]- and CentOS/RedHat [5, 6 & 7] - nightlies : http://rpm.jenslody.de/
oBFusCATed
Developer
Lives here!
*****
Offline Offline

Posts: 7671


« Reply #28 on: February 02, 2011, 09:38:02 am »

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.
In the wxArrayString's case they allow you to do stupid things -> you can change a value you are not supposed to change.
Logged

<debugger plugin maintainer>
(most of the time I ignore long posts)
MortenMacFly
Administrator
Lives here!
*****
Offline Offline

Posts: 8680



« Reply #29 on: February 02, 2011, 10:40:17 am »

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...
Logged

Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ
Pages: 1 [2] 3  All   Go Up
  Send this topic  |  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.20 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!