Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Oct 2009
Offline Last Active Sep 19 2015 08:53 AM

Posts I've Made

In Topic: How to use small datatypes efficiently

19 September 2015 - 08:51 AM

I thought I would tip you off to these excellent videos that explains what you are asking about.  You will see why the data probably is already in the processor by the time the CPU executes the instructions needing those registers.



In Topic: When you realize how dumb a bug is...

20 May 2015 - 07:11 PM



I once spent hours figuring out why this loop started with random values:

for (int i=l; i<10; i++) {

That's why syntax coloring is useful.


Why the heck would somebody declare a variable that is a lowercase 'L'?  I'd be mad at the single letter variable name declaration. 



I'm more curious to know why one would type the lowercase L instead of the 1 in the first place, given that at least on a QWERTY keyboard they're practically on opposite sides of the keyboard.



I was thinking the programming world's version of a troll.  :D

In Topic: Too clever...?

20 May 2015 - 06:42 PM

This isn't too bad. Overly clever would be putting 0, first, last and length in an array, calling is_sorted() on it, and relying on the compiler to unroll the loop to get the same result. Or abusing operator overloading and expression templates to get 0 <lte> first <lte> last <lte> length to compile so that you can python style chained comparisons.


Oh dear.  :D  Yes, that is overly clever.  Not sure if it is any more efficient though.  The first one seems to even have a bit more overhead than 5 if tests, the second one gives me a feeling to be at best just as good.  I don't know the underlying behaviour of either is_sorted or the Python style chained comparisons, though.

In Topic: Too clever...?

20 May 2015 - 05:55 PM

That seems pretty standard to me, it isn't an optimization it's just the straightforward way to bounds-check a range, the readability does not really go down in my opinion. That said I would personally put the "lastIndexExclusive < firstIndexInclusive" check first since the validity of the other two checks does depend on that condition being true, and also should those indices really be signed ints?


Yes, you are right.  I was thinking to myself that if I made them unsigned, I wouldn't even need the test for 'less than 0', since that would never happen in that case anyway.


EDIT: Sometimes I just mindlessly write code, but today I just had an epiphany.



Looks fine to me. In some other languages (like C# which I use most of the time) another common practice is to throw ArgumentException in those three cases.


Yes, I have had my dose of try..catch with Java back in the day.  It is something I try to avoid, unless something really bad happens in the code, but I do see its use.  Not sure why, but even 25 years back in time when I first learned Pascal, I tended to stick with the functions that didn't throw exceptions if for instance a file could not be found.  Really never been a fan of exceptions.  I think the main reason is that I think it clutters the code too much.


In java you even have to wrap string to integer conversions in a try...catch clause...  I always was amazed by that even the "simplest" of operations has to be wrapped in exception handling in Java.  You can probably guess that it is not my favourite programming language.  If I were to rank, it would be c#, and Swift looks promising too, but both are (or have been) traditionally been tied to a single platform.  So here I am with my second or third best: c/c++.


EDIT 2: Oh, yes, I get why you mentioned exceptions now.  You are probably right that it is better to throw an exception rather than returning an arbitrary 'negative 1', or pass a value by reference to see if the operations succeeded or not.  I still have a bad feeling about using too much exceptions though.


I know I am not alone in feeling this way.  The whole Objective-C setup that Apple provides, is built on the assumption that excessive exception handling is evil.  Having pass by reference error values is the rule rather than the exception there.


Then you have the reversed way where you return an ok/error code and pass the returned index as a reference.


What is best practice?  Is there even such a thing in this regard?  Swift can return tuples.  That is a nifty thing.  Too bad I am reluctant to be tied to a system that is so locked to one platform and one platform only.

In Topic: New to templates - Compiler can't find member name

20 May 2015 - 10:59 AM

Thanks for your suggestions.  I went with forward declaration.  I did actually try to forward declare the template class, but it didn't occur to me that I needed to forward declare the Point class too.  After I did both of those, everything compiles fine, and now I have lots of nice points showing up on my screen.


Now I will move on to make a scripted math library to move those dots around plus researching how I can make a fast 2D picking algorithm for a massive point cloud.  Probably will be much fun to see it all in action.


EDIT: Strewya: Thanks for best practices.  I always do forward declare functions, but that I in certain cases need to forward declare classes is a fairly new thing to me.