On 05.05.2012 19:47, Jerry1111 wrote:

> Nie jest za darmo, jesli wstawi gdzies ciag znakow "virtual" (bo nie wie
> ze nie wolno) i 3 dni bedzie szukal czemu "Hello world" nie miesci sie
> do flasha.
Moją magisterkę na ARMa z 8k flash i 32k flash piszę w hardcore C++ z:
- obiektami
- szablonami
- metaprogramowaniem (łącznie z testem, czy boost::mpl zadziała)
W planach właśnie dodanie polimorfizmu dynamicznego.

Dopisałem do projektu następujące klasy:
class foo{
public:
virtual void f(){uart_print("foo\r\n");}
};
class bar:public foo{
void f(){uart_print("bar\r\n");}
};
class foobar:public bar{
void f(){uart_print("foobar\r\n");}
};
class oof:public foo{
void f(){uart_print("oof\r\n");}
};

I do main dopisałem:
int ll=uart_read_int();
foo f;
bar b;
foobar fb;
oof o;
foo* ff;
if(ll==1){
ff=&f;
}else if(ll==2){
ff=&b;
}if(ll==3){
ff=&fb;
}else{
ff=&o;
}
ff->f();

Binarka przytyła po tym o 200 bajtów:
text data bss dec hex filename
4012 8 168 4188 105c firmware.elf
4212 8 168 4388 1124 firmware2.elf

- 28 bajtów to sam wypisywany tekst
- po 8 bajtów na metodę [1]
- 48 bajtów dodatkowego kodu w main (o tym za chwilę)
- po 16 bajtów na vtable dla klasy

W main został wygenerowany następujący kod:
0x000006a4 <+56>: ldr r3, [pc, #224] ; (0x788 <main()+284>)
0x000006a6 <+58>: str r3, [sp, #4]
0x000006a8 <+60>: ldr r3, [pc, #224] ; (0x78c <main()+288>)
0x000006aa <+62>: str r3, [sp, #8]
0x000006ac <+64>: ldr r3, [pc, #224] ; (0x790 <main()+292>)
0x000006ae <+66>: str r3, [sp, #12]
0x000006b0 <+68>: ldr r3, [pc, #224] ; (0x794 <main()+296>)
0x000006b2 <+70>: str r3, [sp, #16]
0x000006b4 <+72>: ldr r3, [r4, #0]
//czyli po 2 instrukcje na stworzenie obiektu na stosie

0x000006b6 <+74>: cmp r3, #1
0x000006b8 <+76>: beq.n 0x6c6 <main()+90>
0x000006ba <+78>: cmp r3, #2
0x000006bc <+80>: beq.n 0x6ca <main()+94>
0x000006be <+82>: cmp r3, #3
0x000006c0 <+84>: bne.n 0x6ce <main()+98>
0x000006c2 <+86>: add r0, sp, #12
0x000006c4 <+88>: b.n 0x6d0 <main()+100>
0x000006c6 <+90>: add r0, sp, #4
0x000006c8 <+92>: b.n 0x6d0 <main()+100>
0x000006ca <+94>: add r0, sp, #8
0x000006cc <+96>: b.n 0x6d0 <main()+100>
0x000006ce <+98>: add r0, sp, #16
// 13 instrukcji na obsłużenie 4 if-else

0x000006d0 <+100>: ldr r3, [r0, #0]
0x000006d2 <+102>: ldr r3, [r3, #0]
0x000006d4 <+104>: blx r3
// 3 instrukcje na wywołanie funkcji wirtualnej

To gdzie są te straszne koszta 'virtual'?


[1]
Dump of assembler code for function foo::f():
0x00000670 <+0>: ldr r0, [pc, #4] ; (0x678 <foo::f()+8>)
0x00000672 <+2>: b.w 0x3b4 <uart_print(char const*)>
0x00000676 <+6>: nop
0x00000678 <+8>: lsrs r7, r3, #18
0x0000067a <+10>: movs r0, r0

--
Pozdrawiam
Michoo

do góry

On 2012-05-05 21:39, Jerry1111 wrote:
>> Tym fajniej busi być debugować te same błedy za każdym razem.
> Przeciez napisalem ze _wszystko_ jest pisane od nowa.

No właśnie.

>> Jakiej transformacji? ScopedWhatever masz za 30 sekund w kodzie. Już.
>> Działa. 0 zonków.
> Zagwarantujesz? Znaczy przyjmiesz fakture (i ja zaplacisz) za jeden
> dzien pracy jesli pracownik, ktory dobrze zna C, przyszedl do naszej
> firmy tydzien temu i _nie_wiem_ jakie ma pojecie o C++, jesli on straci
> dzien bo mu to nie zadziala w 30 sekund?

Co ja mogę poradzić na biędę na rynku pracy? Jeśli twój target to
studenci mizernych uczelni jako pracownicy to nie masz wyjścia. Znam
przynajmniej kilka firm w okolicy które były zmuszone robić gówno, bo
absolwent tylko w tym grzebać potrafi.

> Ja byl bym ostrozny ze
> stwierdzeniem typu '30 sekund i nie bedzie problemu'. W 30 sekund nawet
> tego nie skompilujesz, nie mowiac juz o znalezieniu odpowiednich plikow
> zrodlowych.

W 30 sekund jestem w stanie to napisać i użyć przy okazji kompilując.
Cały kod źrodłowy podałem kilka postów wcześniej. Szukasz dziury w całym.

>> Pięknie ujmujesz poziom kwalifikacji przeciętnego klepacza firmware :)
> Pieknie? A moze realnie?

Tu się zgadzam w 100%. Zazwyczaj jak podnoszę temat C++ na uC to dostaje
po ryju (z braku argumentu) od przeciętnego lemminga, najczęsciej z
gatunku '51. Zaczyna to być nawet zabawne. Wiem, złośliwy jestem.

> Rozmawiamy o kims kto zna C, niekoniecznie C++. To Ty twierdzisz ze nie
> bedzie problemu przy przesiadce...

Tu nie ma przesiadki. Tu jest dodatek.

>> Słusznie. Dzieki takiem podejściu zawsze zaczynasz od int main() { } i
>> odkrywasz kwadratowe koła za każdym razem.
> Jesli za kazdym razem kod idzie do innego klienta, to troche nielegalnie
> byloby uzyc stary kod od innego klienta - nie mam kasy na wloczenie sie
> po sadach. Jest udokumentowane ze calosc powstaje od nowa i nie ma
> problemu.

Dorzucasz kolejny utajniony argument: otwartość źródeł i handel nimi.
Nie było o tym mowy.

Jeśli miałbym od Ciebie kupić kod wręcz zażądał bym aby kod był już
testowany wczesniej a nie pisany od zera. Może ja specyficzny jestem
klient, ale jakoś nie wierze na słowo honoru że pisząc od 0 nie
popelniasz bledow. No nie wierzę i już.

> I prosze nie odpowiedz ze to znowu jest ukryta wiedza - po prostu (tak
> jak i z Matlabem) _zalozyles_ sobie cos, co sie nie sprawdzilo.

Bzdura. Najpierw wyciągasz argument o tym że przypadkowo robisz
softwareowo kawalek hardware (kontroler przerwań), a potem wymyślasz
dodakowy waunek brzegowy o tym że musisz pokazaź źródła. Za chwile
dowiem się że masz klientów którzy robią grep class na plikach i nie da
się. Za dużo tego pojawia się z nienacka. Nierozmawiam o *twoich*
specyficznych problemach tylko o tym że do wiekszości projektów uC C++
można stosować (o ile jest kompilator).

>> Oczywiście, jesli nie narobiłeś straszliwej kupy w C to skompiluje się
>> jako C++.
> Miala byc identyczna. Bezwarunkowo.

Nikt o tym nie mówił. Zacytuje sam siebie: "Większośc kodu przekompiluje
się na tyle gładko [...]". Co do problemów to wszelkiego rodzaju gówna
typu int * = a, gdzie a to char * itp.

>> Nie, z dokładnością do kupy w kodzie. Zazwyczaj wychodzi na zdrowie jej
>> poprawienie.
> j.w., mialo byc bezwarunkowo.

Nie.

> Wyciagasz dosc duzo wnioskow bez posiadania wystarczajacej ilosci danych
> - to jest odwazne.

Głupie raczej. Tym bardziej że widzę ewolucje argumentacji.

> Alez ja wcale nie mam zamiaru tego zrobic. C++ lubie i uzywam. Po prostu
> Ty chcesz przekonac p.m.e. ze C jest be, a C++ jest cacy.

Moim zadaniem jest pokaząc że *niektóre* konstrukcje z C++ nadają się na
uC w przeciwieństwie do "reszty świata" która zaczeła tą dyskusję od
opierdolenia C++ za obiektowość, dziedziczenie i generowanie za dużego
kodu co ma się nijak: a) do moich intencji, b) do faktów.

> Jesli chodzi o poprzednie watki dotyczace Ady: odpowiedz na pytanie, czy
> dla dobrego programisty ma znaczenie w jakim jezyku cos napisze?

Zasadnicze. Powodzenia w przepisywaniu Prologa na C i odwrotnie.
Większość różnic w paradygmatach programowania jest poważna. Ada jest na
szcęscie w tej samej rodzinie co C, ponadto bliski jej VHDL w środowisku
elektroników jest znany. Więc mozna sie pokusić o stwierdenie że C->ADA
jest realny nawet automatycznie. Zaznaczam że z tego wynika że problemy
znane z C dotykają też ADY.

>> Mi potrzeba abstrakcji, destrutorów, traits wyszła na AVR. Dzieki temu
>> ostatnio firmware (specyficzny, RT) napisałem w 0.5 dnia wykorzystując
>> 90% kodu optymalnie (tzn w C nie dało by się lepiej, musiałbym dlubac w
>> ASM) i 10% dopisując.
> No i dla mnie taki kod o kant pupy rozbic. Ani test harness nie ma

Że czego nie ma ? Testów? Unit testów? Mój kochany, *każdy* kawalek kodu
ktory kompiluje na AVR kompiluje tez na x86 z pełnym pokryciem unit
testami poza dostepem do sprzetu (który czasem daje radę emulowac). Czy
aby nie wyciągasz odważnyh wniosków bez posiadania wystarczającej ilości
danych?

Ostatnio spróbowałem google test/mock i chyba przy tym zostanę.
Programiści C mogą lizać szybkę.

>, ani
> kodu legalnie nie uzyje.

G. pradwa. Zalezy od licencji. Ja np. nie sprzedaje kodu tylko wsad.
Inny sprzedaje zaprogramowane procesory. Inny pisze kod półotwarty. Twój
problem jest specyficzny.

> Poza tym jesli chodzi o 'optymalnie' to bym uwazal: u nas w firmie jest
> wiedza jak ukladac pojedyncze instrukcje w C zeby uzyskac pozadany efekt
> od optymalizatora. Kod w C sie wykona tak samo, tylko w innym czasie.
> Jest to tez powod dlaczego uzywamy 2.5 letniej wersji kompilatora a nie
> najnowszej - bo optimizer znamy juz na wylot z wszystkimi jego fanaberiami.

Czas jednak pisać w asm. Mówie serio, używanie kompilatroa tylko po to
aby obejść jego moduł optymalizacyjny jest z definicji porażką narzedzia
i metodyki.

> To jeszcze jezyki non-managed sa na PCta uzywane? (tak wiem, pewnie
> 'duzy system' to cos wieksze od PCta ;-) )

Są. Jezyki managed mają kilka problemów które przeszkadzają w
aplikacjach obrabiających dużo danych bądź kierunkowanych na szybkość.

> Pytam serio, bo juz jakis czas nie widzialem wiekszej _nowej_ aplikacji
> nie napisanej w czyms managed.

Nie piszę *nowej* aplikacji. C++ jest używany powszechnie w EDA (nie,
nie piszę o SystemC, mówię o core apliakcji).

> Musisz zaakceptowac ze rzeczywistosc nie jest idealna. Zycie stanie sie
> latwiejsze ;-)

Wlasnie dlatego rezygnuje z gołego C. Rzeczywistość jest taka że w C++
jest łatwiej. Od AVR po klaster. Ze wszystkimi jego wadami.

do góry

On 05.05.2012 22:59, Sebastian Biały wrote:

> W 30 sekund jestem w stanie to napisać i użyć przy okazji kompilując.
> Cały kod źrodłowy podałem kilka postów wcześniej. Szukasz dziury w całym.
Ja używam trochę bardziej rozbudowanej struktury, żeby umożliwić
rekurencyjne wywołania:

struct scoped_lock
{
scoped_lock(){tmp=SREG;cli();}
~scoped_lock(){SREG=tmp;}
protected:
uint8_t tmp;
};


--
Pozdrawiam
Michoo

do góry

On 2012-05-05 23:06, Michoo wrote:
>> W 30 sekund jestem w stanie to napisać i użyć przy okazji kompilując.
>> Cały kod źrodłowy podałem kilka postów wcześniej. Szukasz dziury w całym.
> Ja używam trochę bardziej rozbudowanej struktury, żeby umożliwić
> rekurencyjne wywołania:

Mam aktualnie w kodzie na ARMa unique_critical_section z semantyką
podobną do unique_ptr. Przyznaje że tylko znajomy programista C++
pokazał palcem gdzie robi się sei() ... Zawodowcy w C polegli. A kod
mial tylko kilkaset linijek :/

do góry

Hello Jerry1111,

Saturday, May 5, 2012, 10:39:34 PM, you wrote:

>>> Jesli za kazdym razem kod idzie do innego klienta, to troche
>>> nielegalnie byloby uzyc stary kod od innego klienta - nie mam kasy na
>>> wloczenie sie po sadach.
>> Naprawdę masz taki problem?
> Zalezy jaki klient. Sa i tacy co chca zeby _calosc_ informacji zostala
> kompletnie usunieta po zakonczeniu roboty (z reguly zaczyna sie dyskusja
> jak sie tego pozbyc z backupow serwerow). Klient nasz Pan.
> Sa tez klienci gdzie rzeczy standardowe uzywamy swoje bez problemu, no
> bo ile mozna pisac roznych driverow do UART na jeden procek? ;-)

Ale to jest jakieś nieporozumienie - ochrona praw producenta nie sięga
tak daleko. Ochronie podlegają równiez prawa autora.

Na przykład ja zawsze zastrzegam projektując jakąkolwiek elektronikę,
że klient otrzymuje _niewyłączne_ prawo do korzystania z projektu.
Przecież nie wymyślę nowej konfiguracji przetwornicy czy też nie
policze inaczej transformatora dla podanych parametrów.

Uprzedzając: żylem 20 lat z programowania i tu też zawsze bylo podobne
zastrzeżenie - uprzedzałem klientów, że o ile rzeczy, które sa
unikalnego dla niego można trakttować na wyłączność, to sposoby
realizacji - jako nieunikalne - nie dają się zastrzec. Klienci na
przykład chcieli zastrzec interfejs. To tlumaczę, że np. układ pól,
przycisków i sposób nawigacji są uniwersalne i nie mogę go uznać za
zastrzeżony tylko dla nich, bo to byłoby absurdem.

(tak, wiem - Apple i inni patentują takie pierdoły, że zęby bolą)

--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

do góry

Dnia 05-05-2012 o 22:50:52 Michoo <m...@v...pl> napisał(a):


>
> Dopisałem do projektu następujące klasy:

[snip kod]

> Binarka przytyła po tym o 200 bajtów:

[snip szczegóły]

Nie będzie to żaden argument w dyskusji na temat metod wirtualnych, ale z
ciekawości do małego programu w C+asm (na PIC24) dopisałem następujące
wiersze:

const char msg1[] = "foo\r\n";
const char msg2[] = "bar\r\n";
const char msg3[] = "foobar\r\n";
const char msg4[] = "off\r\n";

Następnie w main():

const char *msg;
int ll = recv(0); /* odczyt z czegoś innego niż uart, nieistotne z czego,
0 to numer kanału */

if (ll == 1) {
msg = msg1;
} else if (ll == 2) {
msg = msg2;
} if (ll == 3) { /* tuś się chyba pomylił, ale zostawiłem bez
else, żeby było tak samo */
msg = msg3;
} else {
msg = msg4;
}
uart_send_str(msg);

Przy -O0 binarka zwiększyła się z 1452 do 1575 bajtów (123 bajty).
Przy -Os binarka zwiększyła się z 1197 do 1269 bajtów (72 bajty).

Po poprawieniu buga z "else":
-O0 : 1452 do 1578 (126)
-Os : 1197 do 1287 (90)

Ogólna zmiana przy włączeniu optymalizacji jest mała, bo to program tylko
do testowania sporego kawałka kodu pisanego w asemblerze i C tam mało jest.

Sam nie wiem czy i jakie wnioski z tego wyciągać.

ae

do góry

On 05/05/2012 22:34, RoMan Mandziejewicz wrote:
> Hello Jerry1111,
>
> Saturday, May 5, 2012, 10:39:34 PM, you wrote:
>
>>>> Jesli za kazdym razem kod idzie do innego klienta, to troche
>>>> nielegalnie byloby uzyc stary kod od innego klienta - nie mam kasy na
>>>> wloczenie sie po sadach.
>>> Naprawdę masz taki problem?
>> Zalezy jaki klient. Sa i tacy co chca zeby _calosc_ informacji zostala
>> kompletnie usunieta po zakonczeniu roboty (z reguly zaczyna sie dyskusja
>> jak sie tego pozbyc z backupow serwerow). Klient nasz Pan.
>> Sa tez klienci gdzie rzeczy standardowe uzywamy swoje bez problemu, no
>> bo ile mozna pisac roznych driverow do UART na jeden procek? ;-)
>
> Ale to jest jakieś nieporozumienie - ochrona praw producenta nie sięga
> tak daleko. Ochronie podlegają równiez prawa autora.

Ja nie mam nic przeciwko - klient nasz pan. Tak chce, tak ma, taka
bedzie tez faktura. Przeciez nie powiem nie ;-)
Dla niektorych klientow jest to wazne, dla innych nie ma znaczenia. Byl
jeden klient, gdzie przy dyskusji o kodzie zrodlowym padlo
sdtwierdzenie: "Fabryka bedzie wiedziala jak to zaprogramowac? Tak? No
to mi kod zrodlowy nie potrzebny - jak cos bede chcial zmienic to mi to
zmienicie".

> Na przykład ja zawsze zastrzegam projektując jakąkolwiek elektronikę,
> że klient otrzymuje _niewyłączne_ prawo do korzystania z projektu.
> Przecież nie wymyślę nowej konfiguracji przetwornicy czy też nie
> policze inaczej transformatora dla podanych parametrów.

To jest roznie. U mnie tematy sa tak rozne od siebie, ze tego typu
decyzje sa indywidualne dla kazdego projektu.

> Uprzedzając: żylem 20 lat z programowania i tu też zawsze bylo podobne
> zastrzeżenie - uprzedzałem klientów, że o ile rzeczy, które sa
> unikalnego dla niego można trakttować na wyłączność, to sposoby
> realizacji - jako nieunikalne - nie dają się zastrzec. Klienci na
> przykład chcieli zastrzec interfejs.

Ano mielismy jednego co chcial - zastrzeglismy. Znaczy klient zastrzegl
sam, mysmy mu cala papierkologie przygotowali.

> To tlumaczę, że np. układ pól,
> przycisków i sposób nawigacji są uniwersalne i nie mogę go uznać za
> zastrzeżony tylko dla nich, bo to byłoby absurdem.

Jak placi? Prosze bardzo, pomozemy.

--
Jerry1111

do góry

On 05.05.2012 23:54, Andrzej Ekiert wrote:
> Dnia 05-05-2012 o 22:50:52 Michoo <m...@v...pl> napisał(a):
>
>
>>
>> Dopisałem do projektu następujące klasy:
>
> [snip kod]
>
>> Binarka przytyła po tym o 200 bajtów:
>
> [snip szczegóły]
>
> Nie będzie to żaden argument w dyskusji na temat metod wirtualnych, ale
> z ciekawości do małego programu w C+asm (na PIC24) dopisałem następujące
> wiersze:
>
[...]
Tylko zauważ, że chciałem tu zaprezentować koszt związany z funkcjami
wirtualnymi - użycie klas i funkcji wirtualnych do wypisywania kilku
napisów to 'trochę' głupi pomysł.

Odpowiednikiem funkcji wirtualnych z którym się spotkałem w C jest
wskaźnik na funkcję a z wtedy użycie metod wirtualnych to dodatkowy
koszt VTABLE.

> } if (ll == 3) { /* tuś się chyba pomylił, ale zostawiłem bez else, żeby
> było tak samo */
Rzeczywiście się pomyliłem pisząc kod, ale w poście statystyki są dla
poprawionego kodu, przeczyłem sam kod.

>
> Przy -O0 binarka zwiększyła się z 1452 do 1575 bajtów (123 bajty).
> Przy -Os binarka zwiększyła się z 1197 do 1269 bajtów (72 bajty).
+ 40 bajtów Os
+ 128 bajtów O0

>
> Po poprawieniu buga z "else":
> -O0 : 1452 do 1578 (126)
> -Os : 1197 do 1287 (90)
+ 72 bajty Os
+ 132 bajty O0

Kompiluję na gcc-4.7.0 z:

COMMON_FLAGS= -ggdb -Os $(INCLUDES) -mcpu=cortex-m3 -mthumb
-D__thumb2__ -msoft-float -mfloat-abi=soft
CXXFLAGS=$(COMMON_FLAGS) -std=gnu++11 -fno-exceptions -fno-rtti

>
> Ogólna zmiana przy włączeniu optymalizacji jest mała, bo to program
> tylko do testowania sporego kawałka kodu pisanego w asemblerze i C tam
> mało jest.
>
> Sam nie wiem czy i jakie wnioski z tego wyciągać.
>
Że kod w THUMB jest wydajniejszy niż w PIC32 ;) I że hardcore c++ bez
optymalizacji jest małą masakrą - całość przy O0 spuchła do 8176 -
prawie 2 razy (a przebudowałem tylko projekt, bez bibliotek).

--
Pozdrawiam
Michoo

do góry

On 05/05/2012 21:59, Sebastian Biały wrote:
> Co ja mogę poradzić na biędę na rynku pracy? Jeśli twój target to
> studenci mizernych uczelni jako pracownicy to nie masz wyjścia. Znam
> przynajmniej kilka firm w okolicy które były zmuszone robić gówno, bo
> absolwent tylko w tym grzebać potrafi.

ROTFL... jedna z najlepszych uczelni na swiecie 500 metrow (a raczej
jardow) z prawej i nie mam wyjscia ;-)
Prosze - zrozum ze nie wszystkie firmy/sytuacje/realia sa takie same u
Ciebie i u mnie.

>> Ja byl bym ostrozny ze
>> stwierdzeniem typu '30 sekund i nie bedzie problemu'. W 30 sekund nawet
>> tego nie skompilujesz, nie mowiac juz o znalezieniu odpowiednich plikow
>> zrodlowych.
>
> W 30 sekund jestem w stanie to napisać i użyć przy okazji kompilując.

Znowu prawda, ale mierzysz swiat pod siebie. Stwierdzilem ze z
przesiadka nie bedzie problemu, ale w 30s wliczyles swoje doswiadczenie,
a nie brak doswiadczenia kogos zielonego.

>>> Słusznie. Dzieki takiem podejściu zawsze zaczynasz od int main() { } i
>>> odkrywasz kwadratowe koła za każdym razem.
>> Jesli za kazdym razem kod idzie do innego klienta, to troche nielegalnie
>> byloby uzyc stary kod od innego klienta - nie mam kasy na wloczenie sie
>> po sadach. Jest udokumentowane ze calosc powstaje od nowa i nie ma
>> problemu.
>
> Dorzucasz kolejny utajniony argument: otwartość źródeł i handel nimi.
> Nie było o tym mowy.

Nie bylo mowy ze pisze dla idei.

> Jeśli miałbym od Ciebie kupić kod wręcz zażądał bym aby kod był już
> testowany wczesniej a nie pisany od zera. Może ja specyficzny jestem
> klient, ale jakoś nie wierze na słowo honoru że pisząc od 0 nie
> popelniasz bledow. No nie wierzę i już.

Nie ma problemu - dostalbys skladanke z naszych bibliotek. Tu nie ja
decyduje jak cos jest robione. Ja tylko rekomenduje dla klienta, a
decyduje klient.

>> I prosze nie odpowiedz ze to znowu jest ukryta wiedza - po prostu (tak
>> jak i z Matlabem) _zalozyles_ sobie cos, co sie nie sprawdzilo.
>
> Bzdura. Najpierw wyciągasz argument o tym że przypadkowo robisz
> softwareowo kawalek hardware (kontroler przerwań),

Alez ja specjalnie wzialem 'ciekawy przypadek' kodu, a nie kolejny
sterownik wyswietlacza czy czegos tam innego.

> a potem wymyślasz
> dodakowy waunek brzegowy o tym że musisz pokazaź źródła.

Powiem wiecej - w tym akurat projekcie klient zazyczyl sobie usuniecie
wszystkiego, lacznie z danymi z backupow z serwerow.

>>> Oczywiście, jesli nie narobiłeś straszliwej kupy w C to skompiluje się
>>> jako C++.
>> Miala byc identyczna. Bezwarunkowo.
>
> Nikt o tym nie mówił.

Mowil. W poscie o 15:18 stoi: "Ale ja mówie o darmowym ciastku.
Kompilator/składnia identyczna.". No to identyczna, czy z wyjatkami? Bo
ja twierdze ze z wyjatkami.


>> Alez ja wcale nie mam zamiaru tego zrobic. C++ lubie i uzywam. Po prostu
>> Ty chcesz przekonac p.m.e. ze C jest be, a C++ jest cacy.
>
> Moim zadaniem jest pokaząc że *niektóre* konstrukcje z C++ nadają się na
> uC w przeciwieństwie do "reszty świata" która zaczeła tą dyskusję od
> opierdolenia C++ za obiektowość, dziedziczenie i generowanie za dużego
> kodu co ma się nijak: a) do moich intencji, b) do faktów.

To czego nie wliczyles do argumentacji to ryzyko spieprzenia programu
przez kogos nierozumiejacego co robi.

>> Jesli chodzi o poprzednie watki dotyczace Ady: odpowiedz na pytanie, czy
>> dla dobrego programisty ma znaczenie w jakim jezyku cos napisze?
>
> Zasadnicze.

No widzisz, a mi wszystko jedno - nie mam preferencji. Wybieram jezyk
odpowiedni do zadania.

>>> Mi potrzeba abstrakcji, destrutorów, traits wyszła na AVR. Dzieki temu
>>> ostatnio firmware (specyficzny, RT) napisałem w 0.5 dnia wykorzystując
>>> 90% kodu optymalnie (tzn w C nie dało by się lepiej, musiałbym dlubac w
>>> ASM) i 10% dopisując.
>> No i dla mnie taki kod o kant pupy rozbic. Ani test harness nie ma
>
> Że czego nie ma ? Testów? Unit testów? Mój kochany, *każdy* kawalek kodu
> ktory kompiluje na AVR kompiluje tez na x86 z pełnym pokryciem unit
> testami poza dostepem do sprzetu (który czasem daje radę emulowac). Czy
> aby nie wyciągasz odważnyh wniosków bez posiadania wystarczającej ilości
> danych?

W 0.5 dnia?

> Ostatnio spróbowałem google test/mock i chyba przy tym zostanę.
> Programiści C mogą lizać szybkę.
>
>> , ani
>> kodu legalnie nie uzyje.
>
> G. pradwa. Zalezy od licencji.

No i dokladnie tak napisalem - ze ja legalnie nie uzyje (w wiekszosci
przypadkow), wiec nie jest crap prawda.

> Ja np. nie sprzedaje kodu tylko wsad.
> Inny sprzedaje zaprogramowane procesory. Inny pisze kod półotwarty. Twój
> problem jest specyficzny.

Sprzedawanie source code to przypadek specyficzny?

> Są. Jezyki managed mają kilka problemów które przeszkadzają w
> aplikacjach obrabiających dużo danych bądź kierunkowanych na szybkość.

To jest kompilowane. Jesli nie masz za duzo przejsc managed/unmanaged to
nie powinno byc duzego kosztu w szybkosci.


--
Jerry1111

do góry

On 05/05/2012 21:50, Michoo wrote:
> On 05.05.2012 19:47, Jerry1111 wrote:
>
>> Nie jest za darmo, jesli wstawi gdzies ciag znakow "virtual" (bo nie wie
>> ze nie wolno) i 3 dni bedzie szukal czemu "Hello world" nie miesci sie
>> do flasha.
> Moją magisterkę na ARMa z 8k flash i 32k flash piszę w hardcore C++ z:

Wierze. Moje doswiadczenie bylo na Nios2 Altery. Niewykluczone ze to
Altera cos pokrecila. Mam to gdzies udokumentowane, ale nie chce mi sie
szukac - za pozno.
Z drugiej strony to bylo gcc, wiec czemu mialo by nie dzialac?

OIDP to pojawienie sie metody virtual (jednej) skutkowalo zlinkowaniem
dodatkowych 15 czy 20kB. OIDP byla mozliwosc naprawienia tego kombinacja
switchy do gcc.
OIDP rozwiazanie tego problemu zajelo mi mniej niz 3 dni ;-)


--
Jerry1111

do góry