“My compiler complied yours” :)
Nem árulok el nagy titkot, de a C#, VB, és C++ compilert C++-ban írják. Érdekes, hogy a UNIX-ok világában a C++ mostohagyerek, ami nem annyira a nyelv miatt van szerintem, hanem marhára sokféle C++ compiler implementáció létezik, amelyek apró, de fontos pontokon különböznek, így nem portolható a kód rendesen. Vagy laza a nyelvi szabvány, vagy kupi van a másik oldalon, ízlés kérdése.
Persze, az msnek könnyebb dolga van, nem kell több platformra dolgozni, más kérdés, hogy Windows alatt is van sokféle compiler, mégis működik közöttük a bináris együttműködés, köszönhető egy okos szabványnak, a COM-nak.
Igen, a COM nem halt ki, pedig azt hittük, ki fog. Sok ponton soha nem lesz a COM alternatívája a .NET. Miért? Tegyük fel, egy IE vagy Shell extensiont írok (most tényleg azt, az előbbit). Ha .NET-ben írom, akkor be kell töltődni az általam használt CLR-nek a target processzbe. Ok, eddig nincs nagy baj. De mi van, ha egy másik gyártó cucca meg más CLR verziót kér? Egy processzben csak egy CLR verzió lehet, aki először betöltődött, az nyert. Azért ez igen gázos dolog egy extension írónak, nem? Mi marad? ATL, C++.
Mostanában sokat tanulom a C++-t, kaptam a cégtől pár könyvet, és kicsit úgy érzem, kezdek nagykorúvá válni a programolásban. Még mindig nem értek hozzá, soha nem is fogok, de egyre több dolgot látok belőle, és napról-napra ledöbbenek, mennyi mindent nem tudok még. De jó érzés tanulni, mindig van mit.
Zárásul még két adalék. A C++ fordítót tényleg C++-ban írják, mindig a saját verzióval. Tehát, most írják a 2008 utáni C++ compilert, és annak a fordításához felhasználják a “félkész” C++ compilert. Meredek? :)
Ja, és a JScript.NET compilert C#-ban írták. :) Meg lehet nézni reflectorral, én nem találtam bennük C++/CLI maradványokat (modopt, stb.):
C:\Windows\Microsoft.NET\Framework\v2.0.50727\jsc.exe
C:\Windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.JScript.dll
C:\Windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.Vsa.dll
(A Sytem.Data pl. C++/CLI-ben készült, a program managere még a demókat is abban mutatta Redmondban).
Could you hire me? Contact me if you like what I’ve done in this article and think I can create value for your company with my skills.
LEAVE A COMMENT
3 COMMENTS
Azert ez nem teljesen van igy unix oldalon. Eleg sok project hasznal c++ kodot, mert sokszor azzal konnyebb dolgozni. A dolog ugy all, hogy nem feltetlen az oszalyos, oroklodos reszet hasznaljak a c++-nak, hanem egyfajta C expansionkent. Pl iostream, string, iterators. Meglatasom szerint egy kissebb programnal az osztalyhierarchia csak felesleges tulbonyolitas.
MS oldalon azert van nagyon nagy szukseg az osztalyhierarchiaba, mert a windowsos programok nem onalloak, hanem – durvan fogalmazva – egy nagyobb program pluginjei. Itt elengedhetetlen a jo cimezhetoseg, hiszen az oprendszer igencsak interaktivan kommunikal a programmal. Unix alatt az oprendszer passziv, es a programok kernek tole. Ez nem vonatkozik a gui programokra, itt egy picit interaktivabb a dolog, de vegulis ott is arrol van szo, hogy csak azt kapom meg, amit kifejezetten kerek, nem feltetlen kapok meg minden esemenyt.
Jézus, nem irigylem azt az embert, akinek az iostream könnyíti meg az életét. :)
Egyébként a dolog maga nem új, lásd C-ben írt C compiler…
Hat, lehet, hogy a stdio.h-s muvletekhez kepest vkinek az a konnyebb. Persze, nyilvan Qt-t is lehet hasznalni, csak nem mindenutt lehet tinyqt-ra szamolni, a nagy Qt-t meg egy konzolos kis semmisegert fuggosegbe tenni okorseg.