Używam środowiska programistycznego Eclipse udostępnionego
w pakiecie firmy Altera do programowania procesora Nios II.
Środowisko ogólnie rzecz biorąc ładne i funkcjonalne, ale...

Zauważyłem pewną wadę, nie wiem czy to bug czy zła konfiguracja.
Otóż mamy tam okienko "Outline" w którym mamy listę nazw
symboli (zmiennych, funkcji) używanych w naszych źródłach...
List ta jest dynamicznie tworzona w tym okienku w czasie pisania
źródeł w edytorze - dodajemy zmienną/funkcję: wskakuje ona do okienka.

Jeśli zmienna obłożona jest warunkową kompilacją w preprocesorze
to w zależności od tego czy IDE zna zmienną warunkową to ta
funkcja czy zmienna obłożona warunkiem #ifdef....#endif pojawia
się tam w okienku lub nie...

Wszystko pięknie i ładnie dopóki używamy symboli preprocesora
znanych w IDE - czyli tych ustawionych w opcjach preprocesora...
Jeśli obłożmy zmienną lub funkcję dyrektywą #ifdef...#endif
i symbol testowany jest zdefiniowany w pliku nagłówkowym
włączanym do źródeł instrukcją preprocesora #include to okienko
Outline, nie znając tego symbolu, nie pokazuje tej funkcji/zmiennej
na liście. Można się domyślać, że dzieje się tak bo program nie czyta
plików #include i nie rozwija tam zawartych dyrektyw preprocesora.

I teraz pytanie moje brzmi - czy u innych użytkowników Eclipse
dzieje się tak samo czy to jest tylko mankament wersji Eclipse
udostępnianej mi przez firmę Altera? A może źle coś skonfigurowałem?

do góry

Pszemol pisze:
> Używam środowiska programistycznego Eclipse udostępnionego
> w pakiecie firmy Altera do programowania procesora Nios II.
> Środowisko ogólnie rzecz biorąc ładne i funkcjonalne, ale...
>
> Zauważyłem pewną wadę, nie wiem czy to bug czy zła konfiguracja.
...
> Można się domyślać, że dzieje się tak bo program nie czyta
> plików #include i nie rozwija tam zawartych dyrektyw preprocesora.

Nakładki nie znam i nie będę instalował (Eclipse można powiedzieć znam)
, ale preprocesor C jest tradycyjnie negatywnym przykładem, jak to
bajzel wprowadza dla programistów i trudności dla konstrukcji narzędzi
(np. IDE). Tak na dystans, wydaje mi się że to być może tak ma być, że
możliwości narzędzia nie sięgają pełnego rozwijania makr preprocesora,
gdyby tak było, nie pierwszy taki przypadek, nie ostatni.

tyle przypuszczeń.
pozdrawiam.

do góry

"Jacek Czerwinski" <...@...z.pl> wrote in message
news:h5c73u$r8p$1@news.onet.pl...
> Pszemol pisze:
>> Używam środowiska programistycznego Eclipse udostępnionego
>> w pakiecie firmy Altera do programowania procesora Nios II.
>> Środowisko ogólnie rzecz biorąc ładne i funkcjonalne, ale...
>>
>> Zauważyłem pewną wadę, nie wiem czy to bug czy zła konfiguracja.
> ...
>> Można się domyślać, że dzieje się tak bo program nie czyta
>> plików #include i nie rozwija tam zawartych dyrektyw preprocesora.
>
> Nakładki nie znam i nie będę instalował (Eclipse można powiedzieć znam)

O jaką "nakładkę" Ci chodzi??? :-)

> , ale preprocesor C jest tradycyjnie negatywnym przykładem, jak to bajzel
> wprowadza dla programistów i trudności dla konstrukcji narzędzi (np. IDE).
> Tak na dystans, wydaje mi się że to być może tak ma być, że możliwości
> narzędzia nie sięgają pełnego rozwijania makr preprocesora, gdyby tak
> było, nie pierwszy taki przypadek, nie ostatni.
>
> tyle przypuszczeń.

No tak... przypuszczeń :-)

Nawet jeśli przyjmiemy, że nie mieli w planach czytania plików
#include i rozwijania tam zdeklarowanych makr - czy zatem
przy implementacji okienka outline nie lepiej byłoby w ogóle
pominąć funkcję usuwania funkcji/zmiennych objętych warunkami
preprocesora? Tak byłoby logiczniej, skoro częściowa implementacja
nie daje nic wartościowego a tylko utrudnia używanie okienka,
którego główną funkcją jest przecież szybkie odszukanie nazwy funkcji.

Dla mnie logiczne byłoby sugerować się #ifdef-ami tylko gdybyśmy
analizowali źródła w 100% tak samo jak preprocesor... a jak nie w 100%
to wyrzucamy całą funkcję i pokazujemy w tym oknie WSZYSTKIE symbole.

do góry

Pszemol pisze:
> "Jacek Czerwinski" <...@...z.pl> wrote in message

>> Nakładki nie znam i nie będę instalował (Eclipse można powiedzieć znam)
>
> O jaką "nakładkę" Ci chodzi??? :-)

Nakładkę do Eclipsy ... zgaduję że za drobną dodatkową opłatą ;) i w
stosunku do kilku zer ceny 'nakładka' brzmi obraźliwie...

>> , ale preprocesor C jest tradycyjnie negatywnym przykładem, jak to
>> bajzel wprowadza dla programistów i trudności dla konstrukcji narzędzi
>> (np. IDE). Tak na dystans, wydaje mi się że to być może tak ma być, że
>> możliwości narzędzia nie sięgają pełnego rozwijania makr preprocesora,
>> gdyby tak było, nie pierwszy taki przypadek, nie ostatni.
>>
>> tyle przypuszczeń.
>
> No tak... przypuszczeń :-)
>
> Nawet jeśli przyjmiemy, że nie mieli w planach czytania plików
> #include i rozwijania tam zdeklarowanych makr - czy zatem
> przy implementacji okienka outline nie lepiej byłoby w ogóle
> pominąć funkcję usuwania funkcji/zmiennych objętych warunkami
> preprocesora? Tak byłoby logiczniej, skoro częściowa implementacja
> nie daje nic wartościowego a tylko utrudnia używanie okienka,
> którego główną funkcją jest przecież szybkie odszukanie nazwy funkcji.
Jak mówiła moja babcia:
dobrze mówisz tylko nisko siedzisz. (W ogólnym sensie, w szczegółowym
patrz niżej)

> Dla mnie logiczne byłoby sugerować się #ifdef-ami tylko gdybyśmy
> analizowali źródła w 100% tak samo jak preprocesor...
przypuszczeń ciąg dalszy... IDE typowo dla C/C++ które mają
podpowiadanie, prawdopodobnie dokonują mocnej walki ze źródłami (o
koszcie czasowym podobnym do kompilacji co się czuje), tworzą jakieś
tymczasowe struktury itd. Na najlepszych z nich szybkość podpowiadania
zaledwie zbliża się do (nota bene) Eclipse użytej do Javy. Ale Java to
język, gdzie po zastanowieniu specjalnie utrącono preprocesor i kilka
innych właściwości, również z podobnych powodów.

Bardzo często w C++ wyłączam 'udogodnienia' (np na Borlandzie zawsze) bo
więcej wkurza niż pomaga lub przełączam tylko na życzenie.

> a jak nie w 100%
> to wyrzucamy całą funkcję i pokazujemy w tym oknie WSZYSTKIE symbole.
Jakby pomyśleć dłużej, wymyśliłbym kontrprzykład do tej idei (ale mi się
nie chce). Np. niektóre symbole np. TRUE/FALSE min/max by w ogóle nie
istniały bez preprocesora, inne by istniały pod innymi nazwami.

Nie dość że nie pomagam a przypuszczam, to na marginesie dodam złośliwie
że w sursach pisanych przez elektroników makra C są często użyte bez
zrozumienia a nawet w sposób groźny dla życia (przykład moja maszynka do
golenia). Jeśli producent pochodzi z tych kręgów, to ho ho .... wszystko
możliwe.

do góry

Pszemol pisze:

> Wszystko pięknie i ładnie dopóki używamy symboli preprocesora
> znanych w IDE - czyli tych ustawionych w opcjach preprocesora...
> Jeśli obłożmy zmienną lub funkcję dyrektywą #ifdef...#endif
> i symbol testowany jest zdefiniowany w pliku nagłówkowym
> włączanym do źródeł instrukcją preprocesora #include to okienko
> Outline, nie znając tego symbolu, nie pokazuje tej funkcji/zmiennej
> na liście. Można się domyślać, że dzieje się tak bo program nie czyta
> plików #include i nie rozwija tam zawartych dyrektyw preprocesora.

Indekser Eclipsa zagląda do plików nagłówkowych i analizuje ich treść, o
ile potrafi odpowiednie pliki nagłówkowe zlokalizować. Foldery z plikami
nagłówkowymi należy wskazać (zobacz właściwościach projektu "path and
symbols"->Includes).
Lista folderów przeszukiwanych z plikami nagłówkowymi jest wyświetlana w
"Project Explorer" ("Includes").

Poprawność lokalizacji można przetestować poprzez wskazanie kursorem
wybranego pliku nagłówkowego i naciśnięcie F3 (przy standardowych
ustawieniach). Jeśli Eclipse jest w stanie zlokalizować plik nagłówkowy,
to po tej akcji nastąpi przełączenie do okienka edycji pliku nagłówkowego.

Warto sprawdzić ustawienia indeksera (szukaj "Indexer" we właściwościach
projektu). Może jest w ogóle wyłączony... Zwykle powinien wystarczyć
tryb "Fast". W starszych wersjach Eclipsa czasami trzeba było ustawić
opcję "Full".
Czasami zdarza się, że indekser pójdzie gdzieś w maliny, wtedy zwykle
pomaga przeindeksowanie projektu na nowo: kliknij myszką na folderze
projektu i rozwiń menu podręczne, dalej "Index"->"Rebuild".

pzdr
mk

do góry

"Jacek Czerwinski" <...@...z.pl> wrote in message
news:h5ca40$2nu$1@news.onet.pl...
> Pszemol pisze:
>> "Jacek Czerwinski" <...@...z.pl> wrote in message
>
>>> Nakładki nie znam i nie będę instalował (Eclipse można powiedzieć znam)
>>
>> O jaką "nakładkę" Ci chodzi??? :-)
>
> Nakładkę do Eclipsy ... zgaduję że za drobną dodatkową opłatą ;) i w
> stosunku do kilku zer ceny 'nakładka' brzmi obraźliwie...

Nic podobnego - software jest dostępny do ściągnięcia za darmo
z witryny Altera.com :-) Całe środowisko przychodzi w pakiecie
zawierającym właśnie IDE Eclipse, biblioteki, kompilatory itp itd.
Bez licencji jesteś w stanie używać wszystkiego do pisania kodu i
jedyne w czym będziesz ograniczony to produkcja binarek do
programowania.

>> Dla mnie logiczne byłoby sugerować się #ifdef-ami tylko gdybyśmy
>> analizowali źródła w 100% tak samo jak preprocesor...
> przypuszczeń ciąg dalszy... IDE typowo dla C/C++ które mają podpowiadanie,
> prawdopodobnie dokonują mocnej walki ze źródłami (o koszcie czasowym
> podobnym do kompilacji co się czuje), tworzą jakieś tymczasowe struktury
> itd. Na najlepszych z nich szybkość podpowiadania zaledwie zbliża się do
> (nota bene) Eclipse użytej do Javy. Ale Java to język, gdzie po
> zastanowieniu specjalnie utrącono preprocesor i kilka innych właściwości,
> również z podobnych powodów.
>
> Bardzo często w C++ wyłączam 'udogodnienia' (np na Borlandzie zawsze) bo
> więcej wkurza niż pomaga lub przełączam tylko na życzenie.

Podpowiadanie nazw symboli to rzeczywiście już luksus, czego
nie wymagam nawet - ale okienko z listą funkcji było już 20 lat
temu w dosowym edytorze dla programistów BRIEF...
Nie wiem jak tamten radził sobie z nazwami funkcji obkładanymi
warunkową kompilacją preprocesora, ale myślę że je olewał i mimo
wykluczenia w danej konfiguracji definicji je wyświetlał na liście.

Nie mam akurat zainstalowanego żadnego MS Visuala, bo tam też
jest lista funkcji z pliku źródłowego otwartego w edytorze...
Ciekawe jak się ta lista w MS Visualu zachowuje pod kątem preprocesora.

> > a jak nie w 100%
>> to wyrzucamy całą funkcję i pokazujemy w tym oknie WSZYSTKIE symbole.
> Jakby pomyśleć dłużej, wymyśliłbym kontrprzykład do tej idei (ale mi się
> nie chce). Np. niektóre symbole np. TRUE/FALSE min/max by w ogóle nie
> istniały bez preprocesora, inne by istniały pod innymi nazwami.
>
> Nie dość że nie pomagam a przypuszczam, to na marginesie dodam złośliwie
> że w sursach pisanych przez elektroników makra C są często użyte bez
> zrozumienia a nawet w sposób groźny dla życia (przykład moja maszynka do
> golenia). Jeśli producent pochodzi z tych kręgów, to ho ho .... wszystko
> możliwe.

Sam fakt że golarka może mieć jakiś software wydaje się być groźne dla życia
;-)
Swoją drogą nie widzę nic złego w użytej przeze mnie metodzie segmentacji
kodu aby pracował na dwu róznych platformach sprzętowych... Na jednej
z nich kod ma chodzić w całości na drugiej - duze jego fragmenty są usunięte
jako że hardware tego nie wspiera - po co ma kod wisieć i zajmować pamięć.
Problem w tym, że IDE ukrywa mi tą część kodu warunkowego co nieco wkurza
:-(

do góry

"mk" <r...@m...remove> wrote in message
news:h5casl$p82$1@news.wp.pl...
> Pszemol pisze:
>
>> Wszystko pięknie i ładnie dopóki używamy symboli preprocesora
>> znanych w IDE - czyli tych ustawionych w opcjach preprocesora...
>> Jeśli obłożmy zmienną lub funkcję dyrektywą #ifdef...#endif
>> i symbol testowany jest zdefiniowany w pliku nagłówkowym
>> włączanym do źródeł instrukcją preprocesora #include to okienko
>> Outline, nie znając tego symbolu, nie pokazuje tej funkcji/zmiennej
>> na liście. Można się domyślać, że dzieje się tak bo program nie czyta
>> plików #include i nie rozwija tam zawartych dyrektyw preprocesora.
>
> Indekser Eclipsa zagląda do plików nagłówkowych i analizuje ich
> treść, o ile potrafi odpowiednie pliki nagłówkowe zlokalizować.

Pliki nagłówkowe są w domyślnych lokalizacjach, nie działają
nawet #define zrobione w stdio.h takie jak NULL...

Wychodzę być może z błędnego założenia że jeśli kompilator
i preprocesor znajdują pliki nagłówkowe to powinien je również
znaleźć "indekser" eclipsa.

> Foldery z plikami nagłówkowymi należy wskazać (zobacz
> właściwościach projektu "path and symbols"->Includes).

A tu mnie zaciekawiłeś... Dla mojego dużego projektu nie ma
takiej opcji po lewej stronie okienka! Gdy stworzę nowiutki projekt
hello-world od zera w tej wersji Eclipse to wtedy mam po lewej
stronie Include Paths and Symbols. Co ciekawe, okienko po prawej
jest już wypełnione ścieżkami "CDT Managed Build Project" oraz
"Discovered Paths" i ta druga ma wszystko dotyczące stdio.h.
W tym samym okienku po prawej stronie, jest też lista nazwana
Preprocessor symbols, i są tam tylko symbole zdefiniowane
w IDE, nie ma np. symbolu NULL zdefiniowanego w stdio.h jako 0.
Nie ma też charakterystycznego symbolu _STDIO_H_ zdefiniowanego
w pierwszej linii tego pliku nagłówkowego... Żenada.

> Lista folderów przeszukiwanych z plikami nagłówkowymi jest
> wyświetlana w "Project Explorer" ("Includes").
>
> Poprawność lokalizacji można przetestować poprzez wskazanie kursorem
> wybranego pliku nagłówkowego i naciśnięcie F3 (przy standardowych
> ustawieniach). Jeśli Eclipse jest w stanie zlokalizować plik nagłówkowy,
> to po tej akcji nastąpi przełączenie do okienka edycji pliku nagłówkowego.

Tak, "Includes" pojawia się tam jednak dopiero po pierwszej
kompilacji w moim Eclipse. Dla nowoutworzonych projektów
nie ma tej listy. W projekcie hello-world jaki właśnie utworzyłem
po kompilacji mam na liście Includes plik stdio.h, po kliknięciu
na nim otwiera się bez problemów jego treść w okienku edytora.
Ale F3 nie dziala.

> Warto sprawdzić ustawienia indeksera (szukaj "Indexer" we właściwościach
> projektu). Może jest w ogóle wyłączony... Zwykle powinien wystarczyć tryb
> "Fast". W starszych wersjach Eclipsa czasami trzeba było ustawić opcję
> "Full".

Jest Full a mimo to nie radzi sobie.

> Czasami zdarza się, że indekser pójdzie gdzieś w maliny, wtedy zwykle
> pomaga przeindeksowanie projektu na nowo: kliknij myszką na folderze
> projektu i rozwiń menu podręczne, dalej "Index"->"Rebuild".

Mam "Rebuild index" ale wydanie tego polecenia nie pomaga.

do góry

Użytkownik "Pszemol" <P...@P...com> napisał w wiadomości
news:h5bpce.aas.0@poczta.onet.pl...
> "Jacek Czerwinski" <...@...z.pl> wrote in message
> news:h5ca40$2nu$1@news.onet.pl...
>> Pszemol pisze:
>>> "Jacek Czerwinski" <...@...z.pl> wrote in message
>>
>>>> Nakładki nie znam i nie będę instalował (Eclipse można powiedzieć znam)
>>>
>>> O jaką "nakładkę" Ci chodzi??? :-)
>>
>> Nakładkę do Eclipsy ... zgaduję że za drobną dodatkową opłatą ;) i w
>> stosunku do kilku zer ceny 'nakładka' brzmi obraźliwie...
>
> Nic podobnego - software jest dostępny do ściągnięcia za darmo
> z witryny Altera.com :-) Całe środowisko przychodzi w pakiecie
> zawierającym właśnie IDE Eclipse, biblioteki, kompilatory itp itd.
> Bez licencji jesteś w stanie używać wszystkiego do pisania kodu i
> jedyne w czym będziesz ograniczony to produkcja binarek do
> programowania.


Eclipse samo w sobie nie jest IDE programistycznym, tylko frameworkiem i
swego rodzaju API dla osób, które chcą zaprojektować w miarę wygodne IDE.
Każda "personalizacja" umożliwiająca programowanie w PHP, C, C++,
projektowanie tematów dla Symbiana s60 czy pisanie tekstów w osadzonym OOo
ma postać nakładki, czy - jak wolisz - plugina do samego frameworka Eclipse.

Możesz tego od razu nie zauważyć, bo w przypadku zastosowania o którym
wspomniałeś, Eclipse jest dostarczane wraz ze spreinstalowaną i
skonfigurowaną nakładką.

Pozdrawiam -- Spook.

--
! ._______. Warning: Lucida Console sig! //) !
! || spk || www.spook.freshsite.pl / _ """*!
! ||_____|| spook at op.pl / ' | ""!
! | ___ | tlen: spoko_ws gg:1290136 /. __/"\ '!
! |_|[]_|_| May the SOURCE be with you! \/) \ !

do góry

"Wojciech "Spook" Sura" <s...@s...please.op.pl> wrote in message
news:h5cs1m$j0d$1@inews.gazeta.pl...
> Eclipse samo w sobie nie jest IDE programistycznym, tylko frameworkiem i
> swego rodzaju API dla osób, które chcą zaprojektować w miarę wygodne IDE.
> Każda "personalizacja" umożliwiająca programowanie w PHP, C, C++,
> projektowanie tematów dla Symbiana s60 czy pisanie tekstów w osadzonym OOo
> ma postać nakładki, czy - jak wolisz - plugina do samego frameworka
> Eclipse.
>
> Możesz tego od razu nie zauważyć, bo w przypadku zastosowania o którym
> wspomniałeś, Eclipse jest dostarczane wraz ze spreinstalowaną i
> skonfigurowaną nakładką.

Acha... teraz rozumiem. :-) Dzięki.
Tak czy inaczej najwyraźniej "nakładka" Altery jest "skopcona".
Albo wciąż czegoś nie umiem tu ustawić aby było cacy.

do góry

>> Indekser Eclipsa zagląda do plików nagłówkowych i analizuje ich
>> treść, o ile potrafi odpowiednie pliki nagłówkowe zlokalizować.
> Pliki nagłówkowe są w domyślnych lokalizacjach, nie działają
> nawet #define zrobione w stdio.h takie jak NULL...

Ale skąd ECLIPSE wie, gdzie Twój kompilator szuka plików stdio.h i
innych? Ma się domyslić?? :)...

> Wychodzę być może z błędnego założenia że jeśli kompilator
> i preprocesor znajdują pliki nagłówkowe to powinien je również
> znaleźć "indekser" eclipsa.

Tak, to bardzo błędne założenie :). Popatrz, kompilator też nie szuka
tych plików po całym dysku, tylko wie, gdzie ich szukać :). Ponieważ są
to pliki instalowane razem z kompilatorem, to nie musisz ich wskazywać!
Gorzej ma Eclipse... on nie ma pojęcia co gdzie jest i musisz mu to
wskazać. Jak - już chyba wiesz (było napisane ;)).

<CIACH!!>

Z tego, co dalej piszesz wynika, że problem może leżeć jednak gdzieś
indziej... no cóż... To jest duży program i ma wiele ustawień, łatwo się
pogubić... ja też za każdym razem, gdy zaczynam nowy program, to wyważam
otwarte drzwi ;P... to jest masakra po prostu ;)...

A kiedyś miałem inny przypadek... używając klawisza F3 odszukiwałem
definicję jakiejś funkcji, tam ją edytowałem i kompilowałem. I się
dziwiłem czemu nie działa... rozwiązanie - w Eclipse miałem ustawione
inne ścieżki niż w Makefile no i to, co Eclipse pokazywał po naciśnięciu
F3, to był zupełnie inny plik niż ten, który był kompilowany ;D...

Pozdrawiam
Konop

do góry