Author Topic: The 27 November 2010 build (6863) is out.  (Read 36811 times)

Online killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5149
The 27 November 2010 build (6863) is out.
« on: November 27, 2010, 02:40:28 pm »
Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works.

A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2810_gcc441.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc441.7z

The 27 November 2010 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20101127_rev6863_win32.7z
  - Linux :
   none

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:



    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 27 November 2010 build (6863) is out.
    « Reply #1 on: November 27, 2010, 03:27:12 pm »
    Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my repo.

    buub0nik

    • Guest
    Re: The 27 November 2010 build (6863) is out.
    « Reply #2 on: December 01, 2010, 08:24:12 pm »
    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.

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 27 November 2010 build (6863) is out.
    « Reply #3 on: December 01, 2010, 10:57:17 pm »
    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.
    I just tested it on linux with a simple "Hello world" - project and the variables are not dereferenced, if I save the project.

    I attach the project-file.

    Offline ahui886

    • Multiple posting newcomer
    • *
    • Posts: 29
    Re: The 27 November 2010 build (6863) is out.
    « Reply #4 on: December 02, 2010, 04:00:22 am »
    thanks

    Offline xawari

    • Multiple posting newcomer
    • *
    • Posts: 36
    • programming, usability ctrl
      • welcome to reality
    Re: The 27 November 2010 build (6863) is out.
    « Reply #5 on: December 03, 2010, 12:00:53 pm »
    Still crashes when I try to reorder/customize some toolbars (since september, AFAIR).
    Tested on TWO separate mahines with Windows 5.2 (2003 Enterprise and 2003 Enterprise R2) sp2, 32 bit. (I redownloaded all DLLs, but still no luck).
    ┌──────────────────────────────────────────────────────╖
    in another thousand years we'll be machines or gods█
    ╘══════════════════════════════════════════════════════╝

    Offline cacb

    • Regular
    • ***
    • Posts: 389
    Re: The 27 November 2010 build (6863) is out.
    « Reply #6 on: December 03, 2010, 10:04:02 pm »
    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 at
    http://forums.codeblocks.org/index.php/topic,13639.msg92113.html#msg92113


    stefanos_

    • Guest
    Re: The 27 November 2010 build (6863) is out.
    « Reply #7 on: December 04, 2010, 10:34:05 am »
    Current issue - Hot keys

    When I create a new project and I press ctrl-shift-N to create a new source file, "yes / no" window pops up and as soon as I press 'Y' key (which is equals to alt-Y) or the space bar, IDE instantly crashes and I have to terminate IDE's process through task manager. I have searched Code::Blocks's source directory for a crash report and for a weird reason it does not contain one.

    I cannot re-produce the bug neither with the current project nor with a newly created one, but it does happened when I occasionally create a new empty project. Please note that the current issue first appeared on my system with the release of revision 6800 and afterwards.

    System Specs:

    OS: Windows XP SP3
    Compiler: TDM's GCC: 4.5.0
    svn: 6870

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11716
      • Travis build status
    Re: The 27 November 2010 build (6863) is out.
    « Reply #8 on: December 05, 2010, 04:52:01 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 :)), too.

    Code: [Select]
    -                       <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

    « Last Edit: December 05, 2010, 04:53:59 pm by oBFusCATed »
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 27 November 2010 build (6863) is out.
    « Reply #9 on: December 05, 2010, 05:28:50 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 :)), too.

    Code: [Select]
    -                       <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


    I still ca not reproduce it here on debian with latest trunk and latest debugger-branch.

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11716
      • Travis build status
    Re: The 27 November 2010 build (6863) is out.
    « Reply #10 on: December 05, 2010, 05:57:49 pm »
    Probably the broken case is very special, because this is not happening all the time for me.

    I've a workspace with many projects (4).
    Jens, have you tried with a project in a workspace?
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 27 November 2010 build (6863) is out.
    « Reply #11 on: December 05, 2010, 06:14:13 pm »
    Probably the broken case is very special, because this is not happening all the time for me.

    I've a workspace with many projects (4).
    Jens, have you tried with a project in a workspace?
    Still not reproducible.

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 27 November 2010 build (6863) is out.
    « Reply #12 on: December 05, 2010, 07:42:05 pm »
    If anyone can provide a sample workspace/project, where it happesn I would like to test it.

    Offline MortenMacFly

    • Administrator
    • Lives here!
    • *****
    • Posts: 9489
    Re: The 27 November 2010 build (6863) is out.
    « Reply #13 on: December 05, 2010, 09:11:18 pm »
    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!
    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

    Offline cacb

    • Regular
    • ***
    • Posts: 389
    Re: The 27 November 2010 build (6863) is out.
    « Reply #14 on: December 06, 2010, 10:33:53 pm »
    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!

    I don't have a description good enough to guarantee the problem being reproducible. But a while ago I was using 2 Win XP machines with different setups and carrying a workspace+project back and forth on a memory stick (always taking complete copies). The problem very consistently showed itself when returning to one of the 2 machines.

    Later, I have been using a Bazaar branch (on the same memory stick) instead of taking full copies, and the problem seems to have gone away (or become even rarer), even though I am using the same version of C:B (6840) and wxWidgets (2.8.11).

    Perhaps a clue is that my .bzrignore file excludes

    .layout
    .depend
    .cscope_file_list

    ?



    Offline xawari

    • Multiple posting newcomer
    • *
    • Posts: 36
    • programming, usability ctrl
      • welcome to reality
    BUGREPORT
    « 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.
    ┌──────────────────────────────────────────────────────╖
    in another thousand years we'll be machines or gods█
    ╘══════════════════════════════════════════════════════╝

    Offline Biplab

    • Developer
    • Lives here!
    • *****
    • Posts: 1874
      • Biplab's Blog
    Re: BUGREPORT
    « 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.
    Be a part of the solution, not a part of the problem.

    wodraq

    • Guest
    Re: The 27 November 2010 build (6863) is out.
    « 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;
    }

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 27 November 2010 build (6863) is out.
    « 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).

    Offline cacb

    • Regular
    • ***
    • Posts: 389
    Re: The 27 November 2010 build (6863) is out.
    « 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  8) 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 ...

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 27 November 2010 build (6863) is out.
    « 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).

    Offline cacb

    • Regular
    • ***
    • Posts: 389
    Re: The 27 November 2010 build (6863) is out.
    « Reply #21 on: December 17, 2010, 06:34:13 pm »
    Confirmed and fixed in trunk (svn r6898).

    Many thanks  :D !

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11716
      • Travis build status
    Re: The 27 November 2010 build (6863) is out.
    « 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 :)), too.

    Code: [Select]
    -                       <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: [Select]
    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 :(

    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...
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline MortenMacFly

    • Administrator
    • Lives here!
    • *****
    • Posts: 9489
    Re: The 27 November 2010 build (6863) is out.
    « 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! :D
    « Last Edit: February 02, 2011, 06:46:12 am by MortenMacFly »
    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

    Online killerbot

    • Administrator
    • Lives here!
    • *****
    • Posts: 5149
    Re: The 27 November 2010 build (6863) is out.
    « Reply #24 on: February 02, 2011, 07:41:48 am »
    while you are at it, could you provide it too on the debugger branch ?

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 27 November 2010 build (6863) is out.
    « 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 :(

    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 !

    Quote from: http://docs.wxwidgets.org/stable/wx_wxarraystring.html#wxarraystring
    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) !!

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11716
      • Travis build status
    Re: The 27 November 2010 build (6863) is out.
    « 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 »
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 27 November 2010 build (6863) is out.
    « 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 !!

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11716
      • Travis build status
    Re: The 27 November 2010 build (6863) is out.
    « 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.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline MortenMacFly

    • Administrator
    • Lives here!
    • *****
    • Posts: 9489
    Re: The 27 November 2010 build (6863) is out.
    « 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...
    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

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11716
      • Travis build status
    Re: The 27 November 2010 build (6863) is out.
    « Reply #30 on: February 02, 2011, 11:06:32 am »
    The problem with this method is that it breaks this rule: http://www.faqs.org/docs/artu/ch11s01.html
    That is why I've said 'the API is broken'.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline AndyJ

    • Multiple posting newcomer
    • *
    • Posts: 11
    Re: The 27 November 2010 build (6863) is out.
    « Reply #31 on: February 02, 2011, 02:21:30 pm »
    For the last few nightly releases I've found that starting CB and dragging a workspace file onto it seems to result in CB hanging most of the time. I then have to manually kill it. This is on Win XP. Has anyone else experienced this, or is it something specific to my computer?

    Thanks for the great work.

    Offline MortenMacFly

    • Administrator
    • Lives here!
    • *****
    • Posts: 9489
    Re: The 27 November 2010 build (6863) is out.
    « Reply #32 on: February 02, 2011, 02:27:35 pm »
    The problem with this method is that it breaks this rule: http://www.faqs.org/docs/artu/ch11s01.html
    That is why I've said 'the API is broken'.
    You have a const literally for everything. I've learned the meaning of const once (during studies) as the following:
    Quote
     const int* const my_method(const int* const&) const;
      - 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)
    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.

    Anyway - it's getting quite philosophic. I think the good thing is simply that you found that bug. Let the wx guys decide if/how to react. Having the knowledge in mind we know now what we shouldn't do next time... ;-)
    « Last Edit: February 02, 2011, 02:31:49 pm by MortenMacFly »
    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

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11716
      • Travis build status
    Re: The 27 November 2010 build (6863) is out.
    « Reply #33 on: February 02, 2011, 02:32:26 pm »
    Let the wx guys decide if/how to react.
    They would do nothing, they like it the way it is now :x :twisted:
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline cacb

    • Regular
    • ***
    • Posts: 389
    Re: The 27 November 2010 build (6863) is out.
    « Reply #34 on: February 05, 2011, 12:08:27 am »

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


    Great!! Sounds like you have found it. This has been one of my biggest issues with C::B lately, it has caused me a lot of frustration. If this is now solved, I am really happy  :D

    So which is the first nightly with this bug fixed? I am going to install that ASAP!

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 11716
      • Travis build status
    Re: The 27 November 2010 build (6863) is out.
    « Reply #35 on: February 05, 2011, 08:04:08 am »
    The next one :)
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline cacb

    • Regular
    • ***
    • Posts: 389
    Re: The 27 November 2010 build (6863) is out.
    « Reply #36 on: February 05, 2011, 02:35:26 pm »
    The next one :)

    Ok, as this bug was rather annoying for several people, I hope that means "very soon"  :lol:

    Offline Folco

    • Regular
    • ***
    • Posts: 343
      • Folco's blog (68k lover)
    Re: The 27 November 2010 build (6863) is out.
    « Reply #37 on: February 05, 2011, 02:43:20 pm »
    If the patch has been commited, you could compile CB to get this bug out ?
    Kernel Extremist - PedroM power

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 27 November 2010 build (6863) is out.
    « Reply #38 on: February 05, 2011, 03:09:18 pm »
    If the patch has been commited, you could compile CB to get this bug out ?
    Should work.
    If you use my repo (debian): I just finished compiling the latest trunk.