On 05/05/2012 07:40, Sebastian Biały wrote:
> On 2012-05-04 20:35, Jerry1111 wrote:
>> Jak juz kod bedzie pewny i dzialajacy to idzie do biblioteki i mi wisi w
>> czym jest pisany.
>
> Więc kod na destruktorach gwarantuje że jest ok pod warunkiem braku
> bugow w kompilatorze. *Tego* nie gwarantuje, ale nie przypominam sobie
> takowego w gcc. Przypuszczam jednak że wiekszą masz szanse na dowolnego
> innego buga w C który też będzie wymagał wyjęcia gaśnicy. Taki zawód, co
> poradzisz.

Pod warunkiem ze nie zapomnisz napisac destruktora. Kod w C bedzie
dzialal tak samo dobrze jesli nie zapomnisz wlaczyc przerwan. Ale to
troche tak, jakby sie chcialo napisac "Hello, world" i zapomnialo o
printf("Hello, world"); - przed tym sie nie zabezpieczysz.

>> Mysle ze design nie jest mizerny. Starczy powiedziec ze procek ma <5%
>> wolnego czasu, ok. 10% spedza w RTOS i reszta w przerwaniach. Ot, taki
>> sprytniejszy kontroler PWM do przetwornicy.
>
> To nijak nie tłumaczy rozłacznych punktów sekcji krytycznej.

Tlumaczy - warunki sa sprawdzane w zupelnie roznych miejscach.
Stworzenie poprawnej logiki do tego wymagalo troche sprytnego myslenia
zeby 7 tranzystorow dobrze sterowac, ale bylo warto. Moglbym status
trzymac w zmiennej i miec funkcje ktora by sterowala przerwaniami na
podstawie tej zmiennej, ale robi to za mnie swiat zewnetrzny procka.

Nawet bym to w C++ se napisal, tylko kto mi da cykle zegarowe procka na
cos takiego?

Poza tym to nie jest taka ksiazkowa sekcja krytyczna, to sie dzieje w
przerwaniach i ilosc aktualnie nalozonych na siebie przerwan ma pewien
wplyw na priorytet (czyli poczatek i koniec takiej 'udawanej' sekcji
krytycznej bedzie sie wykonywal z roznymi priorytetami - logika jest
dosc zagmatwana). To wszystko narzucone przez hardware jaki musi byc
sterowany w czasie rzeczywistym. Sztuczka w tym zeby nie tracic czasu na
sprawdzanie tych warunkow bo to wszystko sie wykonuje co 10/20/100/500us
(a jest tam troche logiki i dosc duzo DSP).

>> Jak wczesniej napisalem: czas wykonania programu. W taki sposob mam
>> bardzo ladna kontrole nad wlaczaniem/wylaczaniem z priorytetami.
>
> To nijak nie tłumaczy rozłacznych punktów sekcji krytycznej.
>
> Pokaż syntetyczny przykład w którym sekcja krytyczna *musi* być
> rozwałkowana.

Wylaczam przerwanie, cos sie robi i chce wlaczyc przerwanie. W
zaleznosci co sie stalo w miedzyczasie albo wlaczam albo nie. Z
destruktowem musialbym kombinowac i miec jakies parametry mowiace czy
destruktor ma przerwanie wlaczyc czy nie.Tak, wiem, da sie to zrobic na
rozne sposoby, tylko skad ja kuzwa wezme tyle taktow asemblera na to?
Juz pisalem - jedna mikrosekunda jest droga w tej aplikacji, wiec
powstala troche niekonwencjonalna logika.

>> Zaczelo sie od tego ze C++ jest lepsze od C
>
> Bzdua. Zaczeło się od tego że Microchip dostarcza rozwiązania z lat 80
> dla lemmingów.

Czyli kompilator C - nazywajmy rzeczy po imieniu.

> Pomimo tego że moze dostarczyć darmowe ciastko nie robi
> tego.

Czyli kompilator C++.
Aha - polemizowalbym z tym 'darmowe'...

Zapominasz o jednym - na ile wycenisz koszt szkolenia typowego inzyniera
elektronika zeby umial wykorzystac C++? To sie nie oplaca - chcesz robic
sztuke (perfekcyjna i ladna, ale tylko sztuke - bo to nie zmieni sposobu
dzialania urzadzenia) dla sztuki, a tu chodzi o zarabianie kasy. Nic
dziwnego ze ludzie sie nie zgadzaja.

> A potem już poleciała standardowa dyskusja broniąca
> "wystarczającego C" jakie już wiele razy widziałem.

Czas zaakceptowac? ;-)

--
Jerry1111

do góry

On 2012-05-05 14:45, Jerry1111 wrote:
> Pod warunkiem ze nie zapomnisz napisac destruktora. Kod w C bedzie
> dzialal tak samo dobrze jesli nie zapomnisz wlaczyc przerwan.

Nie widzisz róznicy pomiędzy "zapomniałem raz napisac destruktora" a
"zapomniałem napisać pierdyliard miejsc z sei()"? Przeciez oto tu
chodzi. Żeby nie zapomnieć, to kompilator ma zajmować się duperelami
tego typu.

> Nawet bym to w C++ se napisal, tylko kto mi da cykle zegarowe procka na
> cos takiego?

Dlaczego uważasz że C++ zabiera jakies cykle zegarowe?

> Poza tym to nie jest taka ksiazkowa sekcja krytyczna

OK, w więc na *typowy* problem blokowania przerwań masz *szczególny*
przykład gdzie to się nie nada. Jakie to częste w dyskusjach o C++ na uC ...

> Zapominasz o jednym - na ile wycenisz koszt szkolenia typowego inzyniera
> elektronika zeby umial wykorzystac C++?

Typowy pustak argumentowy polega na tym że "muszisz szkolić z C++". Nie
musisz. Zaleta C++ jest to że możesz pisać w C i *powoli* uzywać za
darmo ficzerów. To mogą byc maultkie piedoły typu destruktory i już
podnosisz jakośc kodu za darmo - zarówno jest to łatwiejsze w utrzymaniu
jak i też nie generuje jednego bajtu kodu maszynowego a jest pewne.

> a tu chodzi o zarabianie kasy.

Bierz BASCOma. Niektórym jednak zależy na tym żeby kod utrzymywac,
dodawać ficzery, poprawiać bugi i refaktoryzować. Z pierdyliardem cli()
/ sei() miałbym, z każdym z tych spory kłopot co przekłada się na tą
Twoją ekonomie.

> Nic
> dziwnego ze ludzie sie nie zgadzaja.

Gdybym postulował przejście na haskela to bym się nie dziwił. Ale ja
mówie o darmowym ciastku. Kompilator/składnia identyczna. Większośc kodu
przekompiluje się na tyle gładko, że jak nawet lemmingowi podstawić g++
zamiast gcc to nie zauważy. To bezbolesne. Opór ma źródło w psychice a
nie merytorycznych argumentach.

do góry

Dnia 05-05-2012 o 16:18:33 Sebastian Biały <h...@p...onet.pl>
napisał(a):

> Typowy pustak argumentowy polega na tym że "muszisz szkolić z C++". Nie
> musisz. Zaleta C++ jest to że możesz pisać w C i *powoli* uzywać za
> darmo ficzerów.

Nonsens, i to ciężkiego kalibru. Na początku tej dyskusji pisałem, że w
C++ musisz uważać czego nie używać. Weź typowego elektronika, który C
używa jak makroasemblera, a w C++ nie pisał i każ mu cokolwiek napisać.
Ręczę ci, że efektem będzie przerośnęty kod, korzystający z rzeczy, o
których gdzieś na szybko przeczyta i postanowi użyć nie mając pojęcia
jakie z tym wiążą się konsekwencje (np. metody wirtualne, wielokrotne
dziedziczenie). Większość z tych rzeczy będzie napisana bez sensu: np.
cały kod napisany w konstruktorach, nieświadomość jak i kiedy się
uruchamiają konstruktory i destruktory, przeciążone operatory, gdy to
niczemu nie służy, wyjątki, w dodatku źle użyte, itp. A o cechach C++,
które dla ciebie są tak cenne, mogą się nawet nigdy nie dowiedzieć.

Takie narzędzie jak C++ to możesz dać wyłącznie dobrze wyszkolonym
programistom. Więcej trzeba zrozumieć i dużo łatwiej coś spieprzyć.

> Gdybym postulował przejście na haskela to bym się nie dziwił. Ale ja
> mówie o darmowym ciastku.

Taaa, darmowym. Trzeba utrzymać grupę programistów, którzy zrobią port i
będą o niego dbać. Trzeba wyszkolić CAE/FAE, aby byli w stanie to
wspierać. A naprawdę skorzysta z tego (w przypadku małych uC, nie piszę tu
o 32-bit!), jak to pisałeś? - "szum statystyczny". A zmiana poziomu
sprzedaży będzie poniżej tego szumu.

ae

do góry

On 2012-05-05 17:17, Andrzej Ekiert wrote:
> Weź typowego elektronika, który C
> używa jak makroasemblera, a w C++ nie pisał i każ mu cokolwiek napisać.

Powstawia sei/cli po całym kodzie i będzie narzekać że programowanie to
ciężki zawód bo nie da się tego debugować i naczej nie da rady. Wiem,
bom widział już kilku miszczuf. Faktem jest że kod pisany przez
elektronika zazwyczaj jest gołym asm przerobionym na C ze milionem makr
bez grama wiedzy o programowaniu na jakimkolwiek poziomie abstrakcji.

> Ręczę ci, że efektem będzie przerośnęty kod, korzystający z rzeczy, o
> których gdzieś na szybko przeczyta i postanowi użyć nie mając pojęcia
> jakie z tym wiążą się konsekwencje (np. metody wirtualne, wielokrotne
> dziedziczenie).

Będa o tym pamiętać. Podobnie jak nie sprawia problemu pamiętanie o tym
że nie nalezy uzywać sprintf czy conio na uC. Wiedza jak każda inna.
Zawsze ja mogę wrzucić argument że programista po dowolnym kursie C też
będzie na uC pisał gigantyczne bzdury. Ten argument ma dwa końce.

Ilu znasz programistów którzy po wpisanu a/2.5 zdziwili się czemu kod
zrobil się 10x wiekszy? To ten sam problem.

> Większość z tych rzeczy będzie napisana bez sensu: np.
> cały kod napisany w konstruktorach, nieświadomość jak i kiedy się
> uruchamiają konstruktory i destruktory

Dlatego nie twierdze że C++ jest dla każdego. Microchip skreslił na
starcie wszystkich ktorzy chciali się rozwinąć. Dlatego unikam jak ognia
pomimo kuszącej oferty hardware tych prockow.

> Taaa, darmowym. Trzeba utrzymać grupę programistów, którzy zrobią port i
> będą o niego dbać.

Ta grupa programistów, jesli da się im sensowną architekturę, utrzymuje
się sama albo z mizernych datków. Widocznie MC zauwazył że odstaje od
świata i wsadził MIPSa co rokuje nadzieje że da się na tym coś
współczesnego skompilować a grupa pryszczatych nastolatków będzie mu
utrzymywała gcc.

do góry

no pochwal się, Ktoś się zdecydował?

do góry

On 05/05/2012 15:18, Sebastian Biały wrote:
> On 2012-05-05 14:45, Jerry1111 wrote:
>> Pod warunkiem ze nie zapomnisz napisac destruktora. Kod w C bedzie
>> dzialal tak samo dobrze jesli nie zapomnisz wlaczyc przerwan.
>
> Nie widzisz róznicy pomiędzy "zapomniałem raz napisac destruktora" a
> "zapomniałem napisać pierdyliard miejsc z sei()"? Przeciez oto tu
> chodzi. Żeby nie zapomnieć, to kompilator ma zajmować się duperelami
> tego typu.

Ale u mnie co projekt to pisanie _wszystkiego_ od nowa. Wisi mi czy mam
debugowac konstruktor, makro czy funkcje.

>> Nawet bym to w C++ se napisal, tylko kto mi da cykle zegarowe procka na
>> cos takiego?
>
> Dlaczego uważasz że C++ zabiera jakies cykle zegarowe?

A bedziesz laskawy spowrotem wstawic caly kontekst?

>> Poza tym to nie jest taka ksiazkowa sekcja krytyczna
>
> OK, w więc na *typowy* problem blokowania przerwań masz *szczególny*
> przykład gdzie to się nie nada. Jakie to częste w dyskusjach o C++ na uC

U mnie typowy. Od 10 lat nie napisalem ani jednego kodu embedded w
sposob *typowy* dla wiekszych maszyn. Tego sie nie da oderwac od warstwy
sprzetu jesli sie chce zarobic.

>> Zapominasz o jednym - na ile wycenisz koszt szkolenia typowego inzyniera
>> elektronika zeby umial wykorzystac C++?
>
> Typowy pustak argumentowy polega na tym że "muszisz szkolić z C++". Nie
> musisz. Zaleta C++ jest to że możesz pisać w C i *powoli* uzywać za
> darmo ficzerów.

Taaa... a kto zaplaci za pierwsze 2 miesiace zonkow podczas takiej
transformacji? To ma sens gdzies na uczelni gdzie przy pomocy fajki
mozna myslec o roznych rzeczach przez tydzien. W mojej okolicy za dzien
myslenia jednego inteligentnego idzie faktura w walucie.
Po kilku latach pracownik sie nauczy i co? Odejdzie i bedzie problem -
szukaj drugiego takiego...

> To mogą byc maultkie piedoły typu destruktory i już
> podnosisz jakośc kodu za darmo - zarówno jest to łatwiejsze w utrzymaniu
> jak i też nie generuje jednego bajtu kodu maszynowego a jest pewne.

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.

>> a tu chodzi o zarabianie kasy.
>
> Bierz BASCOma.

Zrozumiales co napisalem?
Moze jeszcze masz plugin Matlab->Bascom?

> Niektórym jednak zależy na tym żeby kod utrzymywac,
> dodawać ficzery, poprawiać bugi i refaktoryzować. Z pierdyliardem cli()
> / sei() miałbym, z każdym z tych spory kłopot co przekłada się na tą
> Twoją ekonomie.

Prosze bardzo - czy ja nie mowie ze nie? Niektorym zalezy na zrobieniu,
wsadzeniu do produkcji i braniu sie za inny _produkt_.

>> Nic
>> dziwnego ze ludzie sie nie zgadzaja.
>
> Gdybym postulował przejście na haskela to bym się nie dziwił. Ale ja
> mówie o darmowym ciastku.

Darmowe nie jest. Producent musi wydac kase zeby to zrobic, klient musi
wydac kase zeby to dobrze uzywac. IMO return on investment bedzie
ujemny. Jest 6e9 ludzi i wychodzi ze jestes jedynym adwokatem.
Statystyka mowi mi ze cos nie tak.

> Kompilator/składnia identyczna.

O!

> Większośc kodu
> przekompiluje się na tyle gładko, że jak nawet lemmingowi podstawić g++
> zamiast gcc to nie zauważy.

Znaczy nie identyczna.

> To bezbolesne. Opór ma źródło w psychice a
> nie merytorycznych argumentach.

Opor ma zrodlo w koncie bankowym. Inaczej wszyscy by robili jak piszesz,
bo by wiecej zarabiali.

--
Jerry1111

do góry

On 2012-05-05 19:47, Jerry1111 wrote:
> Ale u mnie co projekt to pisanie _wszystkiego_ od nowa. Wisi mi czy mam
> debugowac konstruktor, makro czy funkcje.

Tym fajniej busi być debugować te same błedy za każdym razem.

> U mnie typowy. Od 10 lat nie napisalem ani jednego kodu embedded w
> sposob *typowy* dla wiekszych maszyn. Tego sie nie da oderwac od warstwy
> sprzetu jesli sie chce zarobic.

Nie piszę tu o nietypowości że piszesz na uC. Mowię o tym że piszesz
nietypowo jak na uC skoro emulujesz priorytety przerwać na cli/sei
porozrzucancyh po kodzie. Na ten (mizerny) przykład u mnie są same
przypadki CriticalSection a kod jest RT jak najbardziej. Byc może mamy
rózne style pisania kodu. I nie, nie piszę firmware do migania diodą,
problemy są realne i raczej żyłują procesor na pełne osiągi.

> Taaa... a kto zaplaci za pierwsze 2 miesiace zonkow podczas takiej
> transformacji?

Jakiej transformacji? ScopedWhatever masz za 30 sekund w kodzie. Już.
Działa. 0 zonków.

> Po kilku latach pracownik sie nauczy i co? Odejdzie i bedzie problem -
> szukaj drugiego takiego...

Pięknie ujmujesz poziom kwalifikacji przeciętnego klepacza firmware :)

> 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.

Gorzej, jeśli wstawi gdzieś printf to może i 3 flaszy zabraknąć. I co,
porzucamy C i piszemy w asm? Fakt, dla wielu żadna różnica.

>> Bierz BASCOma.
> Zrozumiales co napisalem?
> Moze jeszcze masz plugin Matlab->Bascom?

Ani razu w tej dyskusji nie padło słowo "matlab" o ile dobrze widzę.
Więc argumentujesz używając ukrytej wiedzy. To nie fair.

> Prosze bardzo - czy ja nie mowie ze nie? Niektorym zalezy na zrobieniu,
> wsadzeniu do produkcji i braniu sie za inny _produkt_.

Słusznie. Dzieki takiem podejściu zawsze zaczynasz od int main() { } i
odkrywasz kwadratowe koła za każdym razem. Ekonomia, ja rozumiem. Ja tak
nie potrafie. Może z tego wynika brak porozumienia.

>> Kompilator/składnia identyczna.
> O!

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

>> Większośc kodu
>> przekompiluje się na tyle gładko, że jak nawet lemmingowi podstawić g++
>> zamiast gcc to nie zauważy.
> Znaczy nie identyczna.

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

> Opor ma zrodlo w koncie bankowym. Inaczej wszyscy by robili jak piszesz,
> bo by wiecej zarabiali.

Masz jednokierunkowe podejście do ekonomi. Faktycznie, jesli robisz małe
projekty to moje rady nie mają żadnego zastosowania. Jeśli jednak robisz
większe to nagle potrzeba refaktoringu, ponownego użycia, abstrakcji
staje sie bezpośrednio przekładalna na pieniądze. Zawodowo co prawda mam
do czynienia ze znacznie więszymi apliakcjami od strony kodu, ale zasady
są podobne - tracisz czas (i pieniądze) używając prymitywnych narzędzi,
choć pozornie wydaje się że tworzą produkt szybciej. Bez realiów cięzko
dyskutować czy Tobie taki model biznesu pasuje. Jak widze nie. To jednak
oznacza coś bardzo niefajnego: nie masz realnego przykładu na którym
możesz wykazać mizernośc C++. Bo masz tylko argument ekonomiczny i to
popraty raczej mizerną argumentacją. A taki argument jest zawsze
subiektywny, więc nie ma sensu ciągnąć dyskusji.

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. Mógłbym to samo mieć w C z pomocą kilku
pokracznych makr, ale szacuje że bym się nie wydłubał przez tydzień z
ifdefów. I szacunek popieram próbą którą zarzuciłem po 3 dniach.

Byc może mi pomaga doświadczenie z duzych systemów, bo zawodowo pisuję w
C++ spore rzeczy. Myslę że to zawsze jednak ok poznać inny punkt
widzenia, nawet w ostrej dyskusji (którą to raz na jakiś czas próbuje
wzniecić). Ktoś mi tu zarzucił mesjanizm, może i racja.

do góry

On 05/05/2012 19:26, Sebastian Biały wrote:
> On 2012-05-05 19:47, Jerry1111 wrote:
>> Ale u mnie co projekt to pisanie _wszystkiego_ od nowa. Wisi mi czy mam
>> debugowac konstruktor, makro czy funkcje.
>
> Tym fajniej busi być debugować te same błedy za każdym razem.

Przeciez napisalem ze _wszystko_ jest pisane od nowa. Zaakceptuj to jako
fakt, a nie oceniaj. Publiczna grupa nie jest miejscem na wyjasnianie
dlaczego tak sie dzieje.

>> U mnie typowy. Od 10 lat nie napisalem ani jednego kodu embedded w
>> sposob *typowy* dla wiekszych maszyn. Tego sie nie da oderwac od warstwy
>> sprzetu jesli sie chce zarobic.
>
> Nie piszę tu o nietypowości że piszesz na uC. Mowię o tym że piszesz
> nietypowo jak na uC

Jak najbardziej. Zastosowanie tez nietypowe, ale oszczedza $4.50

>> Taaa... a kto zaplaci za pierwsze 2 miesiace zonkow podczas takiej
>> transformacji?
>
> 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? 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.

>> Po kilku latach pracownik sie nauczy i co? Odejdzie i bedzie problem -
>> szukaj drugiego takiego...
>
> Pięknie ujmujesz poziom kwalifikacji przeciętnego klepacza firmware :)

Pieknie? A moze realnie?

>> 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.
>
> Gorzej, jeśli wstawi gdzieś printf to może i 3 flaszy zabraknąć. I co,
> porzucamy C i piszemy w asm? Fakt, dla wielu żadna różnica.

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

>>> Bierz BASCOma.
>> Zrozumiales co napisalem?
>> Moze jeszcze masz plugin Matlab->Bascom?
>
> Ani razu w tej dyskusji nie padło słowo "matlab" o ile dobrze widzę.
> Więc argumentujesz używając ukrytej wiedzy. To nie fair.

O Bascomie tez nie fair - niepotrzebnie go ekshumowales.

>> Prosze bardzo - czy ja nie mowie ze nie? Niektorym zalezy na zrobieniu,
>> wsadzeniu do produkcji i braniu sie za inny _produkt_.
>
> 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.
I prosze nie odpowiedz ze to znowu jest ukryta wiedza - po prostu (tak
jak i z Matlabem) _zalozyles_ sobie cos, co sie nie sprawdzilo.

> Ekonomia, ja rozumiem. Ja tak
> nie potrafie. Może z tego wynika brak porozumienia.

Ano moze.

>>> Kompilator/składnia identyczna.
>> O!
>
> Oczywiście, jesli nie narobiłeś straszliwej kupy w C to skompiluje się
> jako C++.

Miala byc identyczna. Bezwarunkowo.

>>> Większośc kodu
>>> przekompiluje się na tyle gładko, że jak nawet lemmingowi podstawić g++
>>> zamiast gcc to nie zauważy.
>> Znaczy nie identyczna.
>
> Nie, z dokładnością do kupy w kodzie. Zazwyczaj wychodzi na zdrowie jej
> poprawienie.

j.w., mialo byc bezwarunkowo.

>> Opor ma zrodlo w koncie bankowym. Inaczej wszyscy by robili jak piszesz,
>> bo by wiecej zarabiali.
>
> Masz jednokierunkowe podejście do ekonomi. Faktycznie, jesli robisz małe
> projekty to moje rady nie mają żadnego zastosowania. Jeśli jednak robisz
> większe to nagle potrzeba refaktoringu, ponownego użycia, abstrakcji
> staje sie bezpośrednio przekładalna na pieniądze. Zawodowo co prawda mam
> do czynienia ze znacznie więszymi apliakcjami od strony kodu, ale zasady
> są podobne - tracisz czas (i pieniądze) używając prymitywnych narzędzi,
> choć pozornie wydaje się że tworzą produkt szybciej. Bez realiów cięzko
> dyskutować czy Tobie taki model biznesu pasuje. Jak widze nie.

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

> To jednak
> oznacza coś bardzo niefajnego: nie masz realnego przykładu na którym
> możesz wykazać mizernośc C++.

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. A to co ja
mowie to jest to, ze narzedzie dobiera sie w zaleznosci od problemu
ktory trzeba rozwiazac.
Jesli chodzi o poprzednie watki dotyczace Ady: odpowiedz na pytanie, czy
dla dobrego programisty ma znaczenie w jakim jezyku cos napisze?

> Bo masz tylko argument ekonomiczny i to
> popraty raczej mizerną argumentacją. A taki argument jest zawsze
> subiektywny, więc nie ma sensu ciągnąć dyskusji.

Argument ekonomiczny jest podstawowy: ksztaltuje rzeczywistosc.

> 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, ani
kodu legalnie nie uzyje. Jest szybciej, zgoda, ale jest tez (dla mnie)
bezuzytecznie.

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.

> Mógłbym to samo mieć w C z pomocą kilku
> pokracznych makr, ale szacuje że bym się nie wydłubał przez tydzień z
> ifdefów. I szacunek popieram próbą którą zarzuciłem po 3 dniach.
>
> Byc może mi pomaga doświadczenie z duzych systemów, bo zawodowo pisuję w
> C++ spore rzeczy.

To jeszcze jezyki non-managed sa na PCta uzywane? (tak wiem, pewnie
'duzy system' to cos wieksze od PCta ;-) )
Pytam serio, bo juz jakis czas nie widzialem wiekszej _nowej_ aplikacji
nie napisanej w czyms managed.

> Myslę że to zawsze jednak ok poznać inny punkt
> widzenia, nawet w ostrej dyskusji (którą to raz na jakiś czas próbuje
> wzniecić). Ktoś mi tu zarzucił mesjanizm, może i racja.

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


--
Jerry1111

do góry

Dnia 05-05-2012 o 21:39:38 Jerry1111 <j...@w...pl.pl.wp>
napisał(a):

> 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? Ja zawsze w umowie zaznaczam, że część kodu
będzie pochodzić z naszych bibliotek, na które udzielamy niewyłącznej
bezterminowej licencji. Jak dotychczas zawsze było to akceptowane, czasem
po krótkich negocjacjach.

ae

do góry

On 05/05/2012 21:30, Andrzej Ekiert wrote:
> Dnia 05-05-2012 o 21:39:38 Jerry1111 <j...@w...pl.pl.wp>
> napisał(a):
>
>> 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? ;-)


--
Jerry1111

do góry