10 éves a CCC

Programozás

A változáslisták szerint 10 éves a CCC: Clipper leszármazott, a forráskódot C-re, illetve egy C-ben implementált veremgépre fordítja. Platformfüggetlen programnyelv és fejlesztőeszköz.

A jelenlegi állapot az Eltérések a CCC és Clipper között dokumentumból mérhető fel legjobban. A CCC kiterjeszti a régi Clippert. Korszerű, kiállja az összehasonlítást olyan nyelvekkel, mint a Python, Ruby, Pike. Különösen hasonló a CCC és a Python hangulata, mindkettő praktikus, tömör, mégis könnyen olvasható, kerülik a Java-ra jellemző tudálékosságot.

Hozzászoktam, hogy a fórumokon ilyeneket kapok: "Minek Clipperrel foglalkozni a .NET korában?" (sting), "Időgép is kellene hozzá", "Mit ér egy nyelv önmagában, osztálykönyvtár nélkül?". Először is, van egy s más a CCC-ben. Másodszor, a CCC-t könnyebb C betétekkel bővíteni, mint az említett nyelveket.

A Java bővítése C-vel ellenjavallt. Elvész a hordozhatóság, túl bonyolult, az átlagprogramozó nem is ért hozzá. Hasonló a helyzet a Pythonnál. Az alkalmazáshoz szükséges bővítéseket a futtatókörnyezet/interpreter módosításával kell(ene) megvalósítani. Ezekben a nyelvekben valóban nélkülözhetetlen az egész informatikai univerzumot magábafoglaló osztálykönyvtár.

Ezzel szemben a CCC (C fordítás közbeiktatásával) natív binárisokat készít, ezért bármikor alámerülhetünk C-be. A Clipperrel együtt automatikusan fordulnak a C modulok. Kisebb jelentősége van így az osztálykönyvtáraknak, mert mindig rendelkezésre áll a C-ből elérhető infrastruktúra. Ez a CCC filozófiája.

( tejfel | 2006. 09. 05., k – 14:33 )

"A Java bővítése C-vel ellenjavallt. Elvész a hordozhatóság, túl bonyolult, az átlagprogramozó nem is ért hozzá. Hasonló a helyzet a Pythonnál. Az alkalmazáshoz szükséges bővítéseket a futtatókörnyezet/interpreter módosításával kell(ene) megvalósítani."

Hát ez érdekes, szerintem elég sarkított vélemény. Én is az átlag progamozók közé tartozom, s gyakorlatban a swig (http://www.swig.org/) segítségével illesztettem C++ kódot python-hoz, s nem igazán okozott túl sok nehézséget. Azt meg végkép nem értem miért is kellene a bővítéshez módisítani a futtatókörnyezetet, simán modul fordul, amit be lehet tölteni futásidőben.

Köszönöm a hozzászólást. A Swiget nem ismertem. Egyelőre annyit látok belőle, hogy az "Interfacing C/C++ and Python with Swig" doksi egy 115 oldalas PDF.

Megmutatom inkább, hogy van kivezetve a fork() hívás CCC-ben: A forrás itt látható. A make rendszernek semmit sem kell mondani, a forrás magától fordul, csak attól, hogy ott van a többi prg és cpp között. Az eredmény egy object (fork.obj), ami a többi objecttel együtt linkelődik.

( btami v | 2006. 09. 06., sze – 09:38 )

"A Java bővítése C-vel ellenjavallt. Elvész a hordozhatóság, túl bonyolult, az átlagprogramozó nem is ért hozzá. Hasonló a helyzet a Pythonnál."

Python esetén ennek pont az ellenkezője igaz. Lásd pyqt, pygtk, pygresql, stb-stb.

A Pythont én is jónak tartom, de amit írtam mégis igaz. A pyqt csomag nem az alkalmazást bővíti, hanem a Python interpretert. Másképp nem is lehet, mert a py és cpp kód más "dimenzióban" vannak, nem tudnak máshol találkozni, csak az interpreterben. Ezzel szemben a CCC-nél a cpp kód feldolgozása rákerül ugyanarra sínre (félúton), mint amin a prg fordítás megy. Ez a lényeg.

Mit csinálsz, amikor C vel bővíted a Pythont? Linkelsz egy dinamikus könyvtárat, és azt a Python kezeügyébe rakod, vagy a bővítést direkt belelinkeled az interpreterbe.

Mit csinálsz, amikor Ptyhon alkalmazást írsz? Py fájlokat gyártasz, amikből pyc-ek lesznek.

Ez a két dolog elég élesen elkülönül. Egyébként nyilvánvaló, hogy a pyqt-s programod egy qt-val bővített Python interpretert használ, és a pyqt nem a Te alkalmazásod része.

Az "ellenjavallt" állítás elsősorban a Jávára volt megfogalmazva. A "hasonló a helyzet" pedig minden interpreterre vonatkozik: Ezek nem bővíthetők közvetlenül, hanem csak az interpreteren keresztül. Ez mindenképpen plusz bonyodalmakkal jár.