Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 20 Mar 2012
Offline Last Active Aug 24 2016 07:11 AM

Posts I've Made

In Topic: Code Blocks debugging

18 August 2016 - 12:11 PM

You might be able to tweak Visual Studio's options to make it less bloated/slow, as well. Perhaps one particular setting is causing your pain?


This is indeed true, when I first researched the slowdowns (2005 / 2008 or so?) it seemed others had had the same problem, and I seem to remember it looked like it was caused by the background parsing of the source files, and perhaps some dodgy multithreading. I seem to remember I could improve it but the problem was still there. And the performance has been bad in every version I've tried since '.NET(!)' .. 2003, 2005, 2008, 2010 and 2013.


It might partly be to do with how accurately the parser is trying to map the source files, with users complaining that it has to be 'perfect'.... Early IDEs I suspect just did a wild stab at the classes etc, which is fast, and mostly correct 90% of the time. But with the result of the compilation depending on the particular #defines when you compile a file in c++, if you try and be accurate, you could be there forever as the effects of a small change propagate through the codebase. But still, other IDEs manage it.

In Topic: Code Blocks debugging

18 August 2016 - 11:48 AM

Well after wrestling with CMake (which actually isn't that bad), I've finally got my 3d Paint app compiling and running with QT creator. :lol: My only problem at the moment is that QT creator class view (I'm a big classview user) lumps all of the classes into one massive long list, making things difficult to navigate when you have hundreds of them. :wacko: I can't work out how to split the cmake project into different folders in the class view.


If I can't work this out, an option might be to group everything up into different namespaces, as the classview does seem to put classes into their respective namespace, allowing them to be used like folders. But it's not ideal because I'd have to change loads of code to respect the namespaces. :mellow:


Another possibility if QT is open source, maybe I can do a modification to allow folders in the class view...

In Topic: Code Blocks debugging

18 August 2016 - 11:24 AM

Oh that would be perfect, as aside from a few NCB bugs, Visual Studio 6 was excellent. :D Alas although I gather you can change the cl.exe used, the debugger doesn't seem to understand the later .exe files. Unless you can change the debugger too? Although I know you can use windbg separately, but that's not ideal...

In Topic: Code Blocks debugging

18 August 2016 - 10:57 AM

Ha .. well that's what I'm trying to migrate away from ..


I find latest versions of visual studio IDE to be very bloated, and slow, and they seem to hang at random, although the compiler itself is good. I'm after something more lightweight, and better written.

In Topic: For Loop Max Bug

09 August 2016 - 05:32 AM


you could equally well argue that the width and height are derived from the min / max extents

What do you call a rectangle that has no width and height?  Hint: it's not a rectangle any more.


There is an ontological relation (ie. it's one-one and onto, for those many rogues here who eschew the math behind programming) between the { w, h } properties of a rectangle and a { x, y, x', y' } tuple derived from its position in space.  That means you can substitute one for another at any given instance, but it does not mean the { x', y' } values are a property of the rectangle, it just means that you're storing a derived value and inferring the properties through an implied relation.


Consider further arguments for storing the properties of the object directly.


(1) class invariants -- the invariant property that makes a rectangle a rectangle is that it has a width and a height. Class invariants give a ready test point for verification and problem analysis and greatly facilitate reasoning about your program (as evidenced by the OP not using class invariants and having trouble reasoning about his program).


(2) moving the rectangle: the position of a rectangle is not actually a property of a rectangle but of any object representable in space (an AABB is_a object representable in space and has_a { width, height }).  If you were to store the derived values as a property of the rectangle, you would need to use the ontological relation to back-derive the extents of the rectangle and re-derive the new { x', y' } from the { x, y, w, h } every time you moved the rectangle.


It is possible third-party libraries have optimized their data structures for speed of certain operations, such as two fewer integer adds per rectangle during a render pass, at the expense of other operations.  If I were a gambling man my money would not be on that in most libraries.


So, yes, you could avoid best practices and store derived values in an object.  Lots of bad code is written every day (used the web lately?).  I would suggest your goal in life should not be to be the renowned author of bad code.  Design your software to explicitly store the invariant properties of object in the objects and do not store derived values without clear and compelling reasons for doing so.



I guess we will have to agree to disagree on this. To my mind, one of the major arguments for encapsulation is so that you shouldn't have to mind how the actual data like this is stored. If you want to, you can access it as one form, or the other.


Or, if you want, you can even make it ONLY accessible as left top, width height, to the outside world, but work internally with right, bottom:


If you consider this example offering two classes as a 'black box' to the client (it doesn't have to be a rectangle, it could be anything), which provide the same interface, which are identical, except one of which is faster, which is the better choice? Would you choose the slower one for philosophical reasons? :)