Re: Tajemná zákoutí jazyka C.

[Jiří Nesvačil]

static FNECO GNECO pole[1]=
{
{0,20,20},
{20,23,30,24,20,20,20,20,20,20}};

Vypada to, ze so do pole o rozmeru jedna tj. pole[1] davam dva prvky, to jsou ty dve slozene zavorky. Tak mi to na prvni pohled prijde.

Ono je vhodne se obcas podivat, jak to kompilator prelozi. I kdyz se to povede, tak to obcas vypada tak, ze to z BIN okopiruje do RAM, aby mohl zajistit, co si prejete. Pritom optimalnejsi je, aby to slo rovnou z bin ci flash.
Pokud se tomu chcete vyhnout, tak v poli jen pointery tj. ne nejake n dimenzionalni prvky to GCC nedokaze udelat bez kopie do RAM. Mozna i dalsi kompilery... .

Jirka

Dne 8. 1. 2016 v 22:27 Michal Gregor napsal(a):
> Podobny problem:
>
> #define FNECO const
> #define GNECO /*empty*/
>
> static FNECO GNECO pole[1]=
> {
> {0,20,20},
> {20,23,30,24,20,20,20,20,20,20}};
>
> Je to C soubor, jde to prelozit a program funguje. Compilator C++ myslim VS 2010.
>
> V projektu jina definice FNECO, GNECO neni. Pisu to z hlavy, mozna tam jsou preklepy. Jak je mozne ze to jde zkompilovat?
>
>
> Michal Gregor
>
>
> Dne 8.1.2016 v 21:56 Ales Prochaska, Divesoft napsal(a):
>> Říkám si, jestli už není na čase přejít na nějaký jiný jazyk s lepší
>> detekcí programátorských chyb :-) :-) :-)
>>
>> Aleš Procháska
>>
>>> Na tohle téma bylo napsáno spousta textu, který většinou vůbec nic
>>> neřeší. Jediná rada je udržovat disciplínu, do pole zapisovat (číst) na
>>> jediném místě, kde se zároveň kontrolují meze. I v ansi C můžete
>>> uplatnit objektový přístup.
>>> C++ je na tom lépe, pole může být chráněno (protected) což si samostatné
>>> metody pro čtení a zápis (z vnějšku třídy) přímo vynutí. Pak můžete
>>> použít řadu vymožeností od přetížení operátorů [], -> * atd, po použití
>>> smart pointerů.
>>> Ale co jsem tak koukal, tak všechny ty moderní vymoženosti, které mají
>>> práci usnadnit a předejít chybám produkují jen nové chyby (při nevhodném
>>> použití), které se hůře hledají.
>>> Takže pokud se vám to rozrůstá do nepřehlednosti, udělejte nový
>>> komplexní návrh a celé to přepište nejlépe do objektů. Ušetříte si
>>> spoustu práce.
>>> Co zde míníte pod pojmem Garbage collector není zcela jasné, může to být
>>> uklízeč nepotřebných sekcí z gnu linkeru, který je dobré používat nebo
>>> automatické uvolňování objektů z haldy, které ansi C ani C++ sice
>>> nepoužívá, ale vše směřuje k tomu, že se tím budeme muset zabývat i na
>>> těch jednočipech. Bohužel.
>>
>>> Mrazík
>>
>>> Dne 8.1.2016 v 14:30 Jiří Nesvačil napsal(a):
>>>> Taky se temto zapisum vyhnu. Radeji to delam v ansi-c pres struct a
>>>> vlozim prvy do struct s odkazy na ne.
>>>>
>>>> Jinak, kdyz jsme u te slozitosti, co delate se stringy ci obecne polem
>>>> na takovem STM cpu v ansi-c ? Nekolik poli ci stringu se da uhlidat, ale
>>>> s rustem.... .
>>>> Ja jsem napriklad predelal vsechny metody na praci se stringy v ansi-c,
>>>> aby pracovaly s max delkou a nekde to nepreteklo. Docela se mi libi i
>>>> pascal notace tj. dostat zde delku na prvni pozici. Garbage collector
>>>> jsem zatim nepouzil, i kdyz to k tomu vede.
>>>>
>>>> Jirka
>>>>
>>>>
>>> _______________________________________________
>>> HW-list mailing list  -  sponsored by www.HW.cz
>>> Hw-list na list.hw.cz
>>> http://list.hw.cz/mailman/listinfo/hw-list
>>
>> _______________________________________________
>> HW-list mailing list  -  sponsored by www.HW.cz
>> Hw-list na list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
>>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list