gcc string relocation
Petrik Gergely
spee at freemail.hu
Thu Apr 22 19:02:40 CEST 2004
Babrian Viktor <v at renyi.hu> írta:
> > > > __attribute__ (section((...))) izebigyoval (nem
tudom minek
> > >
> > > Na ilyet meg nem lattam...
> > eleg misztikus dolgok ezek, szabvany C konyvbol ilyesmit nem
> > lehet megtanulni, mert azokban sztem nincs benne. lamer
> > kodgeneratoros windoz programozok ilyet almukban se latnak
> > (amiota windozt programozok, egyszer se lattam ilyesmit ;),
> azert ne szalljunk el, ez egyszeruen gcc specifikus, a C
konyvekben azert
> nem szerepel. Mas foditokban maskent kell megadni,
leginkabb valamilyen
> #pragmaval, ami biztos benne van a C konyvekben is. Tehat
a windoz
> programozok is hasznalnak ilyesmit, csak nem igy hivjak,
es nem irjak fel
> az elektro listara.
kiraly. felreertheto voltam, megerdemlem a kioktatast. a
#pragma onmagaban szabvanyos, de amit beleirsz, az nem az
szvsz. a szabvany c konyvben keresheted a relokalasra
vonatkozo pragma direktivat, vagy hivjuk, ahogy tetszik.
ugyanigy az __attribute__ se igazan van benne a
Kernighan-Ritchie konyvben. es a lamer windoz programozok
NEM hasznalnak #pragma direktivat (_magambol_ indulok ki,
nekem epp eleg ezekbol annyi, amit a generator kikop :).
> Sot a gcc-t is lefordithatom windozra, es akkor mar
elmondthato, hogy a
> 'lamerek' is hasznalhatjak ezt a szintakszist.
es megint magyarazkodok. lamer windoz programozo alatt azt
ertem, aki igazabol nem tud programozni meg annyira se, mint
en, es szereti a kodgeneratoros ocsmanysagok altal kifosott
moslekot (meg se nezni, es tudomast se venni rola).
megnezted mar, mit generalnak a generatorok? ha mar
undorito, legalabb legyen kulturaltan indentalva. es ugyanez
igaz az ilyen cuccokhoz adott szerkesztokben irott kodra is.
megnezem valami kultur editorral, es maris feny derul a
csak a kerdeses tool altal ertelmezheto indentalasi
metodikara. magyarul olvashatatlan elcsuszott sorokat kapok.
ez az osszes szovegszerkeszto kozos nagy hibaja - azt az
allatot kene leloni, aki kitalalta a TAB billentyut, es azt
is, aki a TAB spacing allithatosagat.
> > #define printf printf_P // :)
> >
> > de nem biztos, hogy ennyire egyszeru a dolog. sot,
> > biztosan nem, mert akkor Nektek is eszetekbe jutott volna.
> > de en igy csinalnam, ha lenne pl egy fonokom, aki az
> > asztalra verne, es tegnapra rendelne egy a flashbol
> > printf-elo programot. :)
> Ha jol ertettem az eredeti problemat, akkor az volt a
porblema, hogy
> mikent helyezzuk flashbe a stringet minel kenyelmesebben,
nem pedig
az.
> Legalabbis meg Fuzesi kollega altal hajdanaban feltett
kerdesnek ez volt a
> lenyege.
> de javitson ki barki, ha tevedek.
hurra. irni kell ra egy makrot. ebben a formaban ez nem
tunik tul izgalmasnak. mikor ment ez a thread? megneznem az
archivumban, mert anno intenziven hasznaltam a D gombot...
sokkal izgalmasabb a VF altal (most) felvetett problema,
miszerint van egy vacak printf fuggvenye, ami persze nem tud
flashbol dolgozni. hogy vegyuk ra arra, hogy tudjon?
feluldefinialjuk egy flashbol dolgozo implementacio nevet
printf-re, es kesz? ha a flashbol dolgozo implementacio
megvan valami libben, akkor nekem ugy tunik, ez is
megoldodott, maskulonben meg kell irni, es csak utana lesz
megoldott. de a vararg makrot meg mindig nem ertem, ezert is
szeretnem elolvasni az archivumbol az akkori
hozzaszolasokat. most mar erdekel a tema, valaki megirna,
melyik honapban ment? :)
> > cuccokkal lehessen fejleszteni, mert az ilyenolyan IDE-kkel
> > az utobbi honapokban meggyult a bajom, es elegem van
> > beloluk (nem avr kapcsan, de akkor is).
> Ezekhez az IDEkhez szoktak adni command line fejleszto
eszkozoket is sok
> esetben.
> Nem ismerem az atmel fejlesztoi kornyezeteket, tehat nem
akarok hulyeseget
> mondani, de ha csak az IDEvel van a baj, akkor erdemes
szerintem az
> esetleg letezo parancssoros eszkozoket is kiprobalni, mert
sok esetben a
> gyari forditok jobbak, mint a gcc. Viszont dragabbak ;)
borland c++ builder az aranyos, amitol egnek all a hajam. es
ingyen volt (educational use only, semmi komoly :), de nem
igazan erdekel a parancssoros resze... :)
--
G
More information about the Elektro
mailing list