On the indexing of arrays and other little wonders

[mrjj]

And this is why normal people and programmer always talk past each other.
We start counting at zero and the rest of humanity start with 1 :)

Btw. I do have this case with PLCs.
Their (internal) lists start a 1 and so when I transfer from c/c++ i have to manage that
and hence I do not use index 0 in the c++ code as not to go crazy with +/- 1 all over.
a 1:1 match does read much better for debugging. so [X] on c++ is also [X] on PLC and
not [X+1]

[Forked from http://forum.qt.io/topic/68625/qlist-index ~kshegunov]

[kshegunov]

@mrjj

We start counting at zero and the rest of humanity start with 1

I would argue the rest of humanity is wrong ... but then I don't have the support to enforce a new counting. ;)

I do have this case with PLCs.

I've said it before and I'll say it again: don't use substandard controllers and/or compilers ... ;)

a 1:1 match does read much better for debugging. so [X] on c++ is also [X] on PLC and
not [X+1]

Not only for debugging. I'd say you're just fine wasting a single element from the beginning instead of making a "minor" mistake changing offsets ... however I'm sure you'd agree that the OP's justification for doing that is somewhat iffy ...

[Joel Bodenmann]

@mrjj said:

And this is why normal people and programmer always talk past each other.
We start counting at zero and the rest of humanity start with 1 :)

Actually, my hardware design professor (FPGAs and stuff) can't stand it if I/we start to enumerate with 0 instead of 1. Yes sure, one can now pull the argument whether people doing hardware design using tools like VHDL and Verilog are actually programmers but... do they count as "normal people"? :p
It's just funny to see that a very decent engineer/professor doesn't like enumeration to start with zero.
Next time I'll have that discussion with him (which is surprisingly often), I'll pull the argument that @kshegunov stated: It's the offset of the element :p

Maybe we get too off-topic now.

[mrjj]

@Joel-Bodenmann

• Maybe we get too off-topic now

[the_]

@mrjj
Can't you just move the topic to another sub forum where its not off topic anymore? ;)

[Joel Bodenmann]

That would probably be rather rude for the OP :p

[mrjj]

@the_
well i could - but is it that off ?
Still about the wonders of zero index with some extra ;)

[kshegunov]

@Joel-Bodenmann said:

It's just funny to see that a very decent engineer/professor doesn't like enumeration to start with zero.

Everyone has the right to have no taste ...

I'll pull the argument that @kshegunov stated: It's the offset of the element :p

I thought this was common knowledge.

How is this:

int x[5];
x[2] = 0;

different from:

*(x + 2) = 0;

PS: Except for the extreme ugliness of the latter that is ... :)

[Joel Bodenmann]

@kshegunov This is probably the point where I can dump this one...

#include <iostream>
#include <string>

int main()
{
	std::string a[] = {"Hello", "World"};
	
	std::cout << 0[a] << std::endl;
	std::cout << 1[a] << std::endl;
	
	return 0;
}

This proves that operator[] is really nothing but an offset operator (well, one can overload it for classes, yes....).

[kshegunov]

@Joel-Bodenmann

Man, this:

std::cout << 0[a] << std::endl;

shouldn't work even on Friday ...

By the way, the proper way to unnecessarily make things look unfathomable is to use fully qualified access:

std::cout << a.operator[] (0) << std::endl;

:)

[Joel Bodenmann]

@kshegunov said:

By the way, the proper way to unnecessarily make things look unfathomable is to use fully qualified access:

std::cout << a.operator[] (0) << std::endl;

Well, that won't work with plain arrays ;)
Also you can't annoy C people with that.

[kshegunov]

@Joel-Bodenmann
You youngsters and your requirements ... plain arrays are plain, they need no stinkin' (custom) operators in the first place ... :D

Also you can't annoy C people with that.

With this I agree completely, but they can still annoy you by naming their variables new, like this:

char new[5]; //< This always makes my day

[the_]

char new[5]; //< This always makes my day

Thats as hard as

public class if {

} 

;)

[Joel Bodenmann]

@kshegunov
What about #define float int? :p
If you hide stuff like this: #define if(x) you can truly fuck someone's day.

However, the most evil one might be this: #define struct union.

[the_]

@Joel-Bodenmann

Or try to

#define true false

in a global headerfile in a large project ;)

[kshegunov]

@the_ said:

public class if {

} 

Ouch! There's tons of weird stuff a C dev might do, like:

struct class object;

@Joel-Bodenmann

Aha! We are bringing the heavy artillery, aren't we?

Since the preprocessor is not part of the language, and it's run before anything else ... and it's just string substitution, you can make very ugly stuff, like:

#define true 0
#define false 1

[Joel Bodenmann]

@kshegunov

Aha! We are bringing the heavy artillery, aren't we?

No Sir, this is the heavy artillery:

#define if(x) if((__LINE__ % > 500)^(x))

Everything works well as long as the source doesn't grow larger than 500 lines.

And if you want to keep people from fucking with your sources/algorithms, you can carefully write a program with this:

#define if(x) if((__LINE__ % 5==0)^(x))

If done right, your stuff will work fine for as long as nobody adds or removes a line.

</topic>

[kshegunov]

@Joel-Bodenmann

This is (somewhat) tractable. My greatest clash with the preprocessor was when I was served with a "class" that defined a 256 item color table by means of members for each of 256 colors ... the properties, getters and setters were naturally defined through preprocessor macros. It was one of the low points of my life ... :)

[the_]

@kshegunov said:

@the_ said:

public class if {

} 

Ouch! There's tons of weird stuff a C dev might do, like:

I think it was Java code where i found this crap :)

[kshegunov]

@the_

I think it was Java code where i found this crap

Well, Java is C++'s little sister, too bad her genes got screwed up and she turned out a freak ;)

[Joel Bodenmann]

@kshegunov
You might like my embedded graphics/GUI library then. Everything that can be done with preprocessor macros is done using preprocessor macros:

https://bitbucket.org/Tectu/ugfx/src/fb100bcc25225cfad0bab5d40bef1db703e9670a/src/gdisp/gdisp_colors.h?at=master&fileviewer=file-view-default
https://bitbucket.org/Tectu/ugfx/src/fb100bcc25225cfad0bab5d40bef1db703e9670a/src/gdisp/gdisp_driver.h?at=master&fileviewer=file-view-default#gdisp_driver.h-812

If you keep browsing the sources you will find other goodies :)

[kshegunov]

@Joel-Bodenmann
Right ... because my life doesn't suck enough and I would like to suffer more? I'm with @Wieland on that preprocessor magic - I avoid as the devil avoids incense ... there's a whole battery of cheat-sheets for dealing with that ugly monster ...

[Joel Bodenmann]

@kshegunov
If your target processor runs on 64 MHz and has 32 kB RAM and you want to do some graphics/GUI on it, you might be thankful that there are masochistic people out there :)

Of course I'd never do that on a desktop system.

Actually, the real problem I see with preprocessor macros is not actually writing and maintaining them but debugging them.

[kshegunov]

@Joel-Bodenmann
One of the reasons I stick to real CPUs. ;)
Joke aside, I leave that not-enough ram/CPU time struggle to engineers/embedded devs, I don't have the stomach for it to be honest. :D

As a side note I'm not completely convinced using #define for constants is really warranted.
If you're doing a comparison for example, this would (if I remember correctly) expand to something along the lines of:

mov eax, 0x...      # Set the constant
test eax, [0x...]   # Do the comparison with a field from memory

If you use a simple constant (const static variable), the above should be pretty much the same:

mov eax, [0x...]    # Set the constant (from memory this time)
test eax, [0x...]   # Do the comparison with a field from memory