Różnice w alokacji pamięci dla zmiennych globalnych w avr-gcc - z static i bez

a) Mam program w modułach
b) definiuje zmienną globalną w jednym z modułów w postaci:

extern long zmienna (to w pliku .h)

long zmienna (to w jednym z plików .c)

Ktoś ma jakiś pomysł co robie źle ?

Efekt: W tym jednym mudule zmienna lądowała w innym obszarze
pamięci. Po dodaniu #include zmienna poleciała tam gdzie
wszystkie.

to wygląda tak, jakbyś sobie tą zmienną zadeklarował mimo wszystko w tym
pliku. gdybyś nie miał wcześniej żadnej deklaracji, kompilator powinien
się wywalić.

swoją drogą, dodajesz -Wall do flag kompilatora? dzięki dużej ilości
ostrzeżeń łatwo wykryć potencjalne błędy.

Oczywiście wie ponosze ja, za nieuwagę, ale bardzo dzinym dla mnie
zjawiskiem jaest fakt, że w ogóle kod się skompilował bez błędów.

Podziękuj Kernighanowi i Ritchiemu. :-)

Jeszcze lepszą zabawę będziesz miał, gdy uda Ci się wywołać
konflikt nazwy Twojej funkcji z jedną z funkcji bibliotecznych
-- linker bez ostrzeżeia wybierze Twoją wersję, mimo, że inne
fragmenty biblioteki moga chcieć się odwoływać do prawidłowej
wersji. No cóż, jaki jest C każdy widzi...

na razie mimo jego upierdliwości nie zamienie go na nic
innego, jeśli mam grzebac blisko sprzetu (a jak daleko, to C++).

A to akurat jest bardzo ok

Moim zdaniem pisanie programów w C jest swego rodzaju
pozytywnym wyzwaniem

szczególnie w czasach Delphi/VB i wszelkiej maści .NET ów,
gdzie myślenie i znajomośc bebechów jest wysoce niewskazane.

(...) Pokazałem Ci kilka dni temu w jaki sposób Twój
nierozwiązywalny problem w C rozwiązać w kilku linijkach w C++,
i to bez generowania jakiegokolwiek kodu i zajmowania pamięci.

Piotr Wyderski napisał(a):

(...) Pokazałem Ci kilka dni temu w jaki sposób Twój
nierozwiązywalny problem w C rozwiązać w kilku linijkach w C++,
i to bez generowania jakiegokolwiek kodu i zajmowania pamięci.

szkoda, że tak późno zauważyłem tamten wątek, to bym napisał, że można
po prostu zrobić tak:

unsigned long x;

if (sizeof(x) == sizeof(unsigned long)) {
// foo
}

if (sizeof(x) == sizeof(unsigned short)) {
// bar
}

gcc nawet bez -O już w trakcie kompilacji rozwinie sizeof() i usunie
martwy kod warunkowy. fakt, to nie jest dokładne sprawdzanie typu (nie
odróżni char[2] i short od unsigned short), ale w większości przypadków
wystarczy.

Nie bardzo - nie zrozumiales dokladnie o co chodzi.
a) wpisujemy w zrodlo czestotliwosc kwarcu, w #define
b) kompilator na jej podstawie sam wylicza potrzebne wartosci
c) w zaleznosci od tego co wyjdzie uzywa w kodzie arytmetyki
typu int lub long.

sobie sam nakłada kaganiec, a później narzeka, że nie może gryźć, to
już jego problem... :-)

Nie bardzo - nie zrozumiales dokladnie o co chodzi.
a) wpisujemy w zrodlo czestotliwosc kwarcu, w #define
b) kompilator na jej podstawie sam wylicza potrzebne wartosci
c) w zaleznosci od tego co wyjdzie uzywa w kodzie arytmetyki
typu int lub long.

Tymczasem u ciebie:
0) i tak nie wyliczysz tej wartosci, bo to ponad mozliwosci
preprocesora C.

2) o ile zadziala to na zmiennych, to na stalych nie.
sizeof(1000*500) wynosi .. 2

preprocesor gcc nie poradzi sobie ze stałymi zmiennnoprzecinkowymi, ale
większość rzeczy można policzyć na stałoprzecinkowych przy odpowiednim
przesunięciu wartości.

preprocesor gcc nie poradzi sobie ze stałymi zmiennnoprzecinkowymi, ale
większość rzeczy można policzyć na stałoprzecinkowych przy odpowiednim
przesunięciu wartości.

Na przykład najmniejszą wspólną wielokrotność? :-)

teraz to już szukasz dziury w całym (;

a na poważnie, to jak na podstawie wyniku czegoś w stylu
boost::math::static_lcm<x,y> zadeklarować zmienną?

czy może trzeba własne szablony tworzyć?

a na poważnie, to jak na podstawie wyniku czegoś w stylu
boost::math::static_lcm<x,y> zadeklarować zmienną?

Tj. jak wybrać typ zmiennej? Na przykład tak (rozwiązanie ogólne):
(...)

widzę, że pora zainwestować w jakąś sensowną książkę o C++.

widzę, że pora zainwestować w jakąś sensowną książkę o C++.

Polecam Andrei Alexandrescu, "Modern C++ design".

http://www.amazon.com/exec/obidos/tg/sim-explorer/explore-items/-/0201704315
/0/101/1/none/purchase/ref%3Dpd%5Fsxp%5Fr0/103-0547055-5611007

I zapiąć pasy, bo jazda będzie ostra.

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.

na razie mimo jego upierdliwości nie zamienie go na nic
innego, jeśli mam grzebac blisko sprzetu (a jak daleko, to C++).

A to mnie zaciekawiło: dlaczego C++ stosujesz pisząc bardziej
wysokopoziomowo, a C na niższym poziomie? Przecież wszystko,
co można zrealizować w C przenosi się do C++ praktycznie bez
modyfikacji, a w C++ dostajesz kilka bardzo silnych mechanizmów,
m.in. szablony. Pokazałem Ci kilka dni temu w jaki sposób Twój
nierozwiązywalny problem w C rozwiązać w kilku linijkach w C++,
i to bez generowania jakiegokolwiek kodu i zajmowania pamięci.

A to akurat jest bardzo ok

Nie jest bardzo OK, bo może stać się przyczyną powstania bardzo
trudnych do wykrycia błędów. W C++ można się przed tym zabezpieczyć
za pomocą przestrzeni nazw

Moim zdaniem pisanie programów w C jest swego rodzaju
pozytywnym wyzwaniem

Pisanie programów w czymkolwiek nie jest żadnym wyzwaniem,
to rzemiosło. Wyzwaniem jest zaprojektowanie programu, ale
to się robi w oderwaniu od języka programowania.

Nie zrozum mnie źle, ale pisanie w kompilatorze C++ nie używając klas
dalej uważam za pisanie w C.

W zasadzie dla mnie pisanie w C++ to używanie klas/szblonów/STL.
To się średnio nadaje do mikrokontrolerów 8-bitowych na razie.
Tak więc po prostu inaczej definiuje "pisanie w C++"

i coraz bardziej wymusza stosowanie czasochłonnych
/pamięciochłonnych/zasobożernych rozwiązań, zamiast

acz zakładam, że są sytuację, kiedy się przydaje.

ale po prostu jestem "wychowany" na asm Z80/6502/680x0/x86
i mam jakieś zboczenie w tym kierunku.

Inna sprawa, że przeciętny biznesmen powiedziałby, że trace czas na

Programista C w tej samej sytuacji zazwyczaj musi dośc dokładnie
poznać dokuentację obydwu - i to jest wyzwanie.

A co jest złego w klasach, jeśli nie używa się funkcji wirtualnych
i typowania dynamicznego? Przecież one się kompilują w dokładnie
taki sam sposób, jak struktury w C, a na poziomie języka dają kilka
dodatkowych możliwości: dziedziczenie implementacji, szczegółowa
kontrola dostępu do składowych itd.

i coraz bardziej wymusza stosowanie czasochłonnych
/pamięciochłonnych/zasobożernych rozwiązań, zamiast

Nie zawsze, kwestia przemyślenia struktury programu. Natomiast oddalenie
się od maszyny wbrew pozorom bywa pomocne, bo dzięki temu środowiska
uruchomieniowe mogą stosować takie transformacje kodu (zwłaszcza
dynamiczne!), o których sobie w C++ można pomarzyć. Widziałem juz
benchmarki, w których kod w Javie pobił wydajnością program w C++
-- wszystko dzięki optymalizacjom dynamicznym. Nawet mnie to kiedyś
dość mocno interesowało, ale później zmieniłem kurs na specyfikowanie
rozmaitych systemów i ich weryfikację.

acz zakładam, że są sytuację, kiedy się przydaje.

Tylko żeby wówczas komuś nie urwało ręki na ten przykład...

ale po prostu jestem "wychowany" na asm Z80/6502/680x0/x86
i mam jakieś zboczenie w tym kierunku.

Jeśli tą dziedziną jest programowanie niskopoziomowe, to C jest
dobre, a C++ bardzo dobre, więc trochę dziwi mnie, że podchodzisz
do tego ostatniego jak do jeża -- mity o rzekomej złożoności kodu
wynikowego wyprodukowanego przez kompilator C++ skutecznie
rozwiewa zapoznanie się z listingami disasemblera.

Programista C w tej samej sytuacji zazwyczaj musi dośc dokładnie
poznać dokuentację obydwu - i to jest wyzwanie.

Zgoda, ale to się robi podczas projektowania programu, a nie jego
implementowania (choć oczywiście te dwie fazy mogą się ze sobą
przeplatać). Gdyby taki przemyślany program zapisać w Bascomie,
to również doskonale zadziała. Programowanie w C albo czymkolwiek
innym żadnej nowej jakości nie dodaje.

Z resztą się zgadzam.

Ależ o te własnie wirtualne chodzi :)

Co mi po klasach, które nie dają w zasadzie nic ciekawego do
kodu poza pewnym porzadkowaniem metod+danych.

Z resztą co do klas - troche głupio ich uzywać nie mając pod ręką
operatorów new/delete

wyjątków

czy poprawionych includów (mówie teraz o AVR-GCC).

Na razie AVR-GCC nie jest dobrym pomysłem do pisania w C++.

Akurat Java i C++ to żadne różnica, prawie identyczny zapis, prawie
identyczne zastosowanie (poza przenośnym kodem wynikowym).

Dla programisty tak samo się pisze w obydwu.

Jednak ponieważ rozmawiamy o uC w końcu, to dalej nie wiem, czy jest
sens stosowania języków _za wysokiego_ poziomu do uC.

Tam często trzeba dlubac po rejestracj

pamięci

albo liczyć cykle

czy stosować sztuczki przedziwne żeby zmniejszyć ilość instrukcji asm.

Chyba nie ma chwilowo nic lepszego niż C do pisania programów na uC.

Oczywiście BASCOM rulez ale czy ktoś napisal w nim obsługe FAT na MMC
czy jakiś algorytm szyfrujący ?

No bez przesady :)

Z resztą jakoś ludzie piszą w C aplikacjie bardzo powazne i nie ma kłopotu
)

Swoją drogą od dawna pisze obiektowo i czuje się
troche jak bez ręki przy dłubaniu w czystym C ...

Jasne, że każdy problem można zapisać równie dobrze w każdym języku,

jednak nie w każdym optymalnie

A to ja już nic nie pisze wobec tego w tej odnodze. EOT :)

Ależ o te własnie wirtualne chodzi :)

Szczerze mówiąc to nie widzę większej potrzeby intensywnego
używania metod wirtualnych na mikrokontrolerach. A jesli jednak
ich trzeba, to też dużo nie kosztują: jeden dodatkowy wskaźnik
w klasie, a w kodzie to jedna dereferencja i jeden skok pośredni.
Problemy ze złożonością pojawiają się, gdy korzysta się z metod
wirtualnych w hierarchii klas z dziedziczeniem wielobazowym, ale
tego rzadko kiedy potrzeba na "prawdziwych" komputerach.

Co mi po klasach, które nie dają w zasadzie nic ciekawego do
kodu poza pewnym porzadkowaniem metod+danych.

Właśnie o to porządkowanie chodzi, żebyś się w większym
projekcie nie zabił zaplątując we własne spodnie. ;-)

Z resztą co do klas - troche głupio ich uzywać nie mając pod ręką
operatorów new/delete

A dlaczego na mikrokontrolerze masz ich nie mieć? Są za darmo.
Oprócz tego masz idiom "placement new", na mikrokontrolerach
również bardzo przydatny i zupełnie darmowy.

wyjątków

Wyjątki są za drogie w obsłudze, maluchy mają za mało RAMu na stos.
Każdy znany mi kompilator pozwala wyłączyć ich obsługę.

czy poprawionych includów (mówie teraz o AVR-GCC).

A co Ty chcesz inkludować na mikrokontrolerze, gdzie
wszystko jest wysoce niestandardowe? :-)

Na razie AVR-GCC nie jest dobrym pomysłem do pisania w C++.

Jest bardzo dobrym pomysłem, tylko przed pisaniem trzeba
skończyć z wiarą w mity. ;-)

Akurat Java i C++ to żadne różnica, prawie identyczny zapis, prawie
identyczne zastosowanie (poza przenośnym kodem wynikowym).

Szablony w Javie działają na zupełne innej zasadzie niż w C++ -- tam
nie tylko składnia, ale cała filozofia za nimi stojąca jest zupełnie inna.

Dla programisty tak samo się pisze w obydwu.

Oprócz wspomnianych już szablonów w C++ masz dziedziczenie
wielobazowe, dziedziczenie wirtualne, zupełnie inne zasady wiązania
nazwy obiektu z obiektem (m.in. lookup Koeniga -- to chyba jedyny
język, który implementuję ten wynalazek) i przestrzenie nazw. W C++
się pisze zupełnie inaczej niż w Javie, no chyba, że ktoś zna C++
na poziomie "C z klasami" i w takim zakresie go używa -- wówczas
zgoda, ale czuję się w obowiązku donieść, że to zaledwie ułamek
dostępnych możliwości i daje się zapisać w tym języku takie cuda,
że mało kto zdaje sobie sprawę, że to w ogóle możliwe. Ot, choćby
takie sprawdzanie w czasie kompilacji hierarchii dziedziczenia za
pomocą bardzo pokrętnie skonstruowanego szablonu i niecodziennego
wykorzystania operatora sizeof. Majstersztyk.

Jednak ponieważ rozmawiamy o uC w końcu, to dalej nie wiem, czy jest
sens stosowania języków _za wysokiego_ poziomu do uC.

Jeśli oferowane przez nie możliwości przekładają się w łatwy sposób
na kod wynikowy, to oczywiście, że tak. W C++ większość nowych
możliwości jest dostępna zupełnie za darmo.

Tam często trzeba dlubac po rejestracj

To jest nieosiągalne nawet w C, potrzeba wstawki asemblerowej.
A to się robi równie łatwo w C++.

pamięci

C++ nie różni się pod tym względem od C.

albo liczyć cykle

Do tego też trzeba wstawki asemblerowej.

czy stosować sztuczki przedziwne żeby zmniejszyć ilość instrukcji asm.

Będzie ich tyle samo w C++, co w C.

Chyba nie ma chwilowo nic lepszego niż C do pisania programów na uC.

Jest, C++.

Oczywiście BASCOM rulez ale czy ktoś napisal w nim obsługe FAT na MMC
czy jakiś algorytm szyfrujący ?

A niby czemu miałoby się nie dać, i to nawet wydajnie? Znowu jakieś mity.
;-)

No bez przesady :)

Nie przesadzam, w różnych miejscach takie programy są stosowane.
W jednym program się zawiesi i będzie odtwarzał tę samą piosenkę,
w innym bank straci kilkadziesiąt tysięcy dolarów, a w jeszcze innym
trzeba się będzie zastanawiać, co zrobić z denatem...

Z resztą jakoś ludzie piszą w C aplikacjie bardzo powazne i nie ma kłopotu

Są kłopoty, czasami w postaci ofiar śmiertelnych i kalek.

Swoją drogą od dawna pisze obiektowo i czuje się
troche jak bez ręki przy dłubaniu w czystym C ...

Więc je wywal i przejdź na jego następcę, w czym -- oprócz
mitów -- widzisz problem?

Jasne, że każdy problem można zapisać równie dobrze w każdym języku,

Nie, nie równie dobrze. W jednych lepiej, w innych gorzej i dlatego
jest ich tyle.

jednak nie w każdym optymalnie

A jak definiujesz kryterium optymalności i w jaki sposób chcesz
sprawdzać jego spełnialność? Chyba nadużywasz tego słowa. ;-)

A to ja już nic nie pisze wobec tego w tej odnodze. EOT :)

Szkoda.

[Soko nie chcesz EOT ...]

Widzisz, mamy zupełnie inne podejście do programowania obiektowego

moim przypadku, kiedy już decyduje się na C++ to zycze sobie PEŁNEGO c++
włacznie z STL, metodami wirtualnymi, wyjątkami i cała masą innych
fajnych rzeczy.

To nie znaczy że nie należy pisać w C++ na uC - tylko że imho argument
komplikacji jest tu troche nie w tej skali.

Zwróć uwagę na masę kłopotów, które się "robią same" takie jak tworzenie
tymczasowych obiektów przy arytmetyce przeciążonych operatorów (które
tak lubie stosować :),

konstruktory kopiujące (często niepotrzebne) i tym podobne
rzeczy, których IMHO kompilator raczej nie zoptymalizuje
(może się mylę ?).

Można powiedziec, że o ile C++ ułatwia pewne rzeczy składniowo,
to czasami potrafi wygenerować kod nadmiarowy wynikający z
samej definicji obiektu przez programistę.

Wyjątki są za drogie w obsłudze, maluchy mają za mało RAMu na stos.
Każdy znany mi kompilator pozwala wyłączyć ich obsługę.

Szkoda :) Czyli "-" dla C++ ? :)

Jesli poczytasz helpa do WinAVR to dowiesz się, że w ostatniej wersji
jaką dałem radę ściągnąć częśc plików jest "not C++ safe" a konkretnie
nie mają 'extern "C"'

I ostro zacisnąć pasa w tym C++ :)

Oj, wiadomo że kazdy język ma spore róznice, ale chodzi o to, że
większośc programistów Java jest w stanie pisać w C++ i na odwrót.

Co do filozofi to nie wiem czy mówisz o całym jezyku czy tylko o jego

ale dla mnie nie było zadnych kłopotów w pare dni przegryźć się przez
róznice Java-C++

Jakie ma znaczenie majsteresztyk, skoro można badać
typy/rzutować z użyciem mechanizmów w C++ ?

Tzn jestem wrogiem sztuczek programistycznych

bo to zamiast ułatwiać zycie - zaciemnia tak, że komuś rękę urwie kiedyś
P

Co do przestrzeni nazw - ile to programów w C wyrosło bez tego "bajeru"

ale brak "namespace" jakoś nie spowodował zastoju C

Hmmm ok. Zakładam, że teoretycznie masz rację. Jednak jestem przekonany
że przeciętny dobry programista C++ na dużych pecetach wybije sobie zęby
od razu o mały RAM/mały stos w uC.

Dużo zależy od umiejśtności programisty,

jednak jesli wykastrujemy C++ z STL, wyjątków i paru innych duperelek to
okaże się, że w zasadzie pozostał C + troche "bajerów składniowych" typu
szablony.

Hmmm moment, nie chodzi mi o rejestry uC tylko o rejestry specjalne

Łomatko :) No dobra, C++ wykastrowany, robocza nazwa "1/2C++" może byc ?
)

Cos mi się zdaje że BASCOM nie powstał do takich
zastosowań (co nie zienia faktum że można).

Dziwnym trafem nie przeszkadzają te negatywne doświadczenia na całym
swiecie stosować windowsa do obsługi szaf muzycznych (zaliczyłem już 4
sztuki wesoło zawieszone na niebieskim ekranie), bankomatów ze znakiem
zachęty C:> na ekranie (przoduje tu PKO, 2 trafienia) tudzież
informatorów turystycznych nie mogących znaleźć pliku "xxxx.dll"

We wszystkim o czym dyskutujemy, co praktycznie zawsze ma źródło w
"małej ilości RAMu" co wymusza kastrację.

No dobra, ale się rozpisujemy, ja proponuje powoli kończyć, choć z
przyjemnością sie dyskutuje.

Widzisz, mamy zupełnie inne podejście do programowania obiektowego

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

moim przypadku, kiedy już decyduje się na C++ to zycze sobie PEŁNEGO c++
włacznie z STL, metodami wirtualnymi, wyjątkami i cała masą innych
fajnych rzeczy.

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?

To nie znaczy że nie należy pisać w C++ na uC - tylko że imho argument
komplikacji jest tu troche nie w tej skali.

Jaka komplikacja?

Zwróć uwagę na masę kłopotów, które się "robią same" takie jak tworzenie
tymczasowych obiektów przy arytmetyce przeciążonych operatorów (które
tak lubie stosować :),

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

konstruktory kopiujące (często niepotrzebne) i tym podobne
rzeczy, których IMHO kompilator raczej nie zoptymalizuje
(może się mylę ?).

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

Można powiedziec, że o ile C++ ułatwia pewne rzeczy składniowo,
to czasami potrafi wygenerować kod nadmiarowy wynikający z
samej definicji obiektu przez programistę.

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ć. ;-)

) jednak: przy C mamy pełną jasnośc co do tego jak zostanie wykonana

Wyjątki są za drogie w obsłudze, maluchy mają za mało RAMu na stos.
Każdy znany mi kompilator pozwala wyłączyć ich obsługę.

Szkoda :) Czyli "-" dla C++ ? :)

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

I ostro zacisnąć pasa w tym C++ :)

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?

Oj, wiadomo że kazdy język ma spore róznice, ale chodzi o to, że
większośc programistów Java jest w stanie pisać w C++ i na odwrót.

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

[ciach ciekawe rzeczy]

Tzn jestem wrogiem sztuczek programistycznych

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ą... :-)

bo to zamiast ułatwiać zycie - zaciemnia tak, że komuś rękę urwie kiedyś

Zaciemnia? Trudno sobie wyobrazić czytelniejsze deklaracje niż, odpowiednio:
fn(best_mode<int>::type k);
wektor<457> w;
range<0, 2779> i;

Co do przestrzeni nazw - ile to programów w C wyrosło bez tego "bajeru"

Nieakceptowalnie wiele.

ale brak "namespace" jakoś nie spowodował zastoju C

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

Hmmm ok. Zakładam, że teoretycznie masz rację. Jednak jestem przekonany
że przeciętny dobry programista C++ na dużych pecetach wybije sobie zęby
od razu o mały RAM/mały stos w uC.

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

jednak jesli wykastrujemy C++ z STL, wyjątków i paru innych duperelek to
okaże się, że w zasadzie pozostał C + troche "bajerów składniowych" typu
szablony.

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

Hmmm moment, nie chodzi mi o rejestry uC tylko o rejestry specjalne

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.

Łomatko :) No dobra, C++ wykastrowany, robocza nazwa "1/2C++" może byc ?
)

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

Cos mi się zdaje że BASCOM nie powstał do takich
zastosowań (co nie zienia faktum że można).

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

We wszystkim o czym dyskutujemy, co praktycznie zawsze ma źródło w
"małej ilości RAMu" co wymusza kastrację.

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

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

Oczywiście ;) :P Myslisz że nie próbowałem liczyć na atmedze sinusów ?

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

Przy C++ mamy często przypadkowe błędy wynikające z nieznajomości
pracy C++ przy manipulacji obiektami/wzorcami/whatever.

Szkoda, co prawda nie lubie pisać wyjątkami

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 :)

-)

ale fakt, że w winavr tego niepoprawili (chyba od dawna) świadczy o tym,

chyba jest mało developerów piszących w C++ na AVRy. Jesteś w mniejszości
P

nie ma new/delete z definicji w winavr (pewno mozna dorobic,
nie robiłem tego, w zasadzie nie używam nawet malloc).

Hmmm moment, 20% ? Jakoś cięzko mi tak podliczyc podobieństwa C++ i
Javy.

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"

Hehe, powiedź to sąsiadowi z sąsiedniego biurka

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.

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

O fuj :) Zaciemnia jak diabli :)

Hmmm niewiem co masz na mysli: czy że za mało, czy że za dużo.

Grzebałem w kodach parudziesięciu programów unixowych i
sporadycznie widac jakieś dodatki typu namespace/C++.

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,

To go usunę, żaden problem.

Chyba że mam 50 plików .c, ale to chyba wychodzi poza ramy małego uC.

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

Jasne, ale w sumie o ile to bardziej bedzie bolesne od C/C++.

b) jestem absolutnie za używaniem wzorców przy pisaniu kodu na małe uC.

c) nie lubie języków BASCOM/whatever

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

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

Przy C++ mamy często przypadkowe błędy wynikające z nieznajomości
pracy C++ przy manipulacji obiektami/wzorcami/whatever.

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

Szkoda, co prawda nie lubie pisać wyjątkami

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

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

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

Pfuj, jakie to nieładne :)

Gdy ostatnio zaglądałem w "nowe" inkludy, to właśnie tak to zrobili:
nowy_inklud = extern "C" {

-)

nie ma new/delete z definicji w winavr (pewno mozna dorobic,
nie robiłem tego, w zasadzie nie używam nawet malloc).

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

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"

[...] spróbuj dojść, jak to działa. :-)

[cut fajne]

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)

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

bo statystycznie uzyskiwali mniejszą wydajność niż bez nich.

Wydajność pisania kodu?

Niestety wyrosła konkurencja w postaci javy i C# oraz ogólne
przechodzenie na .NET (choćby z powodu zaszpanowania przed
konkurencją czy klientem).

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

Szkoda, C++ był naprawde wielkim krokiem do przodu,

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.

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

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

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

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

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

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

Ależ o te własnie wirtualne chodzi :) Co mi po klasach, które nie dają w
zasadzie nic ciekawego do kodu poza pewnym porzadkowaniem metod+danych.
Z resztą co do klas - troche głupio ich uzywać nie mając pod ręką
operatorów new/delete, wyjątków czy poprawionych includów (mówie teraz o
AVR-GCC). Na razie AVR-GCC nie jest dobrym pomysłem do pisania w C++.

Już wiem, aczkolwiek jestem bardzo zdziwiony ...

Oczywiscie jestem temu winien. Mój program składa się z 5 modułów.
Przypadkowo (zapewne efekt pisania nocami) w jednym z plików .c
zapomniałem doinkludować charakterystyczme pliki do AVR. Ponieważ nie
było w nim żadnych zaleznych sprzetowo elementów poza SIGNAL i
matematyce na zmiennych to nie wrzeszczał o ich brak (swoją drogą bradzo
dziwne, czyżby SIGNAL był wbudowany w avr-gcc ?).

Efekt: W tym jednym mudule zmienna lądowała w innym obszarze pamięci. Po
dodaniu #include zmienna poleciała tam gdzie wszystkie.
Oczywiście wie ponosze ja, za nieuwagę, ale bardzo dzinym dla mnie
zjawiskiem jaest fakt, że w ogóle kod się skompilował bez błędów.

Dziwne to co piszesz.

Natomiast SIGNAL .. bez include to jest po prostu zwykla funkcja
o takiej nazwie, ktora kompiluje sie swietnie, ale wywolywana
nigdy nie jest. Na assemblerze powinno cie zaciekawic:
-czemu nie konczy sie reti,

-czemu nie przechowuje uzywaneych rejestrow,

J.F. wrote:

Natomiast SIGNAL .. bez include to jest po prostu zwykla funkcja
o takiej nazwie, ktora kompiluje sie swietnie, ale wywolywana
nigdy nie jest. Na assemblerze powinno cie zaciekawic:
-czemu nie konczy sie reti,

Alez kończy, wcześniej tez kończyło się.

-czemu nie przechowuje uzywaneych rejestrow,

No własnie przechowywało wszystkie.

Moje zdumienie miało związek z faktem magicznego przenoszenia się
zmiennej z 0x6x do 0xdx w zalezności od uzycia "static". Widocznie z
jakiś powodów nie dołaczenie własciwych plików .h (moja wina) powoduje,
że linker/kompilator allokuje zmienną w innym obszarze.

Okazało się ze to nie był problem z wywoływaniem funckji z przerwań. To
chyba co innego. Z nieznanych mi przyczyn jest istotna róznica jeśli:

a) Mam program w modułach
b) definiuje zmienną globalną w jednym z modułów w postaci:

extern long zmienna (to w pliku .h)
long zmienna (to w jednym z plików .c)

c) modyfikuje ją w przerwaniu

To w takiej konfiguracji zmiana "zmiennej" powoduje wesołe zawieszenie
się reszty programu/błedne działanie.

jednak wystarczy zdeklarować:

static long zminna

A program się stabilizuje i działa poprawnie.

Ktoś ma jakiś pomysł co robie źle ?

Ciagle nie widzie volatile :-)

Dziwne rzeczy piszesz. Jesli zmienna jest zadeklarowana poza funkcja,
to "static" znaczy de facto "nie publiczna".
Jako taka nie moze byc dostepna z innych modulow !

POdeslij caly program.

J.F. wrote:

Dziwne rzeczy piszesz. Jesli zmienna jest zadeklarowana poza funkcja,
to "static" znaczy de facto "nie publiczna".
Jako taka nie moze byc dostepna z innych modulow !

W moim przypadku nie sięgam do niej z innych modułów (chwilowo) żeby
wykluczyc jakies problemy między-modułowe. Jest deklarowana jako static
i extern i korzysta z niej jeden i tem sam moduł. W jednym wypadku jest
dobrze, w drugim dzieją się cuda.

POdeslij caly program.

Eeee :) Nie da rady, ale postaram się ten problem wywołać dla
rzeczywistego kodu. na razie jedyny objaw to inna lokalizacja zmienne jw
pamięci dla extern i static, natomiast w bardzo mayłym programie który
korzysta z tego mechanizmu jest ok.