Quantcast

Jump to content

» «
Photo

Code::Blocks is cool

7 replies to this topic
The_GTA
  • The_GTA

    revenclaw

  • Members
  • Joined: 27 Dec 2012
  • Germany
  • Modding Milestone [Magic.TXD]

#1

Posted 17 January 2018 - 12:22 AM Edited by The_GTA, 17 January 2018 - 12:25 AM.

Hello programmers!
 
I have recently rediscovered Code::Blocks for me. Did you know that it supports wildcard includes, build scripts and IDE macros? I find those things useful to create powerful projects.
 
Here is a link to a tutorial I just made for Code::Blocks usage.

 

This IDE does mainly use the GCC compiler. And since GCC is pretty versatile I can even compile for my Dreambox 8000 sattelite box (MIPSEL processor).

 

If you read my tutorial, what do you think about it? Do you like Code::Blocks? :)

 

Yours,

Martin


K^2
  • K^2

    Vidi Vici Veni

  • Moderator
  • Joined: 14 Apr 2004
  • United-States
  • Best Poster in Technology / Programming 2017
    Best Poster [Technology / Programming] 2016
    Best Poster [Programming] 2015
    Most Knowledgeable [Web Development/Programming] 2013
    Most Knowledgeable [GTA Series] 2011
    Best Debater 2010

#2

Posted 17 January 2018 - 07:36 AM

Honestly, if you are looking for an integrated build manager and IDE, Visual Studio has better overall support, gives you far more powerful debugging tools, and can be configured to compile with just about anything. When I was working in game dev, we actually used Visual Studio to compile for PS4 via CLang.

On that note, whether you end up using Code::Blocks or anything else, I strongly recommend migrating from GCC towards CLang. It has way better code parsing and error reporting, especially if you work with templates and modern C++ features, is far more uniform cross-platform, and I personally like lldb debugger way more than gdb. In addition, due to language parsing being separate from actual compiler in CLang, there are a host of formatting tools that are just wonderful. If you're working solo, it probably doesn't mean as much, but for any team project that's going to be synced with any kind of version control, clang-format is just brilliant, and can be integrated into most code editors. Personally, I have it as key-binding in vim, but it will work with Eclipse, Atom, and many others.

On a different, related note, if you aren't married to the idea of having your IDE work as your build manager, and are happy to use external tools, CMake exceeds even Visual Studio in a lot or ways. For starters, it's way easier to have it running on different platforms. Also, far more projects on GitHub will have CMake configurations already set up than for VS. And being able to just drop a library from GitHub into your project can save a lot of time. Similarly, if you have a lot of your own libraries, I find adding them to a project you're working on locally way easier in CMake than VS or CB.

I've also gotten a lot of mileage out of Bazel, but mostly because I worked at Google for a while, and it's very similar to tools used internally. It has a lot of fantastic features. Unfortunately, you pretty much have to be working on a Linux machine to make use of it properly. If you intend to make something cross-platform, it's mostly off the table.
  • thehambone likes this

Gian_Yagami
  • Gian_Yagami

    Peon

  • Members
  • Joined: 08 Nov 2011
  • None

#3

Posted 17 January 2018 - 03:04 PM

I never go to Code::blocks, people said it's lightly instead visual studio. Personally I don't like visual studio cause that size is big and you can't completely clean used space aftee you installed it. For example:
-You're installing vs2013 and storage space it's still 20GB.
After IDE installed storage space is 17 GB.
-And if you uninstall the IDE space storage you got is 18.5GB
-Where is 1.5GB?

K^2
  • K^2

    Vidi Vici Veni

  • Moderator
  • Joined: 14 Apr 2004
  • United-States
  • Best Poster in Technology / Programming 2017
    Best Poster [Technology / Programming] 2016
    Best Poster [Programming] 2015
    Most Knowledgeable [Web Development/Programming] 2013
    Most Knowledgeable [GTA Series] 2011
    Best Debater 2010

#4

Posted 18 January 2018 - 02:29 AM

This is why everyone's so eager for C++20 to have official support for modules. Once we start using modules instead of libraries, the bloat will drop by an order of magnitude.

The main reason why we have such ridiculous binary sizes is because when you include templated libraries multiple times, you end up with a lot of code duplication. STL is a huge source of the bloat. But there are so many upshots on productivity and performance, that people chose to eat the cost of disk space. With modules, we'll be able to have our cake and eat it - have highly performant templated code that doesn't bloat binaries.

As for Visual Studio, as much as it annoys me, I know that I'll only ever have 2 versions installed at the same time, with maybe an update somewhere along the line before I'm forced to format my drive again. So I don't mind throwing 50GB or so at VS. Yes, I also wish it would be less, so that I could get away with keeping everything on an SSD, but benefits outweigh the costs for me.

The_GTA
  • The_GTA

    revenclaw

  • Members
  • Joined: 27 Dec 2012
  • Germany
  • Modding Milestone [Magic.TXD]

#5

Posted 18 January 2018 - 07:36 AM

Honestly, if you are looking for an integrated build manager and IDE, Visual Studio has better overall support, gives you far more powerful debugging tools, and can be configured to compile with just about anything. When I was working in game dev, we actually used Visual Studio to compile for PS4 via CLang.

That is actually really cool. I wish there'd a community surrounding Visual Studio compiler integration. I did look into it and you have to write tons of "target" scripts, pretty tedious to get into.

On that note, whether you end up using Code::Blocks or anything else, I strongly recommend migrating from GCC towards CLang. It has way better code parsing and error reporting, especially if you work with templates and modern C++ features, is far more uniform cross-platform, and I personally like lldb debugger way more than gdb. In addition, due to language parsing being separate from actual compiler in CLang, there are a host of formatting tools that are just wonderful. If you're working solo, it probably doesn't mean as much, but for any team project that's going to be synced with any kind of version control, clang-format is just brilliant, and can be integrated into most code editors. Personally, I have it as key-binding in vim, but it will work with Eclipse, Atom, and many others.

I was already impressed by GCC when it mentioned that adding two numbers could lead to an overflow but could be ignored under a certain assumption. There is no easy way to switch compilers in CB other than changing the project configuration but adding alternatives like Clang is a great idea!

On a different, related note, if you aren't married to the idea of having your IDE work as your build manager, and are happy to use external tools, CMake exceeds even Visual Studio in a lot or ways. For starters, it's way easier to have it running on different platforms. Also, far more projects on GitHub will have CMake configurations already set up than for VS. And being able to just drop a library from GitHub into your project can save a lot of time. Similarly, if you have a lot of your own libraries, I find adding them to a project you're working on locally way easier in CMake than VS or CB.

I've also gotten a lot of mileage out of Bazel, but mostly because I worked at Google for a while, and it's very similar to tools used internally. It has a lot of fantastic features. Unfortunately, you pretty much have to be working on a Linux machine to make use of it properly. If you intend to make something cross-platform, it's mostly off the table.

To be honest, I can confirm that many developers see project files as byproduct that can or shuld be generated. That's ok. But I belong to the group that maintains project files, so CMake and other project generators are only useful to me in an initial phase.
 

I never go to Code::blocks, people said it's lightly instead visual studio. Personally I don't like visual studio cause that size is big and you can't completely clean used space aftee you installed it. For example:
-You're installing vs2013 and storage space it's still 20GB.
After IDE installed storage space is 17 GB.
-And if you uninstall the IDE space storage you got is 18.5GB
-Where is 1.5GB?

You are kinda right. Visual Studio does heavily modify your environment and does not remember to clean up everything. And you as developer have the obligation to clean up your own built object files. But that is same for Code::Blocks.
 

This is why everyone's so eager for C++20 to have official support for modules. Once we start using modules instead of libraries, the bloat will drop by an order of magnitude.

The main reason why we have such ridiculous binary sizes is because when you include templated libraries multiple times, you end up with a lot of code duplication. STL is a huge source of the bloat. But there are so many upshots on productivity and performance, that people chose to eat the cost of disk space. With modules, we'll be able to have our cake and eat it - have highly performant templated code that doesn't bloat binaries.

As for Visual Studio, as much as it annoys me, I know that I'll only ever have 2 versions installed at the same time, with maybe an update somewhere along the line before I'm forced to format my drive again. So I don't mind throwing 50GB or so at VS. Yes, I also wish it would be less, so that I could get away with keeping everything on an SSD, but benefits outweigh the costs for me.

Visual Studio is installed on my SSD because I hope it increases building throughput. On my laptop I have no choice but to install it on the SSD.

Looking forward to C++ modules! :)

DK22Pac
  • DK22Pac

  • Feroci
  • Joined: 12 Apr 2009
  • Ukraine
  • Best WIP Mod 2014 [Grand Theft Auto 3D Contribution]
    Contribution Award [Mods]
    Helpfulness Award [Mods]

#6

Posted 18 January 2018 - 09:21 AM Edited by DK22Pac, 18 January 2018 - 09:42 AM.

If you can't afford VS installation, that's probably a best solution for you.

Pros:
  • Leightweight
  • Works on WinXP
  • Integrated GUI development (wxWidgets)
  • User templates and nice scripting system
Cons:
  • The_GTA likes this

The_GTA
  • The_GTA

    revenclaw

  • Members
  • Joined: 27 Dec 2012
  • Germany
  • Modding Milestone [Magic.TXD]

#7

Posted 4 weeks ago

@DK22Pac: thank you for those points! I agree. Will look into the cons eventually.

 

Just noticed a short-comming of Code::Blocks. If you want to add static library dependencies to static libraries, Code::Blocks does not support this. It was first reported by Kalith.

Then I opened another thread which suggests that GNU tools support it and CB could add support.


K^2
  • K^2

    Vidi Vici Veni

  • Moderator
  • Joined: 14 Apr 2004
  • United-States
  • Best Poster in Technology / Programming 2017
    Best Poster [Technology / Programming] 2016
    Best Poster [Programming] 2015
    Most Knowledgeable [Web Development/Programming] 2013
    Most Knowledgeable [GTA Series] 2011
    Best Debater 2010

#8

Posted 4 weeks ago

Yeah, a library has, essentially, the same dependency rules as an executable. So you can build an entire tree of library dependencies. In fact, large, multi-team projects are usually built like that. Each team supports a library, which can depend on any number of other teams' libraries. Some of these dependencies may be cyclic, and a good build system will be able to resolve that. Managing that mess usually ends up somebody's full time job.

Failing that, dynamic linking is a good way to work around that whole issue. There is a bit of a cost associated with that, primarily due to the fact that you're guaranteed a long-jump, which hurts both optimization and run time, but so long as you aren't calling functions from that library directly from within any tight loops, that cost is minimal. GCC flag -shared will build library that can be dynamically linked or loaded. The output library should be named lib<name>.so under *nix OS, and is then linked with -l<name> exactly the same as any static library. Because the actual loading and linking of library image happens at runtime, you no longer have a dependency issue. So you can have all of the shared/dynamic libraries be dependencies of the core project. If able to do so, however, it's a good idea to mark headers of the shared/dynamic library as dependencies of any library that will load it. Otherwise, you'll end up with runtime errors.

Oh, and unlike dynamic loading, where you have to manage your own function pointers, and are limited to C-style names, dynamic linking is taken care of for you by the OS and runtime, so other than the fact that you need to ship all of the .so files along with the executable, and the fact that they will be read separately into memory during start-up, there is no difference from your perspective between a dynamic and a static library. You absolutely can declare and define a C++ class within a dynamic library, and access it from a library or executable that link it, just like you could in static case.

There are some additional cool features that have to do with versions, but that's going beyond the scope a bit. For purposes of resolving dependency problems, you can think of them as equivalent replacement of static libraries.
  • The_GTA likes this




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users