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.