Różnice w zachowaniu zmiennych globalnych w AVR-GCC: extern vs static w przerwaniach

Mon Jul 04, 2005 6:17 pm   

Sebastian Bialy wrote:


A czemu mam chcieć, dyskusja wygląda ciekawie. :-)


Nie, do programowaia w C++. O programowaniu obiektowym niewiele
mówiliśmy, a poza tym C++ dość mało ma z nim wspólnego.


A jesli piszesz w C, to życzysz sobie pełnego zestawu funkcji
matematycznych,
funkcji wejścia-wyjścia oraz plików, mimo, że w danym systemie pojęcie pliku
nie
ma sensu?


Jaka komplikacja?


Przeciążone operatory arytmetyczne na AVR-ku?!


Zoptymalizuje, choć kiedyś miał kłopoty z NRVO i powstał taki tymczasowy
idiom "operator(parametry) return nazwa_zmiennej { treść_operatora }"
-- ostatnio go wycofano.


Jasne, ale należy do tego dodać, że programista powinien był
wiedzieć na czym polega działanie użytego mechanizmu i być
świadom skutków ubocznych. Pierwsze przykazanie: mysleć. ;-)


A czy fakt, że karaluchy miewają problemy z opanowaniem
chińskiego cos chińskiemu ujmuje? :-)

To żaden minus, po prostu nie ma miejsca na stos wyjątków.
A jak nie ma stosu wyjątków, to nie ma i wyjątków.


no to nadaj im go hurtem, pisząc w swoim kodzie

extern "C" {

#include <stdio.h>
#include <stdlib.h>
#include <cośtam.h>
}

int main() { [...]

Tego Ci brakowało? :-)


Rezygnując z wyjątków to ostro? A co m.in. z nieporównywalnie
bardziej potrzebnym programowaniem generycznym i dziedziczeniem,
które żadnych nakładów nie wymaga?


Ano jest, wykorzystując jakieś 20% dostępnych możliwości.
Reszty się przenieść nie da.



Tylko o Java generics -- działają na zupełnie innej zasadzie niż
szablony znane z C++.


Generics weszły do Javy tak niedawno, że chyba nie ma
o nich jeszcze wiele w żadnej książce. :-)


Cały czas mówię o tym, co da się osiągnąć w standardowym C++,
a nie dzięki rozszerzeniom albo zewnętrznym narzędziom. Stąd
wszystko jest "mechanizmem C++", więc niezupełnie rozumiem, o
co Ci chodzi, ale przypuszczam, że o dynamic_cast<>. Jeśli tak,
to wartość dynamic_cast jest obliczana w czasie działania programu,
a nie jego kompilacji, więc się nie nadaje do większości ciekawych
zastosowań, m.in. generowania optymalnej struktury programu
dla danego zbioru parametrów (Twój wątek też nalezy do tego
zbioru). Mozna chcieć otrzymać w C++ takie mechanizmy o
dużym znaczeniu praktycznym:

1. Optymalne przekazywanie parametrów do funkcji i metod.
Niemodyfikowalne parametry można przekazywać w C++ przez
stałą wartość albo przez referencję do obiektu stałego. Jeśli
parametr jest "mały" (np. jakaś liczba naturalna), to najtaniej
będzie przekazać go przez wartość. Gdy jest "duży" (obiekt
klasy o wielu składowych niestatycznych itp.), to znacznie
taniej wyjdzie przekazać referencję niż tworzyć jego tymczasową
kopię w rekordzie aktywacji wywoływanej procedury. Bardzo
małe obiekty klas (np. zawierające tylko jedno pole typu int)
jednak lepiej przekazywać przez wartość, bo dostęp pośredni
jest kosztowniejszy niż bezpośredni. Ponieważ z góry nie
wiadomo, jaka metoda będzie optymalna w _konkretnym_
przypadku (bo zmieniamy docelowy procesor na większy,
albo po prostu rozbudowaliśmy klasę o nowe pola, czy też
pozbyliśmy się niepotrzebnych), chcielibyśmy mieć prosty
w użyciu mechanizm, który pozwoli kompilatorowi wybrać
optymalną dla danego parametru metodę przekazywania.

Czy da się to zrobić nie uciekając się do rozszerzeń albo
nie edytując w pocie czoła wszystkich plików źródłowych
po każdej zmianie definicji typów?

2. Wymuszanie rozwijania pętli. Chcielibyśmy napisać klasę
działającą na wektorch danych podanego typu, o podanej
długości N. Chcemy mieć m.in. operację ich dodawania.
Moglibyśmy napisać w pętli

for(k = 0; k < N; ++k)
c[k] = a[k] + b[k];

ale gdy N jest małe, to stracimy znacznie więcej czasu
na obsługę pętli niż na właściwe dodawanie. Moglibyśmy
więc w takich przypadkach rozwinąć tę pętlę i dla N = 3
zastąpić ją

c[0] = a[0] + b[0];
c[1] = a[1] + b[1];
c[2] = a[2] + b[2];

Gdyby jednak N było duże, to takie rozwinięcie spowodowałoby
gigantyczny wzrost objętości kodu, więc tu jednak lepsza byłaby
pętla. Poza tym jesteśmy leniwi i nie chcemy na sztywno
wkodowywać rozwinięć, bo może się nam zmienić maszyna albo
po prostu więcej się dowiemy i nasza definicja tego, jakie N jest
małe, a jakie duże może się zmienić. Chcielibyśmy móc tylko
podać kompilatorowi w jednym miejscu to, co w chwili obecnej
uważamy za małe i jakiego N potrzebujemy, a o wygenerowanie
odpowiednich wariantów niech on się już zatroszczy sam -- w
końcu lenistwo jest motorem postępu. My będziemy tylko
pisać

wektor<4> a, b, c;
c = a + b;

albo

wektor<1000> a, b, c;
c = a + b;

a nasz kod niech sobie sam tak zmodyfikuje strukturę, by
w pierwszym przypadku (N=4) w pełni się rozwinął, a drugi
został policzony w pętli, bo akurat za małe uznajemy wszystko,
co ma mniej niż 6 elementów. Da się coś takiego zrobić?

3. Optymalny typ zakresowy. Do iterowania po różnych zakresach
parametrów przydałoby się mieć typ range, któremu powiemy tylko,
jakie wartości minimalne i maksymalne może przyjąć parametr, a
kompilator niech dobierze mu odpowiedni typ. Jeśli ten typ będzie
za duży, np. 64-bitowy, to się program będzie bardzo wolno
wykonywał, a jeśli za mały, to nastąpi przepełnienie i program się
popsuje. Dlatego typ iteratora ma być w sam raz i być dobierany
automatycznie na podstawie podanego przez nas zakresu oraz
na podstawie zakresów właściwych dla danej maszyny (np. int
ma 16 bitów). Nas to nie obchodzi -- ma działać, i to działać
optymalnie.

for(range<-10,150> k = -5; k < p; ++k)
[...]

Da się to zrobić?


Sztuczek? Każdy z powyższych kodów będzie małym dziełem sztuki
(o ile da się go napisać -- da się? ), a nie żadną sztuczką... :-)



Zaciemnia? Trudno sobie wyobrazić czytelniejsze deklaracje niż, odpowiednio:

fn(best_mode<int>::type k);
wektor<457> w;
range<0, 2779> i;


Nieakceptowalnie wiele.


Zrobisz konflikt deklaracji, to będziesz miał zastój. ;-)


Nie wiem, nie prowadziłem na ten temat badań statystycznych.
Ja sobie radzę równie dobrze w obu tych środowiskach, dlatego
pozwalam sobie klasyfikować wiele Twoich uwag jako mity --
nie próbowałeś czegoś zrobić, a z uporem bronisz przekonań,
które nie mają oparcia w faktach. Spróbuj, chętnie podyskutuję,
ale z rzeczywistymi doświadczeniami, a nie z uprzedzeniami. ;-)


Jak zawsze.


Heh, Sebastianie, jeśli uważasz szablony za bajerek składniowy, to
z pewnością nigdy z nich nie korzystałeś w bardziej zaawansowany
sposób. Wyrzuć z C++ cokolwiek sobie życzysz, ale szablony mi
zostaw, bo to głównie z ich powodu używam tego języka. :-)


Procesora? No to tym bardziej się do nich nie dostaniesz z poziomu C,
tylko wstawka asemblerowa (albo rozszerzenie, jak sfr w Keilu) będzie
dostatecznie silna.



Ale _z czego_ wykastrowany, z wyjątków? To jest dla Ciebie połowa tego
języka? :-)


Pewnie i nie powstał, ale jeśli ktoś mi zaproponuje dostatecznie
wysoki stosik zachęcaczy, to i w kodzie binarnym mu to napiszę. :-)


Owszem, świat schodzi na psy... ;-)


Przecież ani szablony, ani dziedziczenie, ani przestrzenie
nazw Ci nawet bitu tego RAMu nie zjedzą... :-)


Ciekawe, czy ktoś tu dotarł? :-)

Pozdrawiam
Piotr Wyderski

Mon Jul 04, 2005 7:59 pm   

Piotr Wyderski wrote:

Racja, przejęzyczenie.


Oczywiście Myslisz że nie próbowałem liczyć na atmedze sinusów ? A
i owszem, kiedys się przydazyło, co gorsza szykuje mi sie projekt w
którym jest _naprawde_ dużo liczenia na liczbach zmiennoprzecinkowych
(na szczęscie mam na to mase czasu).

Ale jesli miałbym spoglądnąc na to krytycznie - to akurat ja nie miałem
racji z STL(bo to w sumie wykorzystanie mechanizmów języka, a nie sam
język C++) ani Ty (bo funkcje matematyczne to tez nie jest składnik
_jezyka_ C a raczej dodatek).


Wspominałeś coś o plątaniu sie w spodniach ...


Hmm a czemu nie, o ile prościej jest napisać a+b, gdzie a i b to obiekty
par liczb (powiedzmy współrzednych na ekranie LCD). Ale nie o to chodzi,
chodzi raczej o ukryte manipulacje w tle, które produkują niepotrzene
obiekty tymczasowe, najczesiej własnie przy kombinowaniu z operatorami.
W sumie to sporo roboty jest, żeby stworzyc obiekt i go następnie za
chwile zniszczyć.


Hmmm musze się przyglądnąc co się dzieje przy takim podejściu jak
x=(a+b)*y (wszystko obiekty), czy aby a+b nie tworzy na stosie jakiegoś
tymczasowego obiektu.


jednak: przy C mamy pełną jasnośc co do tego jak zostanie wykonana
operacja (może za wyjątkiem konwersji/rzutowania, gdzie często łatwo
zrobic błąd). Przy C++ mamy często przypadkowe błędy wynikające z
nieznajomości pracy C++ przy manipulacji obiektami/wzorcami/whatever. W
zasadzie C++ wydaje mi się w niektórych zastosowaniach bardziej
niebezpieczny ( o ile niebezpieczeństwo zdefiniujemy jako nadmierne
obciązenie pamięci). Choć jak najbardziej wygodny.


Alez ja cały czas pisze w kontekście AVR-C++. Mozliwe że się nie
rozumiemy, jeśli rozmawiamy o C/C++ na duże pecety to ja się obydwoma
rękami podpisuje pod wszystkim co piszesz. Ale na AVRy nie.


Szkoda, co prawda nie lubie pisać wyjątkami, ale sa sytuację, że bez
nich jak bez ręki. W kazdym razie jak by niebyło to oficjalny składnik
C++ więc skoro go nie ma na AVR to wygląda na to ze nie ma C++ tylko
jakaś proteza :P


Pfuj, jakie to nieładne Nie jest to dla mnie żadną przeszkodą, ale
fakt, że w winavr tego niepoprawili (chyba od dawna) świadczy o tym, że
chyba jest mało developerów piszących w C++ na AVRy. Jesteś w mniejszości :P


Hmm zależy co kto pisze, w sumie cięzko mi sobie wyobrazić bardzo
zaawansowany kod w paru kB flasha używający wszystkich możliwych funkcji
C++. Jednak zwróć uwagę, ż mamy już pare ograniczeń: nie ma wyjątków,
szkoda ramu na metody wirtualne (można sie kłucic czy faktycznie dużo
zajmuja), nie ma new/delete z definicji w winavr (pewno mozna dorobic,
nie robiłem tego, w zasadzie nie używam nawet malloc). Ten c++ na małe
AVR po prostu nie jest tym samym, w dodatku stosowanie niektórych
sztuczek w których powstają obiekty tymczasowe może doprowadzić do
szybkiego wypełnienia RAMu ( o ile nie jest to optymalizowane, nie wiem).


Hmmm moment, 20% ? Jakoś cięzko mi tak podliczyc podobieństwa C++ i
Javy. Wiele ksiązek dojavy rozpoczyna się od podsumowania róznić w
stosunku do C++ lub co chwile w treści mamy ostrzeganie "tu jest troche
inaczej". pewnie, że żaden ze mnie programista w javie bo ledwo liznąłem
i cięzko się wypowiadać, ale moje zdanie jest takie, że mają bardzo dużo
wspólnego. Choć zapewne po paru tysiącach linijek Javy mogę zmienić
zdanie (choć już na dzień dzisiejszy mam ochotę rzucić ją w kąt i wrócić
do C++). Zobaczymy za rok, na razi tematykę javy zamykam, bo za mało
jeszcze wiem.


Wszystko ładnie, tylko podajesz proste przykłady, a wczesniej wpominałeś
o znacznie bardziej rozbudowanym : "sprawdzanie w czasie kompilacji
hierarchii dziedziczenia za pomocą bardzo _pokrętnie_ skonstruowanego
szablonu i _niecodziennego_ wykorzystania operatora sizeof"
(podkreslenia moje). Ale masz oczywiście jak najbardziej racje, C++ jest
do tego wymyślony i nie zmamierzam się spierać bo jest oczywiste, że C
do pięt nie dorasta C++ przy elastyczności na etapie kompilacji kodu.

A swoją drogą ciakwostka: i w C da radę, o ile pamiętam FFTW jest
napisanyw C i samodzielnie (choć oczywiście PO kompilacji, na żywym
kodzie) się optymalizuje do CPU.


Hehe, powiedź to sąsiadowi z sąsiedniego biurka, swoją drogą pamiętam
jak kolega debatował kiedyś 3 godziny z innym nad 4 linikowym kodem,
który okazał się w końcu metodą zmiany 2 zmiennych bez użycia trzeciej
(stara sztuczka z XOR). Wszystko ładnie i pięknie jesli piszesz sam, lub
masz ludzi w zespole potrafiących jednym rzutem oka zrozumieć o co
chodzi. Tak na marginesie: na jakiś 5 programistów w C++ w firmach
jakich znam/znałem żaden już nie pisze z użyciem wzorców(za wyjątkiem
bardzo prostych duperelek - nakaz szefów) bo statystycznie uzyskiwali
mniejszą wydajność niż bez nich. Prawdopodobnie właśnie dlatego, że kod
stawał się nieczytelny przez różne sztuczki. Pewnie że wina szefa, że
nie ustandaryzował, ale co poradzić. Co nie zmienia faktu że to swietna
zabawka :P


O fuj Zaciemnia jak diabli Ale to kwestia gustu.


Hmmm niewiem co masz na mysli: czy że za mało, czy że za dużo. Stawiam
na to pierwsze i musze przyznać, że grzebanie w źródłach narzedzi GNU
jest może przykładem sredniej wielkości projektów, ale bez wątpienia
dużej ilości ... Grzebałem w kodach parudziesięciu programów unixowych i
sporadycznie widac jakieś dodatki typu namespace/C++. A w ogóle to nie
widziałem ani jednego korzystającego z STL (co nie znaczy że ich nie ma,
ale pech - nie trafiłem . C++ jest nadal mało popularny jako język
apliakcji (popularnych), a jeśli w ogóle używany to na poziomie buildera
i SQLa (gdzie podwójna pętla jest zadaniem dla szefa zespołu) a w takim
stanie raczej przypomina wyłacznie C+obiekty. Niestety wyrosła
konkurencja w postaci javy i C# oraz ogólne przechodzenie na .NET
(choćby z powodu zaszpanowania przed konkurencją czy klientem). Szkoda,
C++ był naprawde wielkim krokiem do przodu, dla niektórych za dużym.


To go usunę, żaden problem. Chyba że mam 50 plików .c, ale to chyba
wychodzi poza ramy małego uC.


No masz, przecież dyskutujemy sobie swobodnie o wadach zaletach C/C++ a
ty mi tu wmawiasz jakąs "obronę z uporem" . Ależ ja jestem otwarty na
C++ tak samo jak na C w przypadku uC. W sumie nie chce jakiejś wojny
wywoływać, tylko posłuchac o ciekawych rozwiązaniach i po drodze troche
poprowokować ... :P


Owszem, szablony są wazne, pozwoliłem sobie troche przesadzić w nazwie.
Nie zmienia to faktu, że C++ w całości jest trudny w użyciu na uC.
Faktycznie pozostają wyłącznie szablony i może obiekty. Jeśli z uporem
podkreślasz ich zalety, to muszę zrobić pare testów i może też zaczne
powszechnie korzystać. Człowiek się uczy cały czas, prawda ? :)


nie nie, źle to nazwałem, chodzi o komórki pamięci pełniące role
"strowników" hardware w mikrokontrolerze. Ale mniejsza o to, bo widze,
że coś namieszałem z tym kawałkiem i się nie dogadamy.


Z paru innych rzeczy też (wcześniej pisałem). Czy połowa to znowu
kwestia gustu i przyzwyczajeń.


Jasne, ale w sumie o ile to bardziej bedzie bolesne od C/C++. Niektórych
rzeczy nie warto robic za nawet duże pieniądze . Kiedyś widziałem w
sklepie internetowym koszulkę z napisem "Jestem szmata, pisze w VB". Coś
w tym jest Inna sprawa, że głupio taką zakładac, jeśli 99%
społeczeństwa rozumie tylko część przed przecinkiem...


Ależ nie twierdze, że nie nalezy tego używać. Chyba musze posumowac
dyskusję żeby była jasnośc :)


Ja :)

A teraz podsumowanie z mojeje strony:

a) jestem absolutnie za pisaniem w C++ na wiekszych maszynkach (większa
maszynka=>64KB RAM, z reszta silnie zalezy od problemu). Stosowaniem
takich technik, jakie udostepnia dany jezyk. C jest po prostu zbyt
niebezpieczny na _duże_ projekty.

b) jestem absolutnie za używaniem wzorców przy pisaniu kodu na małe uC.
Z jednym małym wyjątkiem: że po roku czasu patrząc w kod będe wiedział o
co chodzi. Na razie tego nie robie, bo nie było potrzeby, pierwsza się
pojawiła przy dobieraniu wielkości licznika w poprzednim wątku i w tej
chwili wacham się nad przejściem na kompilator C++. Zobaczymy jak bardzo
będzie to bolesne.

c) nie lubie języków BASCOM/whatever bo nie dają mi swobody
implementacji na niskim poziomie i często nie wiem, w jaki sposób działa
dany fragment. Pisanie wiekszych projektów mija się z celem, w zasadzie
brak wsparcia ze strony języka.

d) Nie jestem wrogiem C++, wręcz przeciwnie większośc programów pisze
wlasnie w C++ i nie zamierzam się z tego wycofywać w najbliżyszm czasie
(chyba że .NET zrobią na unixa, ale nawet wtedy chyba nieprędko).
Zaznaczam jednak, że wzorców używam w zasadzie głównie do implementacji
algorytmów zniezależnych od typów. Jakoś nie mogę się przekonać co do
przejrzystości kodu z użyciem wzorców w innych rolach.

e) pisuje w C głównie na kontrolery AVR, bo po prostu jest tak dla mnie
przejrzyściej. Skoro twierdzisz, że wzorce są takie świetne i nie
utrudniają życia/kompilacji/wielkości kodu, to postaram się do nich
przekonać.

f) Obawiam się, że zanim zaczne się bawic na poważnie w C++ na AVR to
przejdę już na ARM i wtedy problemu nie będzie (po prostu będę miał
pełny C++).

Pozdrawiam :)

Ale się rozgadalismy...

--
Sebastian Bialy - heby@poczta.onet.pl

Mon Jul 04, 2005 9:24 pm   

Sebastian Bialy wrote:


Akurat sinusa się prosto liczy, niedawno nawet opisywałem algorytm. :-)


Tu sprawa wcale nie jest jasna: kiedyś długo dyskutowałem z kimś
na ten sam temat, ale sprawa zredukowała się do udzielenia odpowiedzi
na pytanie, czy STL-owy string to część C++, czy też niezależny od
samego języka program. Każdą z dwu możliwych odpowiedzi można
poprzeć bardzo silnymi argumentami, więc sprawa została nierozstrzygnięta.
Ja jestem za drugą z tych możliwości, ale "obóz przeciwny" też ma
dużo racji. Ale widze, że jesteś w moim. ;-)


Nie należy używac mechanizmów, których zasady działania się nie rozumie.


Wiedziałem, że się droczysz. Bez wyjątków daje się żyć i na
dużych maszynach, więc na mikrokontrolerach tym bardziej.


Chyba nie istnieje na Ziemi kompilator będący całkowicie zgodny ze
standardem C++ i implementujący wszystkie własności tego języka,
np. konstrukcję "export template" -- mówię całkowicie poważnie. :-)


Gdy ostatnio zaglądałem w "nowe" inkludy, to właśnie tak to zrobili:

nowy_inklud = extern "C" {

#include "stary_inklud.h"
}

:-)





Bez problemu można to sobie dopisać, tylko mając 128 bajtów RAM
nie bardzo jest czym zarządzać. :-)


Owszem, maksymalnie 20%. Liczą się nie tylko podobieństwa
strukturalne, ale głównie wyrażalność -- w C++ masz do dyspozycji
cały arsenał technik, które nie mają swoich odpowiedników w Javie.


Wbrew pozorom on nie jest bardziej rozbudowany, jeśli chodzi o
wielkość kodu, to zaledwie ~10 linijek -- znacznie mniej, niż zajmie
rozwiązanie każdego z wcześniejszych przykładów. Jego "pokrętność"
sprowadza się do przebłysku geniuszu autora, a nie do wykorzystania
jakiegoś olbrzymiego i nieczytelnego kodu. Masz poniżej moją
implementację (choć nie ja wpadłem na tę technikę), spróbuj
dojść, jak to działa. :-)

struct aux_large_type { char m_Dummy[2]; };

template <class U, class V> struct aux_affinity_conversion {

private:

static char check(V*); // Not implemented, only the
signature is used
static aux_large_type check(...); // Not implemented, only the
signature is used

public:

enum { is = (sizeof(check(static_cast<U*>(0))) == sizeof(char)) };
};

Poza tym rzekoma "pokrętność" nie jest widoczna dla końcowego
użytkownika -- on pisze tylko "affinity<pierwszy_typ,
drugi_typ>::is_derivation"
i w czasie kompilacji dostaje stałą boole'owską z odpowiedzią na pytanie
o istnienie relacji dziedziczenia typu drugi_typ z pierwwszy_typ, której
może użyć np. do parametryzowania innego wzorca.


Swego czasu zademonstrowałem im kilka tego typu technik...
a później się na mnie długo patrzyli jak na raroga. ;o)
Ale zrozumieli i teraz sami używają. :-)


Niestety niewielu ludzi potrafi to robić porządnie albo nawet nie
wie o istnieniu takich technik w C++ -- to zostało opracowane
dopiero w tym wieku. Nie żeby to była jakaś sztuka tajemna, po
prostu te techniki miały zbyt mało czasu, by się upowszechnić.


Wydajność pisania kodu? Jeśli tak, to uwierzę.
Wydajność programu nie miała prawa spaść,
jeśli spadła, to zrobiono coś bardzo, bardzo źle.


Przecież tego kodu nie widać -- jest zamknięty w odpowiednim
nagłówku, a używa się tylko parametryzacji tego szablonu.
Parametryzacje są bardzo czytelne, a przynajmniej powinny być.


Hmm... :-)


Za dużo.


Szkoda.


Szpan pewnie też jest tu istotnym czynnikiem, ale .NET to
naprawdę porządnie zaprojektowana platforma, więc bardzo
dobrze jej życzę. :-)


Nie zgodzę się, C++ pod względem jakości projektu języka
jest sporym krokiem wstecz, ja wolę Adę. A pod względem
nowych mozliwości -- to fakt, doszło bardzo dużo nowych
rzeczy, w C nieosiągalnych.


Nie usuniesz, bo nie będziesz o nim wiedział. Dowiesz się o jego
istnieniu będąc w połowie drogi na Księżyc, niesiony pędem
eksplozji kotła parowego, który Twój sterownik wysadził.
W C++ dzięki przestrzeniom nazw takie coś nie może zaistnieć,
bo użytkownikom zasadniczo nie wolno niczego dokładać do STD.


Dlaczego? Nieukończony jeszcze kod mojego mp3-playerka to ~30 plików,
niestety w C (na 8051 za darmo jest dostępny tylko SDCC).


W całości tak.


Spodoba Ci się i będzie nas tu dwuosobowa mniejszość, choc
Jerry kiedyś coś wspominał, że go nawróciłem na C++ w NIOSie. ))


Ja też nie spodziewam się wielkich przyjemności,
ale jeśli będzie trzeba, to rzecz jest wykonalna.


Dziękuję, bez reszty się obędę. ;-)


Ani ja, co nie zmienia faktu, że w razie potrzeby mogę w nich pisać.


To jest jedyny (i do tego bardzo dobry) sposób rozwiązania
Twojego problemu z licznikiem, więc masz już cos na zachętę. ;-)

Pozdrawiam
Piotr Wyderski

Mon Jul 04, 2005 10:11 pm   

Piotr Wyderski wrote:

Myslisz, że tylko sin potrzebuje ? Mam za zadanie liczyc funkcje,
gdzie jest: logarytm przy podstawie narzuconej, prawdopodobnie jakaś
funkcja składana z sin i paru przekształceń, i jeszcze cos, czego
pomysłodawca nie zdefiniował: "jeszcze pomysle". Hmm.... chyba jednak
standardowa biblioteka C pójdzie w obroty, jeszcze nie upadłem na głowę
żeby pisać wszystko na bitach/bajtach/+/- ... :P


Heh, powiedź to miszczom używająym Delphi i stringów w środku na
palcach jednej ręki policzyłbym wśród znajomych programistów
zaprzątających sobie głowę jak to działa. Co nie przeszkadza im
wszystkim powszechnie używać. Swego czasu pamietam moje boje kiedy
tłumaczyłem po co jest konstruktor kopiujący kiedy obiekt allokuje
jakieś zasoby - do nie ktorych po prostu nie trafia, jesli pisza przez 5
lat "OnClick->SELECT FROM * ...". ja myslę, że programiści nie mający
pojęcia jak działa kompilator są w znacznej większości na rynku. W
dodatku wycięcie wskaźników z języków takich jak java i C# tylko
pogłębia zapaść (acz nie jestem przeciwnikiem znikania wskaźników -
tylko boleje nad faktem braku znajomości mechanizmów niskiego poziomu).


Masz racje, ale to wynik przyzwyczajenia. Przypuszczam że ktoś wychowany
na wyjątkach nie wyobraża sobie zycia bez nich.


Ale wyjątki to raczej się implementuje Ale dobra, niech będzie że
faktycznie standard C++ to na razie świstek papieru a nie rzeczywistość.


A owszem, tylko że niepowinien tego robic programista a producent
kompilatora.


Można, można Zalezy co jest wazniejsze: czy ilośc RAM, czy
"profesjonalnośc" kodu - nie jesten programista C bije pokłony do
wydruku kodu allokującego 2-wymiarową tablicę Na razie nie trafiłem
na małym AVR na potrzebę malloc'a,ale już na AtMega162 z zewnątrznym
RAMem - a i owszem, jak bez ręki.


Nie o 1 w nocy ... ja już nie mam sił na myslenie, przed chwilą
pomyliłem w kodzie true z false i po prostu nie daje rady ... ale
zerknę, choć z wzorców żaden ze mnie specjalista.


Owszem, ale okazuje się, że wzorce okazały się zbyt skomplikowane dla
szarego programisty. Niestety filozofia pisania komercyjnych aplikacji
sprowadza się do prostych pomysłów typu SQl+zdarzenia GUI. Jesli przez 5
lat pisze wyłacznie w tym zakresie aplikacje, to po prostu nic go nie
przekona do nauki wzorców (może wywaleniez roboty i szukanie nowej dla
motywację).


Tak. Mój znajomy twierdzi, że po prostu były niejasności i różne
koncepcje, jak również spore dziury w wiedzy pomiędzy zespołem. A w
zasadzie wszystko można zrobić bez wzorców, tyle że mniej elegancko. Ale
jak się okazało w tych warunkach - szybciej.


Owszem, fajna zabawka, ale na razie działa sensownie tylko na Win, a
Mono jakoś się robi i robi i nie może wreszcie się przebić powaznie jako
alternatywa, z resztą jeśli się nie będa kompilowac programy okiemnkowe
pod mono, to daleko niezajedzie. Ja troche poczekam, bardzo nie lubie
zamykac sobie kodu tylko na win (takie lekkie zboczenie).


Miałem dopisać "dla programistów C". Co do Ady - nie znam. I nie poznam,
bo nie ma zaplecza w postaci bibliotek/algorytmów w takiej ilości jak C.
A może się mylę ?


Hmm... zobaczymy. Na razie mam wazniejsze sprawy na głowie, ale w wolej
chwili ...


Problem chwilowo rozwiązany inaczej - znalazlem troche mocy
obliczeniowej w głównej pętli i jednak kręcę 4 bajtami. Natomaist
rozwiązanie to jest mało eleganckie więc może w wolnej chwili się pobawie.

--
Sebastian Bialy - heby@poczta.onet.pl

Tue Jul 05, 2005 11:52 am   

Sebastian Bialy wrote:

U mnie podobnie (brak czasu na R&D) - jak powylaczalem niepotrzebne
bzdury w kompilatorze (typu wyjatki itp), to kod sie zrobil sensownie
krotki i proste rzeczy byly obiecujace
A ze niedlugo bedzie trza siakies okienka na Niosa napisac (bo cos
wyswietlic na LCD 320x240...) to sie zabiore za c++ w embedded world na
powaznie - po roku...


--
Jerry

Tue Jul 05, 2005 12:42 pm   

Piotr Wyderski wrote:


Fajny ten internet - nie zdaze sie Piotra zapytac o dobra ksiazke
i juz mam odpowiedz
A czy jest taka ksiazka (w zasadzie wiedza czy jest, to tez cenna
informacja) ktora by opisywala uzywanie C++ w malych procesorkach?
Czyli co mozna, czego lepiej nie robic - wiesz, takie male kompendium
wiedzy coby jeszcze raz kola nie wymyslac.


--
Jerry

Tue Jul 05, 2005 3:17 pm   

jerry1111 wrote:


Niestety niczego mi na ten temat nie wiadomo. Jeśli mam na danym
procku C++, to po prostu siadam i w nim piszę, a kod wychodzi taki,
jaki chciałem mieć. Nie zauważyłem większych różnic w podejściu
w porównaniu z większymi maszynami. Nie używam tylko wyjątków,
typowania dynamicznego i metod wirtualnych, bo na ośmiobitowcach
zazwyczaj jest za mało pamięci na dane. Wykorzystuję za to różne
niskopoziomowe mechanizmy standardowe, których się praktycznie
nie używa na większych maszynach, np. placement new. Cała reszta
bez zmian, zwłaszcza szablony.

Pozdrawiam
Piotr Wyderski