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