Author Topic: My issues with C::B (for real now :)  (Read 7506 times)

Offline oZZ

  • Multiple posting newcomer
  • *
  • Posts: 30
My issues with C::B (for real now :)
« on: October 13, 2006, 03:52:08 pm »
I've been using C::B for almost two weeks now after coming from Eclipse CDT.  C::B is easily my favourite IDE, and you guys have done an amazing job!  I'm listing some improvements that I think will make C::B even better.  Some of these are bugs that may (most likely) or may not be known about already.

1. Symbol browser loses all symbols occasionally.  To fix it I delete the application data folder, but I'm able to save the preference file, and restore it after C::B generates a new app data folder.

2. "export makefile" is greyed out?

3. Symbol search is disabled (obviously known about)

4. Symbol view can't sort by type.  Being able to view only methods while in "this file's view" would be really nice.

5. Code complete should show types, (and names if defined in the header) of arguments to calling functions.  ie: someObj->fun( <- at this point show above the cursor: "(int some_arg_name, char *whatever)" just like Visual Studio.

6. when closing a window (ctrl-w) it should bring you to the window you last had open, not the previous one in the window list.

7. when you change a header file and a source file and recompile it checks the header file for syntactic accuracy, but not the source file before it recompiles the dependant sources.  This means if the source file has an error that requires modification of the header then you have to recompile all files up to the source file.  This wastes *A LOT* of time.  Ideally I think it should check the header, compile the source, then if no errors, recompile everything.

8. Stack trace is incomplete on debugger.  It shows the exact line of a crash, however it only shows the first 3-4 functions in the stack trace.  Eclipse CDT with the *EXACT* same gdb shows much more information in the stack trace.

This is a list of bad things about C::B, I don't think I could possibly type a list of all the things I love about C:B because it would take too long.  Keep up the amazing work, and I hope some of these things are being looked at!

-Shawn

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: My issues with C::B (for real now :)
« Reply #1 on: October 13, 2006, 04:08:51 pm »
Quote
1. Symbol browser loses all symbols occasionally.  To fix it I delete the application data folder, but I'm able to save the preference file, and restore it after C::B generates a new app data folder.

Symbols browser needs nothing from the data folder...?

Quote
2. "export makefile" is greyed out?

Yes, this option is not available at the moment.

Quote
3. Symbol search is disabled (obviously known about)

Correct.

Quote
4. Symbol view can't sort by type.  Being able to view only methods while in "this file's view" would be really nice.

File a feature request if you like. I trust you 've seen the code-completion toolbar (yes, a misnomer, I know)?

Quote
5. Code complete should show types, (and names if defined in the header) of arguments to calling functions.  ie: someObj->fun( <- at this point show above the cursor: "(int some_arg_name, char *whatever)" just like Visual Studio.

Usually, when I see "just like your_fav_other_ide" in a sentence I close the firefox tab :).
This functionality is implemented already. It could be that in some cases it won't work but the same goes for code-completion as a whole. It's working correctly 95+% of the time and that's good enough based on my original goals.

Quote
6. when closing a window (ctrl-w) it should bring you to the window you last had open, not the previous one in the window list.

Just yesterday, we updated the notebook control and allows tabbing between the open files the way you said. Closing is not following this principle though. But since Eran, the author of that control, is a frequent visitor here, I guess he 'll like this idea and possibly implement it.

Quote
7. when you change a header file and a source file and recompile it checks the header file for syntactic accuracy, but not the source file before it recompiles the dependant sources.

No such check is made. When you hit "Build" the build process starts. Each file is compiled when its time comes.
If you want to verify that your changes are not build-breakers, hit Ctrl-Shift-F9 ("Compile file") first and then hit "Build". There are plans to add a "Check syntax" option but it's obviously not implemented yet.

Quote
8. Stack trace is incomplete on debugger.  It shows the exact line of a crash, however it only shows the first 3-4 functions in the stack trace.  Eclipse CDT with the *EXACT* same gdb shows much more information in the stack trace.

I 've heard this before and I don't know what to make of it... Really, we only output what gdb prints. The only reason I can think of for this to fail, is if one of the regular expressions misses some lines. Do us a favour and give more info when this happens again to you:
  • Enable the debugger's *debug* log in the options.
  • When you notice that the backtrace is missing lines (check the first column "Nr." and look for discrepancies), turn to the debugger's debug log and copy/paste its output in a post here so I can have a look.


Yiannis.
Be patient!
This bug will be fixed soon...

Offline Belgabor

  • Multiple posting newcomer
  • *
  • Posts: 91
Re: My issues with C::B (for real now :)
« Reply #2 on: October 13, 2006, 04:25:51 pm »

Usually, when I see "just like your_fav_other_ide" in a sentence I close the firefox tab :).
This functionality is implemented already. It could be that in some cases it won't work but the same goes for code-completion as a whole. It's working correctly 95+% of the time and that's good enough based on my original goals.


This also bothered me. Mainly because I've seen it work sometimes and sometimes not (success rate for me was way below 95%).
So I did a short test and I think I stumbled across a bug. It seems to work pretty reliably if you use code completion to complete the function name. If you type it out yourself, it pretty reliably DOESN'T work.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5193
Re: My issues with C::B (for real now :)
« Reply #3 on: October 13, 2006, 04:30:47 pm »

Usually, when I see "just like your_fav_other_ide" in a sentence I close the firefox tab :).
This functionality is implemented already. It could be that in some cases it won't work but the same goes for code-completion as a whole. It's working correctly 95+% of the time and that's good enough based on my original goals.


This also bothered me. Mainly because I've seen it work sometimes and sometimes not (success rate for me was way below 95%).
So I did a short test and I think I stumbled across a bug. It seems to work pretty reliably if you use code completion to complete the function name. If you type it out yourself, it pretty reliably DOESN'T work.

if possible try to provide mini projects or source files where things are reproducable

Offline Belgabor

  • Multiple posting newcomer
  • *
  • Posts: 91
Re: My issues with C::B (for real now :)
« Reply #4 on: October 13, 2006, 04:37:41 pm »
Very Easy:
Code: [Select]
#include <string.h>

void test() {

}
Go into the function, type "memcpy(" -> nothing shows up.
Go into the function, type "memc", select "memcpy" from the list, type "(" -> parameters show up.

Edit: ok, not very easy :( seems to work in a new project
Edit2: I'm currently unable to work this out as the assertion error (I think it was mentioned in the 11th Oct. nightly thread) keeps popping  up. But now the error shows up again as described in a fresh project with one cpp file filled as above (corrected).
« Last Edit: October 13, 2006, 04:45:23 pm by Belgabor »

Offline bigbug

  • Multiple posting newcomer
  • *
  • Posts: 39
Re: My issues with C::B (for real now :)
« Reply #5 on: October 13, 2006, 04:50:19 pm »
Quote from: Belgabor
Go into the function, type "memcpy(" -> nothing shows up.
Yes, in this case, you have to press Ctrl+Shift+Space to get the call tip. But Ctrl+Shift+Space doesn't work, if you've already closed the parentheses.

Offline oZZ

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: My issues with C::B (for real now :)
« Reply #6 on: October 13, 2006, 04:55:27 pm »
Symbols browser needs nothing from the data folder...?

I know it doesn't, but I think the process of regenerating it fixes the bug.  I can't really explain it more than that, but I've observed this at least three times.

Offline Belgabor

  • Multiple posting newcomer
  • *
  • Posts: 91
Re: My issues with C::B (for real now :)
« Reply #7 on: October 13, 2006, 05:02:41 pm »
Quote from: Belgabor
Go into the function, type "memcpy(" -> nothing shows up.
Yes, in this case, you have to press Ctrl+Shift+Space to get the call tip. But Ctrl+Shift+Space doesn't work, if you've already closed the parentheses.
Indeed, you're right. But I still don't get why it behaves differently, as you have to type the '(' yourself in both cases...

Offline oZZ

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: My issues with C::B (for real now :)
« Reply #8 on: October 13, 2006, 05:06:31 pm »
Oh, one more thing I forgot to add to my list ;)

A maximize window button that makes the code window take the full C::B window.  The text zoom is really nice, but having code take up the whole window would be a great addition I think.  In Eclipse ctrl + numkey enter toggles the maximization of a window.

(edit)...and another =)

Can't easily generate files in a particular folder.  Should be able to right click folder and go "new file" and choose C++ header/source or class or other possible options, (especially when viewing in filesytem tree mode).  Right now I've found the most efficient way to do it is to make new files in windows explorer then import them.

Also I'm trying out the debugger right now with a simple example (deleting something twice) through 10 function calls, then I'll try recursion and see what it does.
« Last Edit: October 13, 2006, 05:15:42 pm by oZZ »

Offline oZZ

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: My issues with C::B (for real now :)
« Reply #9 on: October 13, 2006, 05:21:11 pm »
Ah ha!

I did a quick test using my existing project and the debugger's stack trace in the log is more complete than the window.

Here's the debug log:
#0  0x0b69f4a1 in ?? ()
#1  0x0040216a in Entity::~Entity() (this=0xb69f718) at Framework/Bases/Entity.cc:86
#2  0x0057cd39 in Menu::~Menu() (this=0xb69f718) at Framework/Menus/Menu.cc:23
#3  0x00574cc9 in ConfigMenu::~ConfigMenu() (this=0xb69f718) at Framework/Menus/ConfigMenu.cc:2409
#4  0x0053d090 in EntityManager::process() (this=0xb60c7b0) at Framework/Managers/System/EntityManager.cc:217
#5  0x005bfbe1 in Rainbow::mainLoop() (this=0xb5f36f8) at Game/Bases/Rainbow.cc:111
#6  0x0060a6e9 in SDL_main (argc=1, argv=0x22fe60) at Game/main.cc:60
#7  0x0060d940 in console_main (argc=1, argv=0x22fe60) at win32/SDL_win32_main.c:249
#8  0x0060db05 in WinMain (hInst=0x400000, hPrev=0x0, szCmdLine=0x251f23 "", sw=10) at win32/SDL_win32_main.c:361
#9  0x0060d43a in main ()

The window shows NR: 0, 6, 7, 8, 9.
Numbers 1, 2, 3, 4 and 5 are missed. The only thing those lines seem to have in common is the argument after the function name is this=<something>...

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: My issues with C::B (for real now :)
« Reply #10 on: October 13, 2006, 05:22:06 pm »
Quote
A maximize window button that makes the code window take the full C::B window.  The text zoom is really nice, but having code take up the whole window would be a great addition I think.  In Eclipse ctrl + numkey enter toggles the maximization of a window.

View->Fullscreen
Be patient!
This bug will be fixed soon...

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: My issues with C::B (for real now :)
« Reply #11 on: October 13, 2006, 05:24:10 pm »
Quote
I did a quick test using my existing project and the debugger's stack trace in the log is more complete than the window.

Thanks for this, indeed it will probably give me some clues. Of course it would be better if you could provide a test project that exhibits this behaviour, but hopefully I can make something out of what you already posted.
Be patient!
This bug will be fixed soon...

Offline oZZ

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: My issues with C::B (for real now :)
« Reply #12 on: October 13, 2006, 05:24:26 pm »
Quote
A maximize window button that makes the code window take the full C::B window.  The text zoom is really nice, but having code take up the whole window would be a great addition I think.  In Eclipse ctrl + numkey enter toggles the maximization of a window.

View->Fullscreen

That just makes the entire app take the full screen.  I mean make the code window take the full window of the C::B window.

Offline oZZ

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: My issues with C::B (for real now :)
« Reply #13 on: October 13, 2006, 05:43:13 pm »
Here's a program that loses info on backtrace:
Code: [Select]
#include <iostream>
#include <vector>
struct three
{
three() { f_vec.resize(200); }
int a, b, c, d, e, f, g;
float h, i, j, k, l,  m, n;
std::vector<float>f_vec;
};

struct one
{
one() { p = new int; *p = 5; t = new three;}
~one() { delete p; delete t; t = 0; delete t; t->a = *p; }
int *p;
three *t;
};

struct two
{
two() { o = new one; }
~two() { delete o; }
one *o;
};

void f()
{
two *t = new two;
std::cout << *(t->o->p) << std::endl;
delete t;
}

int main()
{
f();
return 0;
}

The debug log shows:
#0  0x00410bfc in one::~one() (this=0x3d2570) at main.cpp:14
#1  0x00410cd3 in two::~two() (this=0x3d24d8) at main.cpp:22
#2  0x0040146e in f() () at main.cpp:30
#3  0x004014bb in main () at main.cpp:35

The backtrace window shows only Nr = 3.

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: My issues with C::B (for real now :)
« Reply #14 on: October 13, 2006, 05:55:17 pm »
Ah, thanks. Obviously the regular expression can't handle two sets of parentheses. I 'll fix it real soon.
Be patient!
This bug will be fixed soon...

Offline oZZ

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: My issues with C::B (for real now :)
« Reply #15 on: October 13, 2006, 05:58:43 pm »
Ah, thanks. Obviously the regular expression can't handle two sets of parentheses. I 'll fix it real soon.

Excellent, thanks ;)

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: My issues with C::B (for real now :)
« Reply #16 on: October 13, 2006, 06:12:24 pm »
As an update, this only happens with gdb 5.2.
gdb 6.3 doesn't have this problem. My bad that I didn't ask you for your debugger version.
Be patient!
This bug will be fixed soon...

Offline oZZ

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: My issues with C::B (for real now :)
« Reply #17 on: October 13, 2006, 06:41:40 pm »
Ah, I shoulda mentioned that I'm running an ancient gdb and gcc.  I'm going to be upgrading next month anyway.

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: My issues with C::B (for real now :)
« Reply #18 on: October 13, 2006, 10:54:09 pm »
Fixed in SVN.
Be patient!
This bug will be fixed soon...