User forums > Using Code::Blocks

Showing vector elements in debugger

<< < (9/11) > >>

sodev:
CodeBlocks is not a compiler, its "just" an IDE, not like Visual Studio that is both. And its not the only one like that, take a look at Eclipse, Netbeans, i dont think they even have packages that include a compiler.

Personally i never downloaded a CodeBlocks package including a compiler, i havent downloaded a CodeBlocks since years actually because i compile it myself from svn. So i dont mind if they drop these packages at all if it helps to stop codecompletion from stopping to work as soon as i type auto.

But im not a cool kid from school anymore, im not coding in cool languages that dont need uncool shit like a compiler, so i might be a little outdated how cool coding works today. Do i still need a keyboard?

nji:
I fear I'm spoiled by all my M$ years.

Maybe I too should try to get used to do what I called the amish way.
(Which wasn't meant derogative for the Amish at all. Just the opposite.)

But, as I pointed out quite often in this thread, if non-commercial development will have a chance it has to become convenient to use.
The long-year insiders don't seem to understand that.

BlueHazzard:
I honestly don't want to discuss this any future...
Just to make some points clear: I to have the opinion that codeblocks should ship as a full functional build environment with enabled debugger ecc. But this will not happen soon...

@nji
You have to understand, that codeblocks is just a IDE. Codeblocks can be used with gdb as debugger or with cdb as debugger
Codeblocks can be used with gcc compiler or with visual studio compiler or with borland compiler ecc...
Codeblocks can be used on windows, mac or linux

Codeblocks can not provide a distribution for any possible combination. Some user uses a older gdb someone uses a newer gdb, someone with c++ someone with fortran ecc.

The philosophy is not to provide a full development environment (like visual studio), but a pretty good text editor with the possibility to integrate other tools (like gdb and gcc), not provide support or help for this tools (but provide support for the integration). GDB and GCC are separate projects. And they need also other separate projects like python. Everyone does what they can and relate to the other project for support. M$ does not use this philosophy because they have everything in house (visual studio ide, visual studio compiler, M$ basic as scripting ecc.), but they are a $$$$M Dollar cooperation and not 5 developer that do this in their free time.
 Python makes a good scripting engine so gdb decides to use it in his project. Now gdb has a dependency to python, but has not the responsibility to provide a binary. On linux the resolving of this dependencys is no problem, because it uses a packet manager that resolves this problems for you. On windows you have to do this by your hand (don't blame codeblocks for this, because it is not the responsibility of codeblocks to resolve installation dependencys).

You try to use a feature that is not present in this release of CB.
I think i provided you with enough support to integrate it on your system (and i am willing to help you even more, until we have all steps together to make a nice tutorial for other people, this is the way how open source work, all cooperate and help to resolve problems). If you are not willing to resolve the dependency i feel a bit fooled for all the time i invested to help you, but this is ok, it was my decision...

Even more OT: All in all this work in resolving problems and using a old stylish IDE looks uncool for young people (i am <<30, so i count me as young). Young people use cool things like electron and java script. But the result of this cool things is bullshit. A telephony application (i look at you discord) that needs 170MB Installation, 146MB RAM and constantly 0.4% cpu on idle versus a uncool old in c and c++ written qTOX that uses 50MB RAM 0% cpu and 60MB installation, and if you use a even more uncool TOX you only need 5MB of RAM and all this uncool tools can better telephone then discord...

killerbot:
Dear all.

please keep  calm and continue debugging ;-)

You know, everyone here is right with fair remarks, but we are all wrong too.

Most important, we develop CB, aka an IDE, that means, not the compiler, not the debugger. BUT ... ( I will come to the but shortly). For convenience on windows we ship the MinGw package (which is a port of gcc, but it brings also problems), as mentioned we could switch too TDM. However it seems TDM John" is unreachable (which probably means he is busy with other things) and the TDM package is also getting outdated (it is at gcc 5.1.0), so it seems we might loose this option too (note that this is the compiler we use to build the nightly builds).

Let me first explain how I use CB, I always build it from svn, and I use it on linux (I boot up windows for 2 things, installing a game (and with some luck even play that game), and building nightlies). As such on linux I have to install the compiler, debugger myself, which is very easy to do (upgrading a compiler however is not).
I also sometimes get lost with the "enable scripts" versus do not enable the scripts but have a gdb-python pair.
And yes me too, I hardly need a debugger.
It is a pity indeed that gdb does not have such things build in (I myself can get angry on that, but I will spare you my rant).

FIRST CONCLUSION : many people have asked about this, so I think it deserves a link on our homepage to an up to date dedicated page on our wiki. Where everything is clearly explained on how to do it (with example of code snippets/programs, so the reader can verify he gets similar results).

SECOND CONCLUSION : we need to start deciding what "convenience" package to ship in the next release.

Now let me address the BUT. The customer is always right! As good as our CB is, what counts is the user experience, no discussion about that, period. We can point to windows, gdb, python whatsoever. We need to at least propose a "recipe" to get to a good user experience (and we can do such thing a little bit with our convenience package. The user use the IDE for 2 things at minimum:

* write code
* debug code
The fact that the user used to have an expensive MS Visual Studio is a non argument. It is not the MSVS user experience that counts in this discussion it is OUR CB experience that matters.
It is the total user experience that counts, and will make a happy user, or aan user which decides to drop CB and look further.
Imagine you have a nice app on your phone, but the backend it talks too really sucks, no matter how nice and shiny and performant that app might be (even assume it is bug free), the experience will be crap due to that backend, and the user will drop it and look for other alternatives.

I have been evangelizing CB a lot in the past, I still do, but I an giving fair information, because if I do not from the start, in the end I end up like a fool, and let me tell you why, again it is all about user experience, and these areas where I have to say upfront the state  of the functionality (or lack of current state) are in order of what I have see from people complaining or in the end not willing to use CB (despite of all the other great features it has):


* code completion      <== we loose big time here wrt competition
* refactoring
* debugger
As long as the first 2 are in the current state, I noticed it is nearly impossible to convince for example an Eclipse user to even consider CB :-(
And yes I could try to improve it myself, but our current completion engine is dead, it can not solve the problems anymore, we need a different approach, and we have someone kindly working on an alternative one, and I am thinking of having a nightly (separate) build with it, so we can have more feedback, but even then it is 1 person at this moment so his time is also limited.
So yes the more people who can help out, test, provide patches, would be very nice. That's the good thing about open source, but it is also the downside, if nearly nobody steps up to help out things start to go slower and slower. And I have to pleed guilty myself, I still get up to the project management part of CB, the nightly builds but my commits have also been very low the last 2 years, because my spare time is a scarce resource.

So to all, please be constructive, though your statements might all be 100% correct, we need to aim for a good user experience, and try to bring that, not by saying we are only this, or that is not our problem. We need to look at the bigger picture.

PROPOSAL:
- this thread consists out of many suggestions, let's try them out
- use a nightly build and install TDM-GCC 5.1.0 package
- install python
- verify if it works
- let's discuss the problems in a positive way
- so we can end up with hopefully a working solution
- document the solution and give it a clear spot on our homepage
- in case we end up with a good result, as far as I am concerned (but I can't decide on just by myself) this could be the trigger for a new release (based upon whatever convenience package we end up with)
So I would like to kindly ask our OP to help out (I think you did not want to install python, in that case I am afraid there will be no solution, so please reconsider, pretty please), so some of the burden will be on your shoulders, but if it works out, I can tell you, you will feel happy and proud and that open source feeling.
And I promise that I will boot up my windows machine and try the same code snippets out myself, so we can share our findings, our frustrations, but we will turn them into something positive.

Please , let's work together, we are all right, but NOW LET'S IMPROVE THE USER EXPERIENCE.
Sorry for shouting ;-)

PS : let's not start a code completion discussion here, let's focus on getting e better debugging experience by bundling all the good things we have.[/list]

nji:
First of all:
It was not my intend to offend anyone.
As a matter of fact I am grateful to those who are the reason that there exists
this fine independent alternative to $$.
Thank you for that indeed.  :)
Being a M$-migrant all I can contribute so far is the experience "one" does
if one comes from that way. Deterrent, pleasant, ...
I didn't "give way" because I wanted to contribute just that.
Again: I didn't want to annoy anyone.

I'm sorry to have to disappoint you (asked to please reconsider) to install python.
I really have a reluctance to install more scripting ability to my system.
A potiential gate for anything ... that I don't need at all.
(Maybe I should mention that first thing I did after installation of Win7 was
to turn off every unwanted services, deinstall certain windows components,
closed all holes etc.).

But this way debugging works (more or less):
If one substitutes the gdb binaries (and probably nescessary sub folders etc.)
with the newer tdm gcc 7.9.1. (http://sourceforge.net/projects/tdm-gcc/files/GDB/gdb32-7.9.1-tdm-1.zip/download),
along with activating the scripts in cb's debugger config (see description above)
then it works ... nearly. (You can see the vector and the unfolding of its members,
but you can't watch a special index directly - test[42]).
So there is something wrong somewhere.

If with next release of cb it comes to the decision to drop mingw support
and to leave it for the windows user too to install compiler (and to manage
the adaption) I probably will stay with c:b (As there are reasons why I did't
decide for the other free options).
But probably cb will put off potential windows migrants and leave them in the arms
of the convenient $$-octopus.

[Edit:

--- Quote from: BlueHazzard on June 25, 2017, 12:44:15 am ---
Even more OT: ... that needs 170MB Installation, 146MB RAM and constantly 0.4% cpu on idle versus a uncool old in c and c++ written qTOX that uses 50MB RAM 0% cpu and 60MB installation...

--- End quote ---
100% agree.
But to my experience (as M$-migrant, did I mention?) also in "here":
Using wxWidgets produces a minimal size of several MB, while a typical
(not too simple) application of mine using MFC are only few 100kB.
"Nobody sane cares about that" was the answer I got in a forum.
Or - maybe a more subtle example - as I wanted to change from MFC
containers to modern standard lib ones, and discovered what kind of
absurd pull ups you have to do if you want to avoid unnecessary initialization.]

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version