Dnia 06-05-2012 o 00:26:23 Michoo <m...@v...pl> napisał(a):

>> Po poprawieniu buga z "else":
>> -Os : 1197 do 1287 (90)
> + 72 bajty Os

Zerknąłem w kod wynikowy: same instrukcje to 14 słów (42 bajty). Większy
kod wynika ze sposobu przechowywania stringów we Flashu - pakowane są w 2
młodsze bajty trzybajtowego słowa. A jak jest nieparzyście, to na ostatni
bajt traci się całe słowo - czyli na stringi poszło 39. A 9 bajtów się nie
mogę doliczyć...

>> Sam nie wiem czy i jakie wnioski z tego wyciągać.
>>
> Że kod w THUMB jest wydajniejszy niż w PIC32 ;)

PIC24. Kod jest chyba dość podobny, ale stringi się efektywniej pakują w
ARMie.

ae

do góry

On 2012-05-06 00:30, Jerry1111 wrote:
> ROTFL... jedna z najlepszych uczelni na swiecie 500 metrow (a raczej
> jardow) z prawej i nie mam wyjscia ;-)

I nie ma tam nikogo od C++ ? *NIKOGO* ? Może za mało płacisz albo jest
już tak źle.

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

Piszesz jak o jakimś hadkorowym kawałku kodu. Przesadzasz. To trywilany
przykład.

>> Dorzucasz kolejny utajniony argument: otwartość źródeł i handel nimi.
>> Nie było o tym mowy.
> Nie bylo mowy ze pisze dla idei.

Można pisac na wiele sposobów. aden z wymienionych przeze mnie nie musi
być darmowy. Twój sposób jest zaś conajmniej nietypowy. Przyznaje jednak
że słyszałem kiedyś o kliencie którzy chciał program w lispie "bo
słyszał że ...", więc nie wykluczam że mogą być różne *marginalne*
przypadki.

> Nie ma problemu - dostalbys skladanke z naszych bibliotek.

Super. Pisaleś o 19:47 "Ale u mnie co projekt to pisanie _wszystkiego_
od nowa". Jesteś pewny że pamiętasz co piszesz?

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

Swietnie. Mam na tapecie ciakwy przypadek kodu który działa tylko z
boost::spirit. Sugerujesz że na jego podstawie powinienem grozić palcem
programistom uzywającym bisona? Uważasz że uczciwe jest negowanie czegoś
ogólnego na podstawie przypadku brzegowego?

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

Znowu jakiś ciekawy pojedynczy przypadek do negowania przypadków
pozostałych? Czy wiesz że prezerwatywa nie zabezpiecza w 100%?

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

Ja też. Kompilator ten sam - gcc. Składnia jak wszystkie klamrowe -
identyczna. char *b; int *a = b; - Taka sama składnia dla C i C++.
Większość kodu nie spieprzonego kompiluje się calkiem nieźle w C++. Czy
to jasno wyjaśnia moje stanowisko, czy dalej chcesz się czepiać
pierdołek bez sensu?

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

To ryzyko jest w każdym jęyku, w C o tyle niebezpieczne że nie ma prawie
żadnej kontroli. Przykłady boost::* pokazują że używając silnych typów i
szablonów mozna wiele z tych pomyłek wyeliminować na etapie kompilacji a
nie runtime. Darmowe ciastko. Tylko trzeba docenić a nie uciekać na
widok <>.

>> Ż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?

Tak, ponieważ mój kod *już* je miał. Tak się składa że nie muszę pisać
wszystkiego od 0. Mam działający kod, optymalnie kompilowany dzięki
traits, przetestowany solidnie poza uC, skalowalny, ze statycznym
polimorfizmem. Skaluje się do innego problemu bez szukania gdzie jeszcze
zapomniałem dać ifdefa i dlaczego się znowu wypierdala i musze lecieć po
gaśnicę.

> No i dokladnie tak napisalem - ze ja legalnie nie uzyje

Ja != inni. Więc nie ma to sensu w dyskusji.

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

Tak. Zazwyczaj sprzedaje się wersje skompilowane. Chyba że jesteś
hindusem, oni tam sprzedają kod od kilograma.

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

Gubie sie. To o uC czy ogólnie? Bo jak ogólnie to kod managed zazwyczaj
wymaga maszyny wirtualnej. To oznacza jakąs technikę JIT. Te techniki
świetnie sprawdzają się w przypadkach akademickich, ale w przypadku
apliakcji RT średnio. Garbage collector typu "stop-the-world" też nie
pomaga osiągnąć RT. Ogólnie jest kłopot z kodem nie-natywnym w wielu
drobnych duperelach ktore na niektórych rynkach są kluczowe do konkurowania.

do góry

On 06/05/2012 00:21, Sebastian Biały wrote:
> On 2012-05-06 00:30, Jerry1111 wrote:
>> ROTFL... jedna z najlepszych uczelni na swiecie 500 metrow (a raczej
>> jardow) z prawej i nie mam wyjscia ;-)
>
> I nie ma tam nikogo od C++ ? *NIKOGO* ? Może za mało płacisz albo jest
> już tak źle.

Ktory by rozumial hardware na wymaganym poziomie? Slabo. A posadzenie
elektronika jako supervisora do kogos od C++ to sie mija z celem
zarabiania na tym kasy. Ten elektronik ma inne rzeczy do roboty.

>>> Dorzucasz kolejny utajniony argument: otwartość źródeł i handel nimi.
>>> Nie było o tym mowy.
>> Nie bylo mowy ze pisze dla idei.
>
> Można pisac na wiele sposobów. aden z wymienionych przeze mnie nie musi
> być darmowy. Twój sposób jest zaś conajmniej nietypowy. Przyznaje jednak
> że słyszałem kiedyś o kliencie którzy chciał program w lispie "bo
> słyszał że ...", więc nie wykluczam że mogą być różne *marginalne*
> przypadki.

Ja nie mowie o pisaniu w lispie, tylko o tym ze klient kupuje kod
zrodlowy. A co? Nie moze, bo tego nie robiles? To jak inaczej opatentuje
urzadzenie, bo wiekszosc naszych prac konczy sie patentem albo innymi
restrykcjami? Musialbys _dokladnie_ przemyslec do czego sa NDA i po co
sie je uzywa. Podpowiem - ich glownym celem _nie_jest_ to, zeby ktos nie
mowil o projekcie. To jest cel drugorzedny.

>> Nie ma problemu - dostalbys skladanke z naszych bibliotek.
>
> Super. Pisaleś o 19:47 "Ale u mnie co projekt to pisanie _wszystkiego_
> od nowa". Jesteś pewny że pamiętasz co piszesz?

Znowu zle zrozumienie - pisalem ze kazdy dostanie to co potrzebuje.

>> Alez ja specjalnie wzialem 'ciekawy przypadek' kodu, a nie kolejny
>> sterownik wyswietlacza czy czegos tam innego.
>
> Swietnie. Mam na tapecie ciakwy przypadek kodu który działa tylko z
> boost::spirit. Sugerujesz że na jego podstawie powinienem grozić palcem
> programistom uzywającym bisona? Uważasz że uczciwe jest negowanie czegoś
> ogólnego na podstawie przypadku brzegowego?

Nie. Dlatego nieuczciwe jest Twoje generalizowanie ze C++ jest lepszy od
C na uC zawsze i bez wyjatku. Wychodzi mi, ze wlasnie pokazalem ze tak
nie jest. A ze nieuczciwie i w przypadku nieidealnym? Takie jest zycie ;-)

>> 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.
>
> Ja też. Kompilator ten sam - gcc. Składnia jak wszystkie klamrowe -
> identyczna. char *b; int *a = b; - Taka sama składnia dla C i C++.
> Większość kodu nie spieprzonego kompiluje się calkiem nieźle w C++. Czy
> to jasno wyjaśnia moje stanowisko, czy dalej chcesz się czepiać
> pierdołek bez sensu?

Dalej. Bo napisales (i to jest glowny motorek dla mnie teraz, jakbys nie
zauwazyl) ze "leming" nie zauwazy podmiany gcc przez g++. Akurat wlasnie
"leming" to zauwazy, bo C bedzie napisane tak okropnie ze bedzie mialo
duza szanse przestac dzialac po potraktowaniu g++.
Ktos to przeczyta, uzyje i bedzie sie dziwil ze nie dziala.
Zakladasz ze inni maja podobny poziom wiedzy. Czyli znowy zakladasz
przypadek idealny ;-)

>> To czego nie wliczyles do argumentacji to ryzyko spieprzenia programu
>> przez kogos nierozumiejacego co robi.
>
> To ryzyko jest w każdym jęyku, w C o tyle niebezpieczne że nie ma prawie
> żadnej kontroli. Przykłady boost::* pokazują że używając silnych typów i
> szablonów mozna wiele z tych pomyłek wyeliminować na etapie kompilacji a
> nie runtime. Darmowe ciastko. Tylko trzeba docenić a nie uciekać na
> widok <>.

Trzeba znac. Ale o tym juz bylo.

>> No i dokladnie tak napisalem - ze ja legalnie nie uzyje
>
> Ja != inni. Więc nie ma to sensu w dyskusji.

Trudno mi o innych dyskutowac...

>>> 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?
>
> Tak. Zazwyczaj sprzedaje się wersje skompilowane.

Dziwnie gadasz. My tu o swiecie embedded rozmawiamy, nie o PCtach...
Moze masz klientow ktorzy placa za binarki bez zdawania sobie sprawy ze
jesli chca cos poprawic to beda w dupie jak Cie autobus przejedzie. Ja
takich nie mam.

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

Bo znowu za duzo cytatow wyciales - pisalem ze ciekawi mnie jak to jest
w swiecie PC, bo uC juz mi sie w tym watku nudzi ;-)

--
Jerry1111

do góry

On 2012-05-06 10:57, Jerry1111 wrote:
> Ja nie mowie o pisaniu w lispie, tylko o tym ze klient kupuje kod
> zrodlowy. A co? Nie moze, bo tego nie robiles?

Czy jesli twój klient będzie wymagał abyście programowali w różowych
skarpetkach to będziesz to używał jako argument w dowolnej tekstylnej
dyskusji na dowolny temat? Twierdze że twój klient który żądał kodu i
kazał go usunąc z backupów jest przyopadkiem marginalnym na podstawie
ktorego nie da się nic wyciągnąć poza stwierdzeniem że zawsze jakiegoś
świra napotkasz. Z resztą to grubo OT bo nijak nie widzę zwiazku z C++.

> Dlatego nieuczciwe jest Twoje generalizowanie ze C++ jest lepszy od
> C na uC zawsze i bez wyjatku.

G. prawda. Nic takego nie generalizuje. C++ jeśli jest przynosi
korzyści. W różnych zakresach. Na małych procesorach pozwala używać
częsci technik RTTI do polepszania jakości, na duzych pozwala tworzyć
abstrakcje znane z wiekszych systemów. Od poczatku mówie, że możesz
sobie z niego wziąśc kawałek i użyć tam gdzie polepszy jakość. Możesz
sobie wziąśc CriticalSection i polepszyć jakość bez uzywania
czegokolwiek innego. Świat nie jest czarno-biały. Nikt nie zmusza do
uzywania C++, natomias jak go masz - masz darmowe ciastko.

> Dalej. Bo napisales (i to jest glowny motorek dla mnie teraz, jakbys nie
> zauwazyl) ze "leming" nie zauwazy podmiany gcc przez g++. Akurat wlasnie
> "leming" to zauwazy, bo C bedzie napisane tak okropnie ze bedzie mialo
> duza szanse przestac dzialac po potraktowaniu g++.
> Ktos to przeczyta, uzyje i bedzie sie dziwil ze nie dziala.
> Zakladasz ze inni maja podobny poziom wiedzy. Czyli znowy zakladasz
> przypadek idealny ;-)

Zakładam że jesli ktoś wali gownianym kodem to trzeba to naprawić bo
inaczej twoja ekonomia robije się o szybki czas pisania ale długi
debugowania. Mam wrażenie że pracujesz w typowej firmie do odwalania
kodu byle jak (co nie znaczy że nie działającego). Być może taka
specyfika rynku, ale to nie jest powod do dumy i slaby background
rozmowy o polepszaniu jakości.

>>> Sprzedawanie source code to przypadek specyficzny?
>> Tak. Zazwyczaj sprzedaje się wersje skompilowane.
> Dziwnie gadasz. My tu o swiecie embedded rozmawiamy, nie o PCtach...
> Moze masz klientow ktorzy placa za binarki bez zdawania sobie sprawy ze
> jesli chca cos poprawic to beda w dupie jak Cie autobus przejedzie. Ja
> takich nie mam.

Świetnie. Zakladamy że za 2 lata ten twój klient powie - no, nadszedł
czas na nowy ficzer. I otwiera ten twój kod a tam nasrane gownem przez
stundetów piszacych na kolanie w popsutym C kod który tylko jakimś cudem
działa. Jestes pewien że klient chciał właśnie tego? Przy czym nie mówi
mi tutaj o purystyce i dopieszczaniu kodu, sam pisałeś że liczy sie
ekonomia i czas. Chyba że znasz złoty środek na pisanie bez bógów, od
zera, skomplikowanych emulatorów priorytetów przerwań, żyłujacych
procesor na 100% przez studentów z sąsiedniej uczelni, optymalizujących
optymalizator gcc, w kilka dni.

Swoją drogą zbliżone problemy mają firmy ktore outsourcing z Indii. Kod
jest żenującej jakości, dokumentacji nie ma, poprawki wymagają czasu
równego jak napisanie od nowa. Ogólnie z tym kupowaniem kodu w celu
poźniejszego poprawiania coś nie uwierzę. Kupuje sie raczej po to by
uniemożliwić konkurowanie na rynku, lub z powodów marketoidalnych.

do góry

On 06.05.2012 01:13, Andrzej Ekiert wrote:
> Dnia 06-05-2012 o 00:26:23 Michoo <m...@v...pl> napisał(a):
>
>>> Po poprawieniu buga z "else":
>>> -Os : 1197 do 1287 (90)
>> + 72 bajty Os
>
> Zerknąłem w kod wynikowy: same instrukcje to 14 słów (42 bajty).
U mnie 15, ale tylko po 2 bajty na każdą.

>
>>> Sam nie wiem czy i jakie wnioski z tego wyciągać.
>>>
>> Że kod w THUMB jest wydajniejszy niż w PIC32 ;)
>
> PIC24. Kod jest chyba dość podobny,
W THUMB jest 2 bajty/opcode poza kilkoma przypadkami, więc na tym sporo
zarabia.

> ale stringi się efektywniej pakują w
> ARMie.
Pewnie tak - wyrównanie do 2 bajtów na THUMB(ale 4 na ARM).

--
Pozdrawiam
Michoo

do góry

On 06.05.2012 12:13, Sebastian Biały wrote:
> G. prawda. Nic takego nie generalizuje. C++ jeśli jest przynosi
> korzyści. W różnych zakresach. Na małych procesorach pozwala używać
> częsci technik RTTI do polepszania jakości, na duzych pozwala tworzyć
> abstrakcje znane z wiekszych systemów. Od poczatku mówie, że możesz
> sobie z niego wziąśc kawałek i użyć tam gdzie polepszy jakość. Możesz
> sobie wziąśc CriticalSection i polepszyć jakość bez uzywania
> czegokolwiek innego. Świat nie jest czarno-biały. Nikt nie zmusza do
> uzywania C++, natomias jak go masz - masz darmowe ciastko.
G. prawda. C++ jest świetny, ale potrzebujesz programisty który:
- zna go na dobrym poziomie
- zna się na programowaniu uC
- zna się na programowaniu uC w C++
inaczej będzie produkował kod na niskim lub bardzo niskim poziomie.

Prosty przykład - boost::mpl działa na uC, ale np konkatenacja stringów
jeżeli nie jest robiona na variadic template to daje rezultat stałej
wielkości. Fajnie, że zrobisz generowanie napisów w czasie kompilacji,
ale przy okazji stracisz ~20 bajtów na każdym. Programista musi to
zauważyć, zrozumieć i obejść. Nie może używać c++ na zasadzie "magia:
takie zaklęcie działa, nie zmieniać"

> Zakładam że jesli ktoś wali gownianym kodem to trzeba to naprawić bo
> inaczej twoja ekonomia robije się o szybki czas pisania ale długi
> debugowania. Mam wrażenie że pracujesz w typowej firmie do odwalania
> kodu byle jak (co nie znaczy że nie działającego). Być może taka
> specyfika rynku, ale to nie jest powod do dumy i slaby background
> rozmowy o polepszaniu jakości.
Czy ty na pewno robisz w embedded?

Cytaty z przykładowego kodu od NXP:
>> Descriptions: Set the I2C stop condition, if the routine
>> never exit, it's a fatal bus error.
To się nazywa obsługa błędów.


>> Returned value: true or false, return false if the I2C
>> interrupt handler was not installed correctly
[...]
>> return( TRUE );
To się nazywa dobra dokumentacja.


>> #define I2C_IDLE 0
>> [...]
>> #define I2C_TIME_OUT 11
[...]
>> Returned value: true or false, return false only if the
>> start condition can never be generated and
>> timed out.
[...]
>> if ( timeout >= MAX_TIMEOUT )
>> {
>> I2CMasterState = I2C_TIME_OUT;
[...]
>> return ( I2CMasterState );
To nie wiem nawet jak nazwać. Sabotaż?

To wszystko w 400 liniach kodu - i potem ludzie wzorujący się na takim
kodzie otrzymanym OD PRODUCENTA mają pisać dobry soft?


> Świetnie. Zakladamy że za 2 lata ten twój klient powie - no, nadszedł
> czas na nowy ficzer.
Gorzej - potem się okazuje, że w kodzie jest dość poważny bug
logiczny[1] a flash i cykle są tak wyżyłowane do granic że buga się nie
da naprawić w sensownym czasie. Kończy się na odpaleniu watchdoga na
sztywno i resetowaniu układu co 5 sekund. ;)

[1] z powodu buga w specyfikacji wymagań, nawet nie wina programisty

--
Pozdrawiam
Michoo

do góry

On 2012-05-06 14:28, Michoo wrote:
> G. prawda. C++ jest świetny, ale potrzebujesz programisty który:
> - zna go na dobrym poziomie
> - zna się na programowaniu uC
> - zna się na programowaniu uC w C++

I kilka procent programistów uC takich jest. A teraz wróćmy do korzeni i
zauwazmy że Microchip odciął ich od razu skazując na wieczne potępienie
w C. To jest powód dla którego nie użyje PICów.

> Czy ty na pewno robisz w embedded?

Robie zarowno w duzych aplikacjach w C++ jak i w uC. uC stanowi jakieś
30% mojego czasu. Czy to oznacza że robie w embedded? Nie, raczej nie.

> To wszystko w 400 liniach kodu - i potem ludzie wzorujący się na takim
> kodzie otrzymanym OD PRODUCENTA mają pisać dobry soft?

Mam podobne przykałady z plikami nagłówkowymi SAM7 Atmela. Powinienem
odstrzelić autorów za totalny chaos, brak systemu ersjonowania,
mieszanie nazwami które po mojej stronie oznaczały 2 tygodnie
opóźnienia. I to był zwykły C, żadnego hardcore.

Ogólnie jeśli chodzi o embedded to jakość kodu jest zazwyczaj żenująca.
Częściowym wytłumaczeniem jest to, że piszą to elektronicy, bez
doświadczenia w programowaniu. I to rozumiem. Niestety MC równa w dół.

Nie tylko ja mam rózne przemyslenia na ten temat.

http://www.objectmentor.com/resources/articles/WhyAr
eYouStillUsingC.pdf

do góry

On 06/05/2012 11:13, Sebastian Biały wrote:
> On 2012-05-06 10:57, Jerry1111 wrote:
>> Ja nie mowie o pisaniu w lispie, tylko o tym ze klient kupuje kod
>> zrodlowy. A co? Nie moze, bo tego nie robiles?
>
> Czy jesli twój klient będzie wymagał abyście programowali w różowych
> skarpetkach to będziesz to używał jako argument w dowolnej tekstylnej
> dyskusji na dowolny temat? Twierdze że twój klient który żądał kodu i
> kazał go usunąc z backupów jest przyopadkiem marginalnym na podstawie
> ktorego nie da się nic wyciągnąć poza stwierdzeniem że zawsze jakiegoś
> świra napotkasz. Z resztą to grubo OT bo nijak nie widzę zwiazku z C++.

Nie jest OT, jest to przyklad. Nie jest marginalny, bo klient to jedna z
wiekszych firm na _swiecie_... Po prostu znowu robisz zalozenie w/g
wlasnego widzimisie. Nie potrafisz na to odpowiedziec juz drugi raz i
siegasz po ironiczne argumenty - sam wiesz co to znaczy.

>> Dlatego nieuczciwe jest Twoje generalizowanie ze C++ jest lepszy od
>> C na uC zawsze i bez wyjatku.
>
> G. prawda. Nic takego nie generalizuje. C++ jeśli jest przynosi
> korzyści. W różnych zakresach. Na małych procesorach pozwala używać
> częsci technik RTTI do polepszania jakości, na duzych pozwala tworzyć
> abstrakcje znane z wiekszych systemów. Od poczatku mówie, że możesz
> sobie z niego wziąśc kawałek i użyć tam gdzie polepszy jakość.

Czy Ty aby napewno pracujesz w komercji, a nie gdzies na uczelni? Jak mi
to 'polepszy jakosc'? Przerwania beda dluzej swieze bez lodowki, albo
co? Ram mi sie nie zamrozi? Od tego mam refresh w jego kontrolerze, a
nie doprawianie kodu sola i pieprzem do smaku.

> Możesz
> sobie wziąśc CriticalSection i polepszyć jakość bez uzywania
> czegokolwiek innego. Świat nie jest czarno-biały. Nikt nie zmusza do
> uzywania C++, natomias jak go masz - masz darmowe ciastko.

Ja nie mowie nie. Ty sie upierasz ze jest to _zawsze_prawda_ - a nie
jest. Do tego jest potrzebna dodatkowa wiedza. Wiedza, ktora lepiej
bedzie spozytkowana gdzies indziej w firmie. Rozumiesz?
W swiecie idealnym: masz racje, zgadzam sie w 100%, tez bym tak chcial.
W swiecie rzeczywistym to nie ma sensu z uwagi na wiele okolicznosci
(stad moje watpliwosci uczelnia/komercja).

>> Dalej. Bo napisales (i to jest glowny motorek dla mnie teraz, jakbys nie
>> zauwazyl) ze "leming" nie zauwazy podmiany gcc przez g++. Akurat wlasnie
>> "leming" to zauwazy, bo C bedzie napisane tak okropnie ze bedzie mialo
>> duza szanse przestac dzialac po potraktowaniu g++.
>> Ktos to przeczyta, uzyje i bedzie sie dziwil ze nie dziala.
>> Zakladasz ze inni maja podobny poziom wiedzy. Czyli znowy zakladasz
>> przypadek idealny ;-)
>
> Zakładam że jesli ktoś wali gownianym kodem to trzeba to naprawić bo
> inaczej twoja ekonomia robije się o szybki czas pisania ale długi
> debugowania.

Trzeba naprawic... dobrze byloby naprawic. Kto za to zaplaci, zeby
naprawic caly swiat?

> Mam wrażenie że pracujesz w typowej firmie do odwalania
> kodu byle jak (co nie znaczy że nie działającego). Być może taka
> specyfika rynku, ale to nie jest powod do dumy i slaby background
> rozmowy o polepszaniu jakości.

Masz zle wrazenie. Nie pisalem nic o naszych procesach code review i
reszcie rzeczy ktora dzieje sie rownolegle do pisania.

>>>> Sprzedawanie source code to przypadek specyficzny?
>>> Tak. Zazwyczaj sprzedaje się wersje skompilowane.
>> Dziwnie gadasz. My tu o swiecie embedded rozmawiamy, nie o PCtach...
>> Moze masz klientow ktorzy placa za binarki bez zdawania sobie sprawy ze
>> jesli chca cos poprawic to beda w dupie jak Cie autobus przejedzie. Ja
>> takich nie mam.
>
> Świetnie. Zakladamy że za 2 lata ten twój klient powie - no, nadszedł
> czas na nowy ficzer. I otwiera ten twój kod a tam nasrane gownem przez
> stundetów piszacych na kolanie w popsutym C kod który tylko jakimś cudem
> działa. Jestes pewien że klient chciał właśnie tego? Przy czym nie mówi
> mi tutaj o purystyce i dopieszczaniu kodu, sam pisałeś że liczy sie
> ekonomia i czas. Chyba że znasz złoty środek na pisanie
> bez bógów, od

bez "bógów" nie znam. Z nimi tez nie.
Ze sraniem i gownem troche przesadzasz (zwlaszcza ze uzywales tych
wyrazow w najwyrazniej nie do konca zrozumianym obcym jezyku gdzies na
poczatku tego watku), wiec jak Ci sie skonczyly normalne argumenty to
sie tymi nienormalnymi sam obrzucaj, mniej balaganu bedzie.

> zera, skomplikowanych emulatorów priorytetów przerwań, żyłujacych
> procesor na 100% przez studentów z sąsiedniej uczelni, optymalizujących
> optymalizator gcc, w kilka dni.

> Swoją drogą zbliżone problemy mają firmy ktore outsourcing z Indii. Kod
> jest żenującej jakości

Ale skad zalozenie ze kod jest zenujacej jakosci? Jest zrobiony inaczej
niz bys chcial - czy to znaczy ze jest zrobiony gorzej? Niech na to
odpowie market - kolejka klientow i ceny jakie jestesmy w stanie
utrzymac udowadniaja ze robimy dobra i cholernie droga robote. Tak,
ludzie musza byc glupi ze wracaja do nas z nastepnymi zamowieniami. I
jest to fakt nawet jesli sie z nim nie zgadzasz.

>, dokumentacji nie ma

Znowu zalozenie czegos, o czyms nie wiesz.

>, poprawki wymagają czasu
> równego jak napisanie od nowa. Ogólnie z tym kupowaniem kodu w celu
> poźniejszego poprawiania coś nie uwierzę. Kupuje sie raczej po to by
> uniemożliwić konkurowanie na rynku, lub z powodów marketoidalnych.

Kupuje sie po to, zeby byc wlascicielem i miec nad nim kontrole.
Chyba nie zrozumiales akapitu odnosnie patentow i NDA - po co sa, bo
wlasnie temu zaprzeczyles.

Dla mnie EOT, bo za duzo smierdzacych argumentow w tym poscie napisales
a za malo merytorycznych.

--
Jerry1111

do góry

On 2012-05-06 15:19, Jerry1111 wrote:
> Czy Ty aby napewno pracujesz w komercji, a nie gdzies na uczelni?

Pracuje w komercji. Mam szczęscie ze pracuje w kodzie w korym jest
nacisk na jakość a nie na predkość pisania. Co i tak się przekłada na
prędkośc pisania - w końcowym efekcie.

> Jak mi
> to 'polepszy jakosc'?

Np. poczujesz przy próbie refaktoringu. Być może żadnej nie
podejmowałeś, dlatego twierdzisz że piszesz zaczynając od 0 za każdym
razem. Nie wiem czemu, ale brzmi jak dzień świstaka.

Żeby pojąć w czym polepszenie jakości pomaga trzeba mieć cykle
developingu. Byc może z powodu swojej specyfiki pracy ich nie masz. Więc
refaktoring, dodawanie ficzerow nie stanowią dla *Ciebie* argumentu. I ok.

>> Zakładam że jesli ktoś wali gownianym kodem to trzeba to naprawić bo
>> inaczej twoja ekonomia robije się o szybki czas pisania ale długi
>> debugowania.
> Trzeba naprawic... dobrze byloby naprawic. Kto za to zaplaci, zeby
> naprawic caly swiat?

Wystarczy kompilator i arch PICów. Arch juz poprawili. Ktoś ten świat
naprawia.

> Ze sraniem i gownem troche przesadzasz (zwlaszcza ze uzywales tych
> wyrazow w najwyrazniej nie do konca zrozumianym obcym jezyku gdzies na
> poczatku tego watku), wiec jak Ci sie skonczyly normalne argumenty to
> sie tymi nienormalnymi sam obrzucaj, mniej balaganu bedzie.

Sam twierdzisz że piszecie szybko i zapominając o kodzie. A więc musicie
mieć albo gówniany kod, albo nadludzkie moce żeby dodatkowo,
nieuzadaniono ekonomicznie, pisać ładny.

> Ale skad zalozenie ze kod jest zenujacej jakosci? Jest zrobiony inaczej
> niz bys chcial - czy to znaczy ze jest zrobiony gorzej?

Bo akurat kod z Indii - do którego się tu odnosisz - widuje.

>> , dokumentacji nie ma
> Znowu zalozenie czegos, o czyms nie wiesz.

Nie doczytaleś do czego ta uwaga.

Zgadzam się nad EOT. Już mi się znudziło :)

do góry

On 06.05.2012 15:04, Sebastian Biały wrote:
> I kilka procent programistów uC takich jest. A teraz wróćmy do korzeni i
> zauwazmy że Microchip odciął ich od razu skazując na wieczne potępienie
> w C. To jest powód dla którego nie użyje PICów.
Ja nie użyję z braku gcc ;) Po tym jak kiedyś kod na 8051 pod sdcc
skompilował się ładnie z obliczeniami na float, a następnie w printf na
LCD wypisał "no FPU unit" (czy coś w tym stylu)[1] stwierdziłem, że
nigdy więcej, chyba, że okoliczności naprawdę wymuszą.

[1] a w assemblerze operacje na float zostały po prostu wycięte, bez
żadnego komunikatu kompilatora

> Ogólnie jeśli chodzi o embedded to jakość kodu jest zazwyczaj żenująca.
> Częściowym wytłumaczeniem jest to, że piszą to elektronicy, bez
> doświadczenia w programowaniu. I to rozumiem. Niestety MC równa w dół.
Najpiękniejsze jest jak piszesz coś pod microblaze - zależnie czy dany
fragment pisał elektronik, czy programista indeksy są raz od 0 a raz od 1 ;)

--
Pozdrawiam
Michoo

do góry