Az egyértelmű számomra, hogy ha pl Linux akkor GCC _a_ C fordító. De mi a helyzet Windowson? Mivel szokás lefordítani monjduk egy GIMP-et, vagy Python-t?
Hozzászólások
IMHO: MinGW vagy MSVC
--
A gyors gondolat többet ér, mint a gyors mozdulat.
kicsit off, de azert valamennyire a temahoz kapcsolodik:
- linux alatt mingw-vel lehet win-es binarisokat kesziteni, fasza, kiprobaltam, megy. kerdes, hogy hogyan lehet elerni hogy bizonyos retegfuggvenyek amik linuxon alapbol mennek (unistd, persze, mima's) menjenek mingw+linux alatt is? Pl fork(), pipe()? A win is multitaszk, nem hiszem hogy ezekre ne lenne implementacio, vagy wrapper.
- win alatti mingw-vel mi a helyzet? ott van fork()? ilyen szintu hordozhatosag mennyire megvalosithato? (igen, tudom, cygwin alatt megy minden, az fasza, de ott egyeb overhead-ek is vannak - cygwin.dll - ill nem lehet linux alatt elkesziteni...)
Nincs, ugyanis a Windows szalkezelese pl. teljesen mas, mint linux alatt. Windows alatt nincs fork, ott a CreateProcess-szel kell jatszani. A pipe()-re ugyanez van. Nem lehet wrapper implementaciot se igazan adni, mert tok maskepp kell parameterezni, es a linuxos API nem ad lehetoseget arra, hogy az elengedhetetlen leirokat visszaadja. Tehat mindenkepp maskepp kell megoldani, akkor meg akar a windowsos modon is meg lehet csinalni ifdeffel.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
Ilyenkor jó valamilyen OS feletti réteget használni. Én a Qt megoldásaival általában elégedett vagyok, de a boost is jónak tűnik. Két process között gépen belül én ma a shared memory-t tartom a leghatékonyabb megoldásnak. Megy a legtöbb OS alatt, és gyors. De ízlések és pofonok...
-- http://www.naszta.hu
Na igen. En kimondottan apal kollega kerdeseit akartam csak megvalaszolni, viszont a valodi megoldas tenyleg valamilyen platformfuggetlen framework hasznalata, ha a feladat megengedi.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
Igen, kozben neztem en is ezt a winbase api-t. Ez a createprocessw() elegge meredeken kulonbozik a fork()-tol, a mingw-n belul nincs annyira jol dokumentalva. de nem is ez lenne, konkretan a szuk keresztmetszet, mert ha mondjuk (a fork-nal meg a pipe-nal maradva) meg is talalnank ezeknek a megfelelojet, egy ilyen pipe()+fork()+close([0])/close([1])+read()/write()+select() alapu kis egyszeru" multiplexelt ipc-t megvalositani (amit mondjuk csuklobol csinal az ember unix alatt), azt mar gondolom eselytelen (es ilyen szinten akkor valszeg qt-ben sem lehet lemenni, bar azt nem ismerem).
Csak azt nem ertem, miert akarod alacsony szinten megvalositani ezt a reszet, mikor rendesen meg van ez csinalva pl. a Qt-ben?
MinGW-ben nincs dokumentalva: parser error. Miert kellene a MinGW-nek dokumentalni? MSDN. Ott minden szepen le van dokumentalva, lehet olvasgatni.
En mindenkepp annak a hive vagyok, hogy ha egy feladatot meg akarok oldani, akkor ne a melegviz melegitesenek ujraimplementalasaval toltsem az ido jelentos reszet, hanem a konkret problema megoldasaval. Ha van egy framework, amit lehet hasznalni, akkor hasznalom. Persze, nekem sose lesz feladatom embedded rendszerek fejlesztese, ugyhogy abba nem tudok beleszolni, de mivel Windows a tema, itt nyilvan nem errol van szo (a WinCE API megint nagyon sokba kulonbozik, abba mar bele se menjunk).
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
Csak azt nem ertem, miert akarod alacsony szinten megvalositani ezt a reszet, mikor rendesen meg van ez csinalva pl. a Qt-ben?
inkabb forditva: adott egy tonna kod, ami mar unix rendszereken megy, hasznalja ezeket az eszkozoket, oszt tfh hogy nem lenne baj, ha ezek futnanak win alatt is. kis faradsaggal, ugy, hogy a binarist is maga't le lehet forditani linux alatt.
az egy mas kerdes, kicsit szubjektiv is, hogy egy fork()+pipe() kaliberu problemara mellett egy qt az nem is kicsit agyu-vereb. de persze ketsegtelen, hogy hordozhato lesz qt-vel: valamit valamiert.
Amennyire most a cygwin honlapját olvasgatom, ezekhez a fork-exec szerű dolgokhoz mindössze egy cygwin1.dll-kell.
Így van. Például az lbzip2.exe (ehehe... bocs) simán elfut egy libbz2.dll + cygwin1.dll páros kíséretében. (Legalábbis azt hiszem.)
Ezen oldal szerint ha az alkalmazás valamilyen OSI szerint elfogadott nyíltforrás-licensz alatt van terjesztve, akkor a cygwin1.dll még csak nem is kényszeríti GPL alá az alkalmazást. Vagyis simán terjeszthető az OSI-nyílt program bináris formában (.exe + cygwin1.dll) egy olyan oldalon, ahonnan még az alábbiak mindegyike is letölthető: (1) alkalmazás illeszkedő verziójú forrása, (2) cygwin1.dll illeszkedő verziójú forrása (példának lásd ezt -- a lap tetején leírja, mi minek a forrása).
(Plusz a további lib-ekre is figyelni kell, természetesen.)
Úgy sejtem, hogy ha egy rendes Cygwin release-ben található cygwin1.dll forrására van szükségünk, akkor meg lehet hozzá keresni itt a megfelelő CVS tag-et (pl. "cygwin-1_7_3-release"), majd ezzel a tag-gel rendesen egy cvs export -kv:
Haaat, a fene tudja. En ezt olyan... lusta megoldasnak erzem. Ha valaki windowsra (is) fejleszt, lehet jobb lenne, ha tisztaban lenne a mukodesevel, nem csak a fork-exec miatt, hanem ugy altalaban is. Ez sajna nem mindig jellemzo.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
Nezd, jelen pillanatban az az tenyalladek, hogy a Microsoft szarik magasrol a POSIX ajanlasokra, es baromi keves dolog van belole implementalva a Windows API-jaban. Emiatt lehet sirni, lehet duhongeni, egyet nem lehet: valtoztatni rajta. Jelen pillanatban kettofele kerulomegoldas letezik
- #if defined(WIN32) && !defined(__Cygwin__)
- valamilyen framework hasznalata, ahol ezt megoldottak
Az elso verziohoz nagyon el kell merulni a WinAPI rejtelmeiben ahhoz, hogy korrekt megoldas szulessen.
A masodik plusz elonye az, hogy az ilyen framework-ok altalaban mas tekintetben is egesz kellemes megoldasokat tudnak nyujtani, es lehet, hogy az alkalmazasban mashol is egyszerubb lesz az ember elete.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
Nem hülyeség amit szeretnél, ezt akarták a cygwin fejlesztői is, és ezért van cygwin.
Szinte biztos vagyok benne hogy lehet cygwin-re fordítani linux alól...
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o
Ha C-rol van szo es nem C++, akkor az MSVC nem feltetlenul jo valasztas, mert pl. tobb hasznos C99 feature-t nem tamogat (es legalabbis regebben egyeb gondok is voltak vele C tamogatas teren, nem tudom azota jobb lett-e).
MinGW-t javaslom (gcc), vagy az intel c compiler nem tudom van-e windowsra.
MS Visual Studio 6.0-val volt sok gond (nem volt szabványos). Az MSVC 2005 (8.0) óta sokat ment az MS a szabványok felé. Szerintem ma teljesen korrektül tudja azokat. Az én javaslatom az, hogy vagy MSVC 2005 vagy MSVC 2008-at használjon, ha MSVC a compiler. Erősen javasolt a service pack-ok használata, mert MSVC 2005 SP nélkül memory leak-es az STL-ben.
Par alapveto dolog:
- Does not understand named initializers;
- Does not understand variable-length arrays;
- Does not understand the inline keyword (understands _inline though);
- Does not understand compound litterals;
Valóban még most sem teljes a kép. Azt azonban el kell ismerni, hogy nagyságrendekkel jobb, mint a 6.0 volt. Minimális különbségek egyébként a GCC-ben is vannak, de ma már lehet olyan ötleted, hogy olyan szabványos kódot írsz, ami gyakorlatilag mindenen fordul. :)
Tudom, hogy ezek nincsenek benne implementálva (még), de ezek nélkül azért egész kényelmesen lehet fejleszteni. Ma már - szerintem - minden open source cuccot úgy érdemes írni, hogy lehetőleg a 3 nagy compiler (gcc, msvc 8.0 <=, intel cc) alatt forduljon.
Tisztán C projekthez semmiképpen nem ajánlom az MSVC-t. Friss tapasztalat!
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods
Cygwin-t használtam eddig, ha néha fordítottam valamit Windows alá, és a binárisnak szüksége van a Cygwin dll-re a futáshoz.
A MinGW-nél ez hogy működik? Lehet önállóan futásképes programot fordítani, vagy ehhez statikus linkelés kell?
Lehet-e csak a C fordítót telepíteni, vagy itt is kell mindenféle GNU program még?
Mind ezek mellett én MS Visual Studio Express-t használnék, ha free kell. Gyorsabbak win alatt általában a kereskedelmi fordítók, az Express-t meg meg lehet hegeszteni úgy, hogy mindent tudjon, amit kell. Platform SDK-t is.
Én is MinGW-vel próbálkozok Win alatt, de szerintem ne az igazi:
a lefordított fájl mérete kb. másflészer akkora (24KB), mint amit Borland Turbo C-vel fordítottam (17KB), emellett fele olyan gyors ugyanaz a kód...
--
Azt akarom, hogy az emberek ne kényszerből tanuljanak, hanem azért, mert tudni akarnak.
Azért a korábban felsoroltakon kívül létezik Win-re az LCC, a Pelles-C, a Watcom-féle C/C++ fordító (asszem mostanában OpenWatcom-nak híjják, és a maga idejében az egyik leggyorsabb kódot fordította), most már mintha menne Win alatt az LLVM-féle CLANG. Választék az van.
Egyiknél sem tudtam, hogy létezik ilyen... o_O Borland Turbo C IDE-ben csak F9-et nyomtam, gcc pedig a -Wall paraméterekkel fordította le.
Egyszerű konzol alkalmazás, van benne memória és fájlkezelés is.
Hozzá kell tenni, hogy a Turbo C-vel készített prog WinXP alatt ezt az üzenetet írja ki az első futtatásnál: C:\WINDOWS\SYSTEM32\HASPDOS.SYS
--
Azt akarom, hogy az emberek ne kényszerből tanuljanak, hanem azért, mert tudni akarnak.
Hozzászólások
IMHO: MinGW vagy MSVC
--
A gyors gondolat többet ér, mint a gyors mozdulat.
kicsit off, de azert valamennyire a temahoz kapcsolodik:
- linux alatt mingw-vel lehet win-es binarisokat kesziteni, fasza, kiprobaltam, megy. kerdes, hogy hogyan lehet elerni hogy bizonyos retegfuggvenyek amik linuxon alapbol mennek (unistd, persze, mima's) menjenek mingw+linux alatt is? Pl fork(), pipe()? A win is multitaszk, nem hiszem hogy ezekre ne lenne implementacio, vagy wrapper.
- win alatti mingw-vel mi a helyzet? ott van fork()? ilyen szintu hordozhatosag mennyire megvalosithato? (igen, tudom, cygwin alatt megy minden, az fasza, de ott egyeb overhead-ek is vannak - cygwin.dll - ill nem lehet linux alatt elkesziteni...)
Nincs, ugyanis a Windows szalkezelese pl. teljesen mas, mint linux alatt. Windows alatt nincs fork, ott a CreateProcess-szel kell jatszani. A pipe()-re ugyanez van. Nem lehet wrapper implementaciot se igazan adni, mert tok maskepp kell parameterezni, es a linuxos API nem ad lehetoseget arra, hogy az elengedhetetlen leirokat visszaadja. Tehat mindenkepp maskepp kell megoldani, akkor meg akar a windowsos modon is meg lehet csinalni ifdeffel.
--
Ilyenkor jó valamilyen OS feletti réteget használni. Én a Qt megoldásaival általában elégedett vagyok, de a boost is jónak tűnik. Két process között gépen belül én ma a shared memory-t tartom a leghatékonyabb megoldásnak. Megy a legtöbb OS alatt, és gyors. De ízlések és pofonok...
--
http://www.naszta.hu
Na igen. En kimondottan apal kollega kerdeseit akartam csak megvalaszolni, viszont a valodi megoldas tenyleg valamilyen platformfuggetlen framework hasznalata, ha a feladat megengedi.
--
Igen, kozben neztem en is ezt a winbase api-t. Ez a createprocessw() elegge meredeken kulonbozik a fork()-tol, a mingw-n belul nincs annyira jol dokumentalva. de nem is ez lenne, konkretan a szuk keresztmetszet, mert ha mondjuk (a fork-nal meg a pipe-nal maradva) meg is talalnank ezeknek a megfelelojet, egy ilyen pipe()+fork()+close([0])/close([1])+read()/write()+select() alapu kis egyszeru" multiplexelt ipc-t megvalositani (amit mondjuk csuklobol csinal az ember unix alatt), azt mar gondolom eselytelen (es ilyen szinten akkor valszeg qt-ben sem lehet lemenni, bar azt nem ismerem).
Csak azt nem ertem, miert akarod alacsony szinten megvalositani ezt a reszet, mikor rendesen meg van ez csinalva pl. a Qt-ben?
MinGW-ben nincs dokumentalva: parser error. Miert kellene a MinGW-nek dokumentalni? MSDN. Ott minden szepen le van dokumentalva, lehet olvasgatni.
En mindenkepp annak a hive vagyok, hogy ha egy feladatot meg akarok oldani, akkor ne a melegviz melegitesenek ujraimplementalasaval toltsem az ido jelentos reszet, hanem a konkret problema megoldasaval. Ha van egy framework, amit lehet hasznalni, akkor hasznalom. Persze, nekem sose lesz feladatom embedded rendszerek fejlesztese, ugyhogy abba nem tudok beleszolni, de mivel Windows a tema, itt nyilvan nem errol van szo (a WinCE API megint nagyon sokba kulonbozik, abba mar bele se menjunk).
--
Csak azt nem ertem, miert akarod alacsony szinten megvalositani ezt a reszet, mikor rendesen meg van ez csinalva pl. a Qt-ben?
inkabb forditva: adott egy tonna kod, ami mar unix rendszereken megy, hasznalja ezeket az eszkozoket, oszt tfh hogy nem lenne baj, ha ezek futnanak win alatt is. kis faradsaggal, ugy, hogy a binarist is maga't le lehet forditani linux alatt.
az egy mas kerdes, kicsit szubjektiv is, hogy egy fork()+pipe() kaliberu problemara mellett egy qt az nem is kicsit agyu-vereb. de persze ketsegtelen, hogy hordozhato lesz qt-vel: valamit valamiert.
Nem pont erre találták ki a cygwin-t?
Pl ott van fork...
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o
A cygwin az olyan majdnem, mint egy kulon oprendszer az oprendszer felett. Azt fel kell telepiteni kulon ahhoz, hogy hasznalhato legyen a program.
--
Amennyire most a cygwin honlapját olvasgatom, ezekhez a fork-exec szerű dolgokhoz mindössze egy cygwin1.dll-kell.
Nyilván, ha bash-t, sed-et meg hasonlókat akarsz használni, akkor kellenek azok is...
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o
Amennyire most a cygwin honlapját olvasgatom, ezekhez a fork-exec szerű dolgokhoz mindössze egy cygwin1.dll-kell.
Így van. Például az lbzip2.exe (ehehe... bocs) simán elfut egy libbz2.dll + cygwin1.dll páros kíséretében. (Legalábbis azt hiszem.)
Ezen oldal szerint ha az alkalmazás valamilyen OSI szerint elfogadott nyíltforrás-licensz alatt van terjesztve, akkor a cygwin1.dll még csak nem is kényszeríti GPL alá az alkalmazást. Vagyis simán terjeszthető az OSI-nyílt program bináris formában (.exe + cygwin1.dll) egy olyan oldalon, ahonnan még az alábbiak mindegyike is letölthető: (1) alkalmazás illeszkedő verziójú forrása, (2) cygwin1.dll illeszkedő verziójú forrása (példának lásd ezt -- a lap tetején leírja, mi minek a forrása).
(Plusz a további lib-ekre is figyelni kell, természetesen.)
Úgy sejtem, hogy ha egy rendes Cygwin release-ben található cygwin1.dll forrására van szükségünk, akkor meg lehet hozzá keresni itt a megfelelő CVS tag-et (pl. "cygwin-1_7_3-release"), majd ezzel a tag-gel rendesen egy cvs export -kv:
és az eredményt lehet csomagolni.
Haaat, a fene tudja. En ezt olyan... lusta megoldasnak erzem. Ha valaki windowsra (is) fejleszt, lehet jobb lenne, ha tisztaban lenne a mukodesevel, nem csak a fork-exec miatt, hanem ugy altalaban is. Ez sajna nem mindig jellemzo.
--
+1, főleg, hogy úgy jóval gyorsabb...
--
http://www.naszta.hu
Nezd, jelen pillanatban az az tenyalladek, hogy a Microsoft szarik magasrol a POSIX ajanlasokra, es baromi keves dolog van belole implementalva a Windows API-jaban. Emiatt lehet sirni, lehet duhongeni, egyet nem lehet: valtoztatni rajta. Jelen pillanatban kettofele kerulomegoldas letezik
- #if defined(WIN32) && !defined(__Cygwin__)
- valamilyen framework hasznalata, ahol ezt megoldottak
Az elso verziohoz nagyon el kell merulni a WinAPI rejtelmeiben ahhoz, hogy korrekt megoldas szulessen.
A masodik plusz elonye az, hogy az ilyen framework-ok altalaban mas tekintetben is egesz kellemes megoldasokat tudnak nyujtani, es lehet, hogy az alkalmazasban mashol is egyszerubb lesz az ember elete.
--
a Microsoft szarik magasrol a POSIX ajanlasokra
Nem annyira magasról, lásd Interix / SFU.
fork minek? Ott a pthreads-win32 :-)
szerk.: közben rájöttem, hogy hülyeséget írtam, mert te nem új szálat akarsz létrehozni, hanem új processzt.
Nem hülyeség amit szeretnél, ezt akarták a cygwin fejlesztői is, és ezért van cygwin.
Szinte biztos vagyok benne hogy lehet cygwin-re fordítani linux alól...
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o
1 2
Én szeretem még az intel compliler-t is. 32 bit-en borland sem rossz.
Ha CMake alapú a projekt, akkor bármelyiket használhatod. ;)
--
http://www.naszta.hu
imho MSVC, de ott a Borland C forditoja is, meg a MinGW-e is.
---
/* No comment */
Ketchup elementál megidézése a sajt síkra
Ha C-rol van szo es nem C++, akkor az MSVC nem feltetlenul jo valasztas, mert pl. tobb hasznos C99 feature-t nem tamogat (es legalabbis regebben egyeb gondok is voltak vele C tamogatas teren, nem tudom azota jobb lett-e).
MinGW-t javaslom (gcc), vagy az intel c compiler nem tudom van-e windowsra.
- Use the Source Luke ! -
intel fordito van windowsra, visual studioval is hasznalhato
szerk: valahol olvastam (talan itt a forumon), hogy van 30 napos teljes probaverzioja is
---
Egy jól megállapított probléma félig megoldott probléma.
- Charles Kettering
MS Visual Studio 6.0-val volt sok gond (nem volt szabványos). Az MSVC 2005 (8.0) óta sokat ment az MS a szabványok felé. Szerintem ma teljesen korrektül tudja azokat. Az én javaslatom az, hogy vagy MSVC 2005 vagy MSVC 2008-at használjon, ha MSVC a compiler. Erősen javasolt a service pack-ok használata, mert MSVC 2005 SP nélkül memory leak-es az STL-ben.
--
http://www.naszta.hu
Par alapveto dolog:
- Does not understand named initializers;
- Does not understand variable-length arrays;
- Does not understand the inline keyword (understands _inline though);
- Does not understand compound litterals;
lasd itt
De voltak vele mas problemak is regebben (vagy most is, nem tudom).
- Use the Source Luke ! -
Valóban még most sem teljes a kép. Azt azonban el kell ismerni, hogy nagyságrendekkel jobb, mint a 6.0 volt. Minimális különbségek egyébként a GCC-ben is vannak, de ma már lehet olyan ötleted, hogy olyan szabványos kódot írsz, ami gyakorlatilag mindenen fordul. :)
--
http://www.naszta.hu
lehetnek bugok a gcc-ben (bar nem tudom pont mire gondolsz), de ez az msvc-ben nem bug hanem meg sem csinaltak ezeket a featureket.
- Use the Source Luke ! -
Tudom, hogy ezek nincsenek benne implementálva (még), de ezek nélkül azért egész kényelmesen lehet fejleszteni. Ma már - szerintem - minden open source cuccot úgy érdemes írni, hogy lehetőleg a 3 nagy compiler (gcc, msvc 8.0 <=, intel cc) alatt forduljon.
--
http://www.naszta.hu
Tisztán C projekthez semmiképpen nem ajánlom az MSVC-t. Friss tapasztalat!
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods
kicsit lehetne bovebben?
---
Egy jól megállapított probléma félig megoldott probléma.
- Charles Kettering
-1, szintén friss tapasztalat ;)
Cygwin-t használtam eddig, ha néha fordítottam valamit Windows alá, és a binárisnak szüksége van a Cygwin dll-re a futáshoz.
A MinGW-nél ez hogy működik? Lehet önállóan futásképes programot fordítani, vagy ehhez statikus linkelés kell?
Lehet-e csak a C fordítót telepíteni, vagy itt is kell mindenféle GNU program még?
Nekem van olyan projektem, amihez kell a mingwm10.dll, és van olyan is, amihez nem. Meg ne kérdezd hogy miért, mert nem tudom. :)
Akkor kell, ha hasznalod az -mthread link flaget. Ez pedig a "multithreaded exceptions"-hoz kell. Allitolag :-)
Cyg eseteben talan az -mwindows tud segiteni.
Szerk: -mno-cygwin a megoldas.
--
Mind ezek mellett én MS Visual Studio Express-t használnék, ha free kell. Gyorsabbak win alatt általában a kereskedelmi fordítók, az Express-t meg meg lehet hegeszteni úgy, hogy mindent tudjon, amit kell. Platform SDK-t is.
http://www.microsoft.com/express/vc
--
http://www.naszta.hu
+1
Az express változatba OpenMP támogatást is elég egyszerűen be lehet hegeszteni, úgy már ütős
Borland nagyon felejtős, vége, meghalt.
"Platform SDK-t is"
A 2008-as Expresst mar nem kell hegeszteni, alapbol tartalmaz Platform SDK-t (Windows SDK ujabb neven)!
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
Jár a pont.
--
http://www.naszta.hu
Azaz olyan binárist fordít, aminek a futásához nem kell a .NET?
--
Keep it simple, stupid.
Igen. Íme: http://msdn.microsoft.com/en-us/library/zcbsd3cz%28VS.80%29.aspx
--
http://www.naszta.hu
csak ha direkt ugy van irva a kod, akkor kell .NET
---
/* No comment */
Ketchup elementál megidézése a sajt síkra
Ha nem hasznalsz CIL kodot, akkor sosem kellett eddig sem .NET
--
Mivel szokás lefordítani monjduk egy GIMP-et, vagy Python-t?
MinGW-vel.
FYI: A Python inkabb az msvc forditast tamogatja.
--
Köszönöm a válaszokat!
--
Keep it simple, stupid.
Én is MinGW-vel próbálkozok Win alatt, de szerintem ne az igazi:
a lefordított fájl mérete kb. másflészer akkora (24KB), mint amit Borland Turbo C-vel fordítottam (17KB), emellett fele olyan gyors ugyanaz a kód...
--
Azt akarom, hogy az emberek ne kényszerből tanuljanak, hanem azért, mert tudni akarnak.
strip.exe --strip-unneeded -R .comment a.exe
--
Azért a korábban felsoroltakon kívül létezik Win-re az LCC, a Pelles-C, a Watcom-féle C/C++ fordító (asszem mostanában OpenWatcom-nak híjják, és a maga idejében az egyik leggyorsabb kódot fordította), most már mintha menne Win alatt az LLVM-féle CLANG. Választék az van.
Persze, a kerdes az, hogy a leforditando alkalmazas mit tamogat, illetve, ha sajat alkalmazasrol van szo, akkor melyik hasznalata kenyelmesebb.
--
A méret nem feltétlen hiba, de a sebesség kizárt dolog.
Mindkettőnél bekapcsoltad az optimalizációt?
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o
Egyiknél sem tudtam, hogy létezik ilyen... o_O Borland Turbo C IDE-ben csak F9-et nyomtam, gcc pedig a
-Wall
paraméterekkel fordította le.Egyszerű konzol alkalmazás, van benne memória és fájlkezelés is.
Hozzá kell tenni, hogy a Turbo C-vel készített prog WinXP alatt ezt az üzenetet írja ki az első futtatásnál:
C:\WINDOWS\SYSTEM32\HASPDOS.SYS
--
Azt akarom, hogy az emberek ne kényszerből tanuljanak, hanem azért, mert tudni akarnak.
Anélkül nincs sok értelme összehasonlítani.
A gcc-nél -O2 a leggyakrabban használt beállítás, másiknál fogalmam nincs.
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o
linuxon a C fordítót icc-nek hívják