[Hasse]

Idézet: Nevergone - Dátum: 2005. okt. 12., szerda - 17:46

lyenkor mindig bánkódom picit, hogy az sprintf visszatérési értéke nem az új sztringre mutató pointer. ..

sprintf(...)?buffer:buffer.   

[UfoZ]

Idézet: Hasse - Dátum: 2005. okt. 12., szerda - 18:03

sprintf(...)?buffer:buffer. 

(sprintf(...),buffer)

[h1ghland3r]

Idézet: Nevergone - Dátum: 2005. okt. 12., szerda - 15:08

Akkor sem nyitok új topicot, mert minek... 
Szóval, egy érdekes problémám lenne C nyelvben.

Adott egy konstans, amelyet az elõfordító dolgoz fel, és ezt kellene behelyetessítenem szövegként egy sztringliterálba. Valahogy így:

#define FOO 300
int main () {
  printf ("Ize"FOO"Ize"\n);
}

És ugye, én azt szeretném, ha a kimenet ez lenne: Ize300Ize
A probléma az, hogy az elõfordító így nem akarja az igazságot, mert ugye szám. Úgy elfogadná, hogy a konstans értékét idézõjelek közé tenném, csak az azért nem lenne jó, mert máshol pedig számolok vele, és akkor ott kellene elöbb számmá konvertálgatni mindig, brrr...

Van valami ötletetek, vagy törõdjek bele inkább...? 

Azert halvany off-ot en erzek.     

Mondjuk "token-pasting operator" kulcsszora (vagy valami ilyesmi) kellene rakeresni a forditoprogramod/preprocesszorod doksijaban, es maris lehet okosodni.

[ed101]

Idézet

Halistennek a magyar egyetemeken pascal-t meg c-t tanitanak.... Tanithatnak ezt is, de akkor a vegzosok jo esellyel munkanelkulikent kolan meg kutyatapon elnenek es egesz nap nezhetnek a tevet otthon.

naja, mert nem azokat a fogalmakat kene megtanitani, hogy statically typed, static bind/dynamic bind, prototype based, class based oop, condition system, exception system, functional/sideeffect-free, closure, higher-order function, stb... es utanna azt mondani, hogy itt a C, ez egy statically typed, nem strictly typed, sideeffectes, stb nyelv. es VEGE a C nyelv oktatasanak, mert a szintaxist meg mindenki megszokhatja maga. persze meg lehetne tanitani a villamosmernokoknek is hogyan kell osszerakni a VCR3344 eszkozt, de sokkal egyszerubb megtanitani nekik az elektronikat altalaban es hagyni, hogy beoldoguljanak maguk. (egyebkent meg a BME info kararol tudok csak nyilatkozni, az ELTE progmat hallomasbol sokkal jobb ebbol a szempontbol)

Idézet

Mar ne haragudj de itt most tiz ember (te mondtad) munkaja all szemben egy tobbszaz milliard dollaros uzlettel, es egy irgalmatlan meretu infrastrukturaval.

ha kicsit atlatnad a vilag mukodeset ezt nem hoztad volna fel. a reszletek nelkul ajanlom figyelmedbe a "100 milliard legy nem tevedhet" szolast...

Idézet

Es ameddig tunes-os barataink whitepaper-t meg wiki-t gyartanak, az Internetnek mennie kell, es valamit a befektetok is szeretnenek latni a penzukbol, szuksegunk lesz meteorologiai elorejelzesekre, uj gyogyszerekre ....

a tunes gyakorlatilag egy link-gyujtemeny azokrol a paper-ekrol/gondolatokrol amik szerintuk a szamitastechnikat sokkal jobb alapokra helyezne... de egyebkent van tobb konkret project is.

Idézet

Azert lassuk be a papir sokmindent elbir es azon az oldalon meg konkret (piaci-szakmai szempontbol ertekelheto) eredmenyek nemigen vannak. Tudomanyos eredmenyek lehetnek, de azok csak a kutatokat erdeklik.

nem a tunes a lenyeg, hanem a szemlelet ami atjarja a szamitastechnikai vilagot. pl az a zart gondolkodas ami a valaszodat ihlette. nem mondom, eleg parasztak a postjaim, ami nemileg indokolja ezt, de en meg mindig kiakadok ezen a gondolkodason... pl amikor elkezdenek (annak a sokmilliardos uzletnek a programozoi) veszekedni azon, hogy c vagy java...

Idézet

Analog peldakent az jut eszembe, amikor valaki levezeti annak a lehetoseget, hogy fereglyukakon v. fekete lyukakon keresztul milyen klasszul lehetne idoben v. terben ugrani. Megsem veri senki sem az asztalt, hogy minden mozdithato urjarmuvel celozzuk be a legkozelebbi fekete lyukat es hajra....

hat persze, amikor pl az 1960-as evekben megalkotott lisp nyelvet emlegetem, akkor vszinuleg a levegobe beszelek... es ne feledd, hogy a tunes cuccainak a 2/3-ara van proof of concept...

Idézet

Az, hogy a Lisp megveri a Perl sebessegben kb. olyan hir, minthogy nagyanyam finomabb porkoltet foz, mint en...

miert is? a perl 3x ujabb nyelv es mindenhol azt emlegetik mint referenciat _regexp_ teren...

Idézet

A masik bevagott linked meg abszolut lol. Kerestel google-ben es el sem olvastad

igen es erre egeszen konkretan felhivtam a figyelmet: "random google result" mert arra volt valasz, hogy lisp-et nem lehet hasznalni clusteringre...

egyebkent azota talatam meg egy erdekes lisp projectet: a Hubble scheduleret is lispben irtak, ami kiszamolja mikor merre forduljon, mert ugye az nem olcso dolog.

Idézet

A franya reszletekkel is kellene foglalkozni es azt is leirni, hogy mi van most, mi lesz 1-2-5-10 ev mulva. Legalabb hozzavetolegesen.

a tunes review subprojectje pont arrol szol, hogy mi van most. a tobbi meg arrol, hogy mi kene legyen (szerintuk)

Idézet

Namost megneztem a cikk vegen a hivatkozasokat. A legujabb talan 99-es (ok maguk nem irtak datumot a cikkre, pedig jol jonne neha). A leirt tervezetbol en arra kovetkeztetek, hogy kb. 3-4 eves a cikk.

minel oregebb, annal erdekesebb szerintem. pl amikor a C++ megszuletett, mint otlet (!) 198x, akkor mar regen mukodott a CLOS (Common Lisp Object System), ami kb 3x profibb dolgokat tud, mint a C++-os class based OOP modell.

na mind1, annyi legynek biztos igaza van...

[Hasse]

Idézet: ed101 - Dátum: 2005. okt. 14., péntek - 11:16

ha kicsit atlatnad a vilag mukodeset ezt nem hoztad volna fel. a reszletek nelkul ajanlom figyelmedbe a "100 milliard legy nem tevedhet" szolast...

Mármint a világ mûködését, ahogy az egyetemen belülrõl látszik? Mert a szoftveriparban két alapvetõ prioritás van, profitmaximalizálás és kockázatcsökkentés, egy architekt meg az utóbbi miatt nem kedveli a pozitív referencia és háttérinfrastruktúra nélküli technológiákat, akár jók azok, akár nem.

[ed101]

Idézet

Mert a szoftveriparban két alapvetõ prioritás van, profitmaximalizálás és kockázatcsökkentés, egy architekt meg az utóbbi miatt nem kedveli a pozitív referencia és háttérinfrastruktúra nélküli technológiákat, akár jók azok, akár nem.

en is hasonlora gondoltam, bar kicsit mashogy fogalmaztam volna meg. persze egy manager sosem azt fogja nezni, hogy milyen produktiv egy embere. neki sokkal fontosabb, hogy ha az egyik emberet eluti a villamos vagy elhagyja az asszony, akkor befuccsol-e a project vagy sem.

szoval hozza kell tennem, hogy a "jo" szo alatt en azt ertem jelen beszelgetesben, hogy produktivabb tudok lenni (en) egy programnyelven. nem azt, hogy mennyire elfogadott vagy elterjedt. es igen, adott szituacioban a java/c++/stb lehet "jobb" a lisp/(random "egzotikus" nyelv)-nel a peremfelteteleket is figyelembe veve. csak ez ritka... (allitom en azok utan, hogy valaha azt hittem, hogy a c++ mennyire jo)

[dexion432]

Sziasztok,

nem nagyon vagyok otthon a C/C++ témában, de egy kérdésem lenne:

Tudom, hogy egzotikus meg minden, de ha jól tudom, a UNIX kernel-t C-ben irták anno, meg talán még ma is abban írják. Természetesen nem tudom, hogy a szálkezelést stb hogyan oldották meg, de azt gondolom, hogy nem nagyon van olyan probléma, amit ne lehetne C/C++-ban megoldani, esetleg csak sokkal több idõ alatt, mint összekattintani valamit egy .NET designerben.

Tévedek?

... a sebesség pedig nem feltétlen a legfontosabb kérdés sokszor... vegyél kettõvel nagyobb processzort, ha lassú, sokszor ez a válasz.
Kifizetõdõbb lassabb, de stabil kódot irni, mint olyat, ami jó gyorsan jó sokat hibázik, nem ?

Szerkesztette: dexion432 2005. 10. 19. 14:59 -kor

[alvaro]

Idézet: dexion432 - Dátum: 2005. okt. 19., szerda - 14:58

...vegyél kettõvel nagyobb processzort, ha lassú, sokszor ez a válasz.

alapvetoen igaz valahol, de ez manapsag sajna mar nem mukodik - a "kettovel nagyobb processzor" egyre inkabb azt jelenti, hogy bizony eppen a szalkezelessel kell majd foglalkoznod, kulonben semmit nem ersz vele.
hanem en baromi nagy off-ot batorkodom ide bedobni, elnezest is kerek erte mindenkitol, de ha valaki elmondana, hogyan talalok en egy mukodo, up to date gcc win32 buildet, mindenfele libekkel (perpill hang es tcp/ip lenne a legfontosabb), es hogy azt hogyan helyezzem uzembe... aztan talan majd beszallok a magas roptu vitaba. tolem torolheti barmilyen mod a hozzaszolasom, csak legyen egy linkem ez nagyon misztikus, vagy csak nekem van antitalentumom a neten valo kereseshez, de mar orakat csextem el  az eletembol ezzel, es semmi eredmeny

[Hasse]

Idézet: alvaro - Dátum: 2005. okt. 31., hétfõ - 14:19

...de ha valaki elmondana, hogyan talalok en egy mukodo, up to date gcc win32 buildet, mindenfele libekkel (perpill hang es tcp/ip lenne a legfontosabb),...

https://forum.hwsw.hu/index.php?showtopic=6...dpost&p=3455663

Ezek kozott nincs hasznalhato?

[Haderach]

ismerkedett mar valaki a D nyelvvel?

[marczi]

Én megnéztem, fõleg most az 1.0 miatt, de nem igazán tudtam meggyõzni magam arról, hogy egy sokadik C/Java/C# jellegû nyelvet elkezdjek tanulni.

[Cibet]

Én is belekukkantottam. Tetszik, hogy lehet választani GC és saját memóriakezelés közül. De hát ugye én integrált, GUI fejlesztõkörnyezet nélkül meg se tudok mozdulni. 

[marczi]

Idézet: Cibet - Dátum: 2007. jan. 23., kedd - 18:04

Én is belekukkantottam. Tetszik, hogy lehet választani GC és saját memóriakezelés közül. De hát ugye én integrált, GUI fejlesztõkörnyezet nélkül meg se tudok mozdulni. 

Hát ja, öregszik az ember

[Haderach]

Idézet: Cibet - Dátum: 2007. jan. 23., kedd - 19:04

Én is belekukkantottam. Tetszik, hogy lehet választani GC és saját memóriakezelés közül. De hát ugye én integrált, GUI fejlesztõkörnyezet nélkül meg se tudok mozdulni. 

mindig is meg akartam kerdezni valakitol, hogy mennyire skalazodik a visual studioba(vagy akarmi mas GUIs csodaba) epitett C/C++ make rendszer? mondjuk elkepzelheto, hogy egy nehany millio soros projekt meg mindig elszaladgal a visual studio(vagy akarmi mas) altal generalt make rendszerrel anelkul, hogy jelentos bevatkozast igenyelne a fejlesztoktol?

[Dead6nail]

Idézet: Haderach - Dátum: 2007. jan. 23., kedd - 20:39

mindig is meg akartam kerdezni valakitol, hogy mennyire skalazodik a visual studioba(vagy akarmi mas GUIs csodaba) epitett C/C++ make rendszer? mondjuk elkepzelheto, hogy egy nehany millio soros projekt meg mindig elszaladgal a visual studio(vagy akarmi mas) altal generalt make rendszerrel anelkul, hogy jelentos bevatkozast igenyelne a fejlesztoktol?

A kérdés nem jó. A make rendszer (nagyjából) annyit csinál, hogy megmondja a fordítónak, hogy milyen file-okat, milyen paraméterekkel kell lefordítani és linkelni. Az hogy mekkora a file mérete nem befolyásolja magát a fordítást ütemezõ programot. Tehát, az hogy egy make rendszer rosszul skálázódna nem nagyon következhet be. Persze nagy projektek esetén szempont lehet, hogy egyes fordítási-linkelési megoldások milyen elõnyökkel-hátrányokkal bírnak.

[Haderach]

Idézet: Dead6nail - Dátum: 2007. jan. 25., csütörtök - 16:53

A kérdés nem jó. A make rendszer (nagyjából) annyit csinál, hogy megmondja a fordítónak, hogy milyen file-okat, milyen paraméterekkel kell lefordítani és linkelni. Az hogy mekkora a file mérete nem befolyásolja magát a fordítást ütemezõ programot. Tehát, az hogy egy make rendszer rosszul skálázódna nem nagyon következhet be. Persze nagy projektek esetén szempont lehet, hogy egyes fordítási-linkelési megoldások milyen elõnyökkel-hátrányokkal bírnak.

tudom mit csinal a make, alapvetoen arra voltam kivancsi, hogy ha a fejlesztok mindig csak hozzaadjak a projektjukhoz az ujabb es ujabb libeket, header es source fileokat, es mondjuk tobben dolgoznak egy projekten, akkor az automatikusan generalt make fileok mondjuk egy 30000 filebol allo 7 forditoval forditott projekt eseten jol mukodnek, vagy elobb utobb elkerulhetetlen lesz kezzel igazgatni oket.

[Hasse]

Idézet: Haderach - Dátum: 2007. jan. 25., csütörtök - 16:10

tudom mit csinal a make, alapvetoen arra voltam kivancsi, hogy ha a fejlesztok mindig csak hozzaadjak a projektjukhoz az ujabb es ujabb libeket, header es source fileokat, es mondjuk tobben dolgoznak egy projekten, akkor az automatikusan generalt make fileok mondjuk egy 30000 filebol allo 7 forditoval forditott projekt eseten jol mukodnek, vagy elobb utobb elkerulhetetlen lesz kezzel igazgatni oket.

Ilyet eleve több projektbe rak az ember (ezért van a workspace/solution szint) a dependencyket meg kézzel igazgatja, projektétõl eltérõ programnyelvû fájlhoz (mint pl. az eventlog resource) értelem szerint kézzel kell beírni a fordításhoz szükséges sort, meg persze post-build-eventnek beír az ember pár copy parancsot szintén kézzel. De önmagában a fordításnál mindegy, hogy most két fájl van, vagy kétmillió.

[Haderach]

Idézet: Hasse - Dátum: 2007. jan. 25., csütörtök - 18:27

Ilyet eleve több projektbe rak az ember (ezért van a workspace/solution szint) a dependencyket meg kézzel igazgatja, projektétõl eltérõ programnyelvû fájlhoz (mint pl. az eventlog resource) értelem szerint kézzel kell beírni a fordításhoz szükséges sort, meg persze post-build-eventnek beír az ember pár copy parancsot szintén kézzel. De önmagában a fordításnál mindegy, hogy most két fájl van, vagy kétmillió.

erre voltam kivancsi, hogy mennyi kezimunkat igenyel, koszonom a valaszt. Mint mondtam a maket ismerem, a makefile-generalo rendszer erdekelt:)

[Hasse]

Idézet: Haderach - Dátum: 2007. jan. 25., csütörtök - 20:11

erre voltam kivancsi, hogy mennyi kezimunkat igenyel, koszonom a valaszt. Mint mondtam a maket ismerem, a makefile-generalo rendszer erdekelt:)

Erre szoktam mondani, hogy a Visual C++ nem RAD eszköz.

[Haderach]

1: grat a ****** kftnek a reklamert
2: begepelni nem er!
reklam