Code::Blocks Forums
User forums => Help => Topic started by: Ender46 on February 01, 2010, 07:24:10 pm
-
Hello all,
Recently I decided to upgrade my programming environment for my short c++ scripts from gedit to Code::Blocks. Needless to say, the difference is abismal. I have however found something that is annoying me, and that I know has to have a very easy fix, but I can't seem to find it.
I'm running version 8.02, in a Karmic Ubuntu, with an i7 920 processor (2.66GHz). When I used to work in the ancient manner, writting the code in gedit and compiling it with g++ from the command line, I could call the produced binary file multiple times, and each instance would use its own independent thread, so I could take advantadge of the multithreading capacities of my computer (given that I'm completely unable to make the program use multithreading by itself). However, when I compile the exact same code using Code::Blocks, whenever I call the binary multiple times, all the instances will just queue up on the same thread, effectively making things 8 times less efficient.
How can I solve this? Thanks in advance
-
How can I solve this? Thanks in advance
You can easily use the tools menu for that. Use the macros to point to the currently active target and then assign the launch command (with console, if you like) to run "visible, detached". Thus whatever target is active you can run multiple times from the menu therefore.
-
Can tips like that get put in the Tip of the Day window? =-) Also i think 'full commandline output' needs to be tip #2. I think its currently last.
-
Can tips like that get put in the Tip of the Day window? =-) Also i think 'full commandline output' needs to be tip #2. I think its currently last.
We have a very nice documentation that explains all that in detail. Hence nobody is reading. :-( So I'd say the tooltips will nobody read, too (in fact it's the first thing I disable when running a new software).
You can't defeat laziness, can you?!
-
Ok, after having spent a couple of hours on this, it seems I have it working now.
For the record, since my scripts requiered input from the console and showed meaningful output on it, I had to create a tool that would execute
gnome-terminal -x ${TARGET_OUTPUT_FILE}
from the working directory
${PROJECT_DIR}
with launching mode visible and detached. What this efectively does is to execute your current active binary in a new console terminal, which seem to be thread-independent at least to some extent.
Thanks!
-
Thanks for posting your exact solution. It makes forum searches more useful for the few people who use them =-)
We have a very nice documentation that explains all that in detail. Hence nobody is reading. :-( So I'd say the tooltips will nobody read, too (in fact it's the first thing I disable when running a new software).
You can't defeat laziness, can you?!
I dont read thru -all- Tip of the Day tips on new software immediately but I do try to avoid disabling them and read at least 2 or 3 each time I open the program as long as the 'tips' can fit in a paragraph or less. Just figure that if we put the most common 'lazy questions' as the very first few tips it might reduce the forum abuse. And out of curiosity does the tip of the day window support hyperlinks? If it does we could make sure that a couple tips that are also FAQ answers could link back to the documentation. Preferably the first tip might just mention the documentation and do nothing BUT link to it. That might encourage a few more users to rely on the docs too.
-
That might encourage a few more users to rely on the docs too.
IIRC even 08/02 ships with an internal documentation (CHM file). Probably it's worth adding it to the nightlies, too. Hence it will eat a lot bandwidth (that was the reason we decided no to do it actually).
-
Or you can add "Help -> Manual" that opens http://www.codeblocks.org/user-manual in the user's browser