GNOME nebo KDE ?

Pavel Kankovsky peak na argo.troja.mff.cuni.cz
Středa Listopad 22 16:49:32 CET 2000


On Wed, 22 Nov 2000, Ing. Pavel PaJaSoft Janousek wrote:

> 	No neni synonymem, ale muzete mi rici, jak byste v C volal vytvoreni
> aplikace - tedy vsechny <pref. lib.>Init<Cosi> coz za Vas v C++ udela
> konstruktor tridy automaticky?

Udela to automaticky, coz je fakt, ale ma to par chybicek: treba neni
nikde definovano v jakem poradi, ani to nelze zadnym inteligentnim
zpusobem ovlivnit, a tudiz neni tak uplne vylouceno, ze se budu muset
uchylit k ne-C++ reseni (napr. tak, ze na kazdem vstupu do me
"komponenty" se podivam, jestli jsem uz inicializovany a pokud ne,
tak se inicializuji).

Tim nechci nijak zvlast obhajovat C, spis tim chci rict, ze C++ je
v mnoha smerech pekne zmrseny jazyk. :)

> Pro Michala Krauseho: Cetl jsem mezitim vas dalsi prispevek, reaguji
> vsak primo zde - uz jen prosty fakt, ze konstruktory/destruktory vsech
> objektu za mne vola jazyk (ne prostredi!) dela z jazyka C vetsiho
> bumbrlicka (co se tyce delky source).

Konstruktory: Objekty z cizich knihoven neni nejlepsi napad pouzivat jako
automaticke promenne, protoze pak program neni binarne kompatibilni
v pripade, ze tam chci vrazit lepsi verzi te same knihovny, leda by ty
objekty byly jen "inteligentni pointery". Ale kdyz jsou alokovane
explicitne, tak se ten rozdil vubec nepozna (new Ble(a, b, c) a
new_Ble(a, b, c)...what's the difference?).

Destruktory: Kam se automaticke volani destruktoru hrabe na poradny
garbage collector. :) Vazne...automaticke volani destruktoru u
automatickych objektu dost pomaha zvlaste pri reseni vyjimek, ale zase je
to tak, ze knihovni objekty neni dobry napad moc pouzivat jako automaticke
promenne.

Cely ten humbuk o komponentach je v tom, ze kdyz se komponenty sice
vypadaji jako velke objekty, coz jsou v nejakych knihovnach, ale uz
zacinaji byt zajimave prave problemy napr. s binarni kompatibilitou
ruznych verzi a s spoluprace s ruznymi programovacimi jazyky. Zakladni
elementy uzivatelskeho rozhrani jsou nekde na dolnim okraji toho, cemu lze
v tomto smyslu rikat komponenty (zvlaste v pripade, ze maji jit
implementovat ruzne blbinky jako "themes").

> 	Zatim mne ani jedno prostredi po programatorske strance k nicemu
> nedonutilo - klidne mi v klidu aplikace psana v Motifu pred 3 lety (kdy
> jsem si o GNOME i KDE mohl nechat zdat) stale funguje a jeji Look and
> Feel (o tom to cele je) je porad to same...

Ne. Otazka zni, jestli KDE aplikaci muzete napsat treba v Pythonu,
resp. jak je velky opruz udelat pro KDE "language binding" do Pythonu.

> 1. Mluvite o konkretnim firemnim reseni - ja Vam mohu oponovat velmi
> jednoduse - stovnejte ESQL program a C program prohnany ECPG
> (PostgreSQL) - ja nevidim valneho rozdilu, vy ano?

Pardon? Je ESQL zkratka za Embedded SQL, tj. vec, ktera se procpe nejakym
preprocesorem, aby se z ni stal program v C nebo necem podobnem? K cemu
by ten preprocesor byl, kdyby mezi vstupem a vystupem nebyl zadny "valny
rozdil"?

> 2. Dynamicky vytvarenymi dotazy myslite:

Mel jsem na mysli kdyz je vylozene dynamicky i seznam parametru/vysledku a
jejich typy. Tedy ono to lze take udelat (nejake ty hruzy s DESCRIPTOR).
Spis mne napada jiny problem: jak treba Emb. SQL udela praci s typem
number(25) (25 dekadickych cislic, vice nez 80 bitu), kdyz se neco
takoveho do zadneho intu, longu ani long longu nevejde?

Ale nejak odbihame od toho...jak se to jmenuje? Je tam nejaky
vysmaty tucnak? Jo, Linux! :)

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."




Další informace o konferenci Linux