On the indexing of arrays and other little wonders

[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.