ruby vs python (is: Programmierung)

[Jan 'Red Bully' Seiffert]

Martin Baehr schrieb:
> On Tue, Nov 09, 2004 at 05:46:16PM +0100, Jan 'Red Bully' Seiffert wrote:
> 
>>>>In C++ kann man sie deklarativ durchbrechen,
>>>
>>>was heisst das?
>>
>>#define private public
> 
> 
> das is nicht dein ernst, oder?
Ich weiss jetzt nicht, ob Ingo das meinte, aber ja, das ist mein ernst.

> das durchbrechen der kapselung indem du private umdefinierst?
Jup, natuerlich nur waehrend der Einbindung entsprechender Header...

#define private public
# include "../include/hierwillichanprivate.h"
#undef private

Das kann man als Programmierer aber auch verhindern...

#if defined private or protected
# error "so nicht mein Freundchen"
#endif

(Sch...e mein groesser/kleiner/pipe geht grad nicht unter Gnome, wat is
dat den schon wieder, geht doch unter KDE...)

> das is doch garkein durchbrechen, sondern einfach ändern vom code, das
> geht doch in java auch (ok, halt nicht mit einem preprozessor)
> 
Geht das in Java auch so schmerzlos in Class-Dateien?

Naja, die Kunst ist halt, das du nichts wirklich Editierst, naja,
iregendwie schon, du nimmst halt mal fuer nen Moment die Worte weg (in
den Headern), an denen dein Compiler festmacht, er muesse dir verbieten
da jetzt drauf zuzugreifen. Nachher ist es ja eh egal - kein Laufzeitschutz.

Selbst wenn du das so nicht gelten laesst:
Du hast ja unter C++ sowieso noch die Totschlagkeule Pointer, damit
kommst du an alles ran, da keine Laufzeitkontrolle. Oder du tipst die
Klassendefinition ab (mit deinen Aenderungen) und Castet.

selbst so magische konstrukte wie (Achtung, das is C):

interface.h
-------------------------------------------------------
...
typedef struct interface
{
	int num; /* hier zugreifen */
	foo bar; /* hier auch */
	void *geheim; /* Fingers von die Dingers! */
} interface_t

interface_t *interface_t_alloc(size_t menge);
void interface_t_free(interface_t *to_free);
...
-------------------------------------------------------

interface.c
-------------------------------------------------------
#include ....
#include "interface.h"

struct geheim
{
	....
}

static struct geheim *geheim_alloc(size_t menge);
static void geheim_free(struct geheim *to_free);

interface_t *interface_t_alloc(size_t menge)
{
	size_t i = menge;
	interface_t *ret_val;
	if(!menge)
		return NULL;

	if(!(ret_val = malloc(menge)))
		return NULL;
	
	for(;i;i--)
	{
		ret_val[i].geheim = geheim_alloc(1);
		....
	}
	
	...

	return ret_val;
}

void interace_t_free(interface_t *to_free)
{
	if(to_free)
	{
		if(to_free-geheim)
			geheim_free(to_free-geheim);

		free(to_free);
	}
}
....
-------------------------------------------------------

(Wer Fehler findet kann sie behalten, is nur schnell runtergeschrieben.
In C++ ist das dann als "private: void *geheim" moeglich, und der
Konstruktor fuellt das dann mit einem "new MeineGeheimeKlasse()", der
Destruktor ruft eben die weiteren Destruktoren auf)

Man kann zwar nun das Layout von "geheim" in einem Nichtoeffentlichen
Bereich (z.B. nur lokal im .c(pp)) verstecken (bei Binary-only kannst du
es dann auch nicht nachlesen), du kommst aber trozdem irgendwie ran, ist
halt Irgendwie doch nur Speicher am Ende des Pointers.

Schoen is das alles nich, auch unportabel (Padding und was weiss ich was
sich dann alles verdreht), aber es geht, dagegen ist z.B. Java eine
"Festtung" (Da musst du mit Aufwand erstmal eine geaenderte Klasse
kompilieren und in dein Laufzeitsystem reinmogeln, hab ich schon drueber
nachgedacht, ich sach nur java.lang.String ist final....).

> 
> gruss, martin.
Gruss
	Jan

-- 
[memory leaks in Java]
Sozusagen eine Wohlstandskrankheit. Ein C-Programmierer wird dafuer
nur ein muedes Laecheln uebrig haben.