Sugestia o niezainicjalizowaniu stringa mimo inicjalizacji.

0

Cześć.

Napotkałem dziwne sugestię w Lazarusie. Nie wiem, czy to specyfika Lazarusa, ale postanowiłem napisać kod bez ostrzeżeń i potencjalnie niebezpiecznych konstrukcji, i dlatego zwracam uwagę, natomiast kod który na co dzień utrzymuje posiada taką ilość ostrzeżeń, że nikt nawet tego nie przegląda... wiem, życie...

Ogólnie inicjuje pewną długością łańcuch znaków, po czym wkładam "coś nie coś" do środka i wypisuje(lub zwracam z funkcji, do dalszej manipulacji - ta procedura jest tylko przykładem).

procedure MakeSomeWithString;
var
  line: string;
begin
  Setlength(line,20);  //<-- ostrzeżenie
  line := line + LineEnding;

  line[5] := 'X';

  Write(line);
end;

w linii zaznaczonej w kodzie wyżej dostaję taką sugestie:

Test.lpr(84,17) Hint: Local variable "line" of a managed type does not seem to be initialized

Czyżby Setlength nie inicjował zmiennej o danej rozpiętości, oraz późniejsze przypisanie wartości do poszczególnych indeksów tego nie robiło?

0

Btw, skoro line := nadpisuje cokolwiek wcześniej znajdowało się w tej zmiennej, to wywołanie SetLength() nie ma sensu - doesn't it?

4

nadałeś jej rozmiar ale nadal nie wiadomo co tam jest w środku. Powinieneś użyć http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/System_StringOfChar@[email protected] albo po prostu line := 'xxxxxxxxxxxxxxxxxxxx'; czy czego tam potrzebujesz w środku

0

@abrakadaber: zastosowanie tej funkcji pomogło. Natomiast mam wrażenie, że wykonuje się wolniej niż SetLength, wieczorem to zmierzę. Natomiast co jest w stringu po ustawieniu samego rozmiaru? Rozumiem, że jakieś śmieci z pamięci, rzeczy nieustalone? Jeśli zależy mi na doklejeniu czegoś na koniec stringa, oraz późniejsze jego uzupełnienie (jakąś logiką), to chyba nie jest niebezpiecznym zostawić tam śmieci, skoro zaraz i tak będę tam wkładał inne docelowe wartości?

Zresztą po SetLength wkładam tam wartości i on nadal twierdzi,że lepiej, żebym zainicjował na początku... coś ten lazarus hints nadgorliwe...

1

Dlatego masz tylko poradę (Hint) a nie ostrzeżenie (WARNING). W przypadkach kiedy doskonale wiesz co robisz powinieneś używać:
https://wiki.freepascal.org/Turn_warnings_and_hints_on_or_off

0
somedev napisał(a):

Zresztą po SetLength wkładam tam wartości i on nadal twierdzi,że lepiej, żebym zainicjował na początku... coś ten lazarus hints nadgorliwe...

Z tego co piszesz, to Tobie nie jest potrzebny string tylko array of char...

1
wloochacz napisał(a):
somedev napisał(a):

Zresztą po SetLength wkładam tam wartości i on nadal twierdzi,że lepiej, żebym zainicjował na początku... coś ten lazarus hints nadgorliwe...

Z tego co piszesz, to Tobie nie jest potrzebny string tylko array of char...

Dlaczego tak sądzisz? Co prawda może faktycznie wykorzystuję to bardziej jak tablicę/bufor ale przerabiając to ze string na array of char tracę możliwość szybkiego łączenia i przypisań przez = oraz +. Poza utratą tego "lukru", który dla większości jest czymś normalnym nie zyskuje nic, ponieważ sugestia, że zmienna nie jest alokowana nadal pozostaje. Dodatkowo używanie array of char nie jest zalecane i tutaj się zgadzam, chyba, że ktoś wie co robi... ale pozostaje problem robienia wszystkiego na piechotę. Chyba po prostu zignoruje ten komunikat. Wyłączać ogólnie go nie będę bo może gdzie indziej mi podpowie coś mądrego.

2
somedev napisał(a):

[…] ponieważ sugestia, że zmienna nie jest alokowana nadal pozostaje.

Sugestia (hint) dotyczy inicjalizacji, nie alokacji. SetLength w działaniu jest identyczny jak np. GetMem – dostajesz blok pamięci wypełniony losowymi danymi. Aby sobie taki blok przygotować i mieć pewność, że zawiera on konkretne dane, kolejnym krokiem jest np. FillChar lub dla dużych bloków FillWord.

Podpowiedź na temat braku inicjalizacji jest słuszna – w końcu nie zdefiniowałeś wartości wszystkich komórek tego bloku, więc program może zadziałać nie tak jak sobie tego życzysz. Pierwszy problem może się pojawić np. gdy zrzutujesz ten ciąg znaków na PChar – jeśli wewnątrz bloku znajdzie się choćby jeden znak NULL, to w rezultacie otrzymasz za krótki ciąg (do pierwszego #0).

Dodatkowo używanie array of char nie jest zalecane […]

Nie słyszałem o takich zaleceniach. Zresztą w większości przypadków tego typu zalecenia to bulshit – używasz tego co spełnia wymagania i pozwala zaimplementować dany algorytm. A czy skorzystasz z ciągu znaków, tablicy znaków czy surowego bloku to już mało istotne. Byle dało się z kodem wygodnie i szybko pracować.

Wyłączać ogólnie go nie będę bo może gdzie indziej mi podpowie coś mądrego.

Dokładnie – trzeba wiedzieć o tym co się dzieje w kodzie. Jeśli używasz Lazarusa, to kompilacja projektu w trybie debug zawsze powinna skutkować dodaniem jednej linijki do okienka komunikatów:

Compile Project, Mode: Debug, Target: foo.exe: Success

przy ustawionej opcji Filter non urgent Messages na domyślne Filter hints and below. Tryb release to już inna bajka, bo tam z reguły pojawiają się ostrzeżenia wynikające z nadgorliwości kompilatora przy włączonych mocnych optymalizacjach.

Natomiast same buildy debug i release polecam sobie wygenerować w oknie ustawień projektu.

0
furious programming napisał(a):
somedev napisał(a):

[…] ponieważ sugestia, że zmienna nie jest alokowana nadal pozostaje.

Sugestia (hint) dotyczy inicjalizacji, nie alokacji. SetLength w działaniu jest identyczny jak np. GetMem – dostajesz blok pamięci wypełniony losowymi danymi. Aby sobie taki blok przygotować i mieć pewność, że zawiera on konkretne dane, kolejnym krokiem jest np. FillChar lub dla dużych bloków FillWord.

Nie mogę znaleźć źródeł SetLength - w jakim pliku je znajdę?

Podpowiedź na temat braku inicjalizacji jest słuszna – w końcu nie zdefiniowałeś wartości wszystkich komórek tego bloku, więc program może zadziałać nie tak jak sobie tego życzysz. Pierwszy problem może się pojawić np. gdy zrzutujesz ten ciąg znaków na PChar – jeśli wewnątrz bloku znajdzie się choćby jeden znak NULL, to w rezultacie otrzymasz za krótki ciąg (do pierwszego #0).

Zgadzam się, przy tym, jak używa się stringa "normalnie". Ja używam jako bufor wyjściowy. Kod, którego nie zamieściłem skrupulatnie wypełnia każdą komórkę stringa, więc jest on w pełni zainicjowany. Dlatego uważam, że stosowanie FillChar, czy StingOfChar jest zbędne i nadmiarowe. Niestety analizator kodu Lazarusa nie radzi sobie z detekcją, że w dalszej części kodu jest tablica/łańcuch wypełniona.

Dodatkowo używanie array of char nie jest zalecane […]

Nie słyszałem o takich zaleceniach. Zresztą w większości przypadków tego typu zalecenia to bulshit – używasz tego co spełnia wymagania i pozwala zaimplementować dany algorytm. A czy skorzystasz z ciągu znaków, tablicy znaków czy surowego bloku to już mało istotne. Byle dało się z kodem wygodnie i szybko pracować.

Zgodzę się i nie zgodzę ;) Jeśli ktoś zrobi tablicę tablicę wskaźników na na obiekty zawierające obiekt z kluczem stringowym to na review odrzucę to, bo winny użyć TStringList. Patrząc na tworzenie kody w zespole, powinno stosować się bezpieczne i powszechnie używane rzeczy. Sądzę, że to niezalecanie array of char, jest w sprawie używania tego jako łańcuchów reprezentujących tekst, do składania komunikatów etc. Faktycznie, ja nie używam łańcucha jako komunikatu, a jako bufora więc może array of char nie jest tutaj niebezpieczne, niemniej nie widzę żadnych korzyści w jego stosowaniu. Co do niezalecania - podaje źródło - https://wiki.freepascal.org/Character_and_string_types rozdział o Array Of Char.

Ostatecznie każdy powinien przemyśleć decyzje i nie stosować na ślepo dokumentacji, ale ja nie widzę takiego powodu, by zastępować array of char stringa.

Wyłączać ogólnie go nie będę bo może gdzie indziej mi podpowie coś mądrego.

Dokładnie – trzeba wiedzieć o tym co się dzieje w kodzie. Jeśli używasz Lazarusa, to kompilacja projektu w trybie debug zawsze powinna skutkować dodaniem jednej linijki do okienka komunikatów:

Compile Project, Mode: Debug, Target: foo.exe: Success

przy ustawionej opcji Filter non urgent Messages na domyślne Filter hints and below. Tryb release to już inna bajka, bo tam z reguły pojawiają się ostrzeżenia wynikające z nadgorliwości kompilatora przy włączonych mocnych optymalizacjach.

Natomiast same buildy debug i release polecam sobie wygenerować w oknie ustawień projektu.

Czyli on nadal hinty jakoś klasyfikuje, ukrył hint o SetLength ale zostawił np. o nieużywanych zmiennych. Fajna opcja, dzięki.

1
somedev napisał(a):
furious programming napisał(a):
somedev napisał(a):

[…] ponieważ sugestia, że zmienna nie jest alokowana nadal pozostaje.

Sugestia (hint) dotyczy inicjalizacji, nie alokacji. SetLength w działaniu jest identyczny jak np. GetMem – dostajesz blok pamięci wypełniony losowymi danymi. Aby sobie taki blok przygotować i mieć pewność, że zawiera on konkretne dane, kolejnym krokiem jest np. FillChar lub dla dużych bloków FillWord.

Nie mogę znaleźć źródeł SetLength - w jakim pliku je znajdę?

Podpowiedź na temat braku inicjalizacji jest słuszna – w końcu nie zdefiniowałeś wartości wszystkich komórek tego bloku, więc program może zadziałać nie tak jak sobie tego życzysz. Pierwszy problem może się pojawić np. gdy zrzutujesz ten ciąg znaków na PChar – jeśli wewnątrz bloku znajdzie się choćby jeden znak NULL, to w rezultacie otrzymasz za krótki ciąg (do pierwszego #0).

Zgadzam się, przy tym, jak używa się stringa "normalnie". Ja używam jako bufor wyjściowy. Kod, którego nie zamieściłem skrupulatnie wypełnia każdą komórkę stringa, więc jest on w pełni zainicjowany.

Czyli dokładnie jak tablicy.

Dlatego uważam, że stosowanie FillChar, czy StingOfChar jest zbędne i nadmiarowe. Niestety analizator kodu Lazarusa nie radzi sobie z detekcją, że w dalszej części kodu jest tablica/łańcuch wypełniona.

Testy też uważasz za nadmiarowe?
Praktyki programowania defensywnego też niepotrzebne?
Może i nadmiarowe, ale to po prostu dobra praktyka jest.
Nikt, kto spędził dziesiątki/setki godzin na szukanie niedeterministycznego błędnego kodu z dobrymi praktykami nie będzie dyskutował.

Dodatkowo używanie array of char nie jest zalecane […]

Nie słyszałem o takich zaleceniach. Zresztą w większości przypadków tego typu zalecenia to bulshit – używasz tego co spełnia wymagania i pozwala zaimplementować dany algorytm. A czy skorzystasz z ciągu znaków, tablicy znaków czy surowego bloku to już mało istotne. Byle dało się z kodem wygodnie i szybko pracować.

Zgodzę się i nie zgodzę ;) Jeśli ktoś zrobi tablicę tablicę wskaźników na na obiekty zawierające obiekt z kluczem stringowym to na review odrzucę to, bo winny użyć TStringList.

Może 10 lat temu, ale dziś to raczej powinien użyć TDictionary<string, class> a w FPC może bardziej TFPObjectHashTable; nie wiem, nie znam się na FPC.

Używa się do danych celów takich struktur które spełniają minimalne warunki.
Używania TStringListy do takich celów uważam za niepotrzebną zaszłość.
A tekst w stylu "używanie array of char nie jest zalecane" jest po postu głupi i nie da się tego obronić, zwłaszcza że padł bez kontekstu.

Patrząc na tworzenie kody w zespole, powinno stosować się bezpieczne i powszechnie używane rzeczy.

U mnie powszechnie używane rzeczy to typy generyczne na przykład.
A u Ciebie TStringList i broń Boże na pewno nie TArray<char>?

Sądzę, że to niezalecanie array of char, jest w sprawie używania tego jako łańcuchów reprezentujących tekst, do składania komunikatów etc. Faktycznie, ja nie używam łańcucha jako komunikatu, a jako bufora więc może array of char nie jest tutaj niebezpieczne, niemniej nie widzę żadnych korzyści w jego stosowaniu.

Nie jest niebezpieczne, tylko właśnie w takim celu jest powszechnie używane.
Period.
Strach się bać, co jeszcze odrzucasz/sugerujesz na code review...

Co do niezalecania - podaje źródło - https://wiki.freepascal.org/Character_and_string_types rozdział o Array Of Char.

Dobrze, nie znam tajemnej wiedzy FPC i być może trzeba umieć tamtejszą dokumentację, ale...
Ja to rozumiem tak, że Array Of Char nie jest zalecane jako substytut (zamiennik) dla typu string.
Można tak tego używać, ale już nie trzeba bo FPC (hurra! :D) obsługuje typ string.
I super, ale u Ciebie jest dokładnie odwrotnie - Ty używasz typu string jako zamiennika dla array of char i jeszcze twierdzisz, ze array of char jest niezalecany.
No nie.

Ostatecznie każdy powinien przemyśleć decyzje i nie stosować na ślepo dokumentacji, ale ja nie widzę takiego powodu, by zastępować array of char stringa.

Wyłączać ogólnie go nie będę bo może gdzie indziej mi podpowie coś mądrego.

W FPC nie można ostrzeżeń wyłączyć tylko dla danego kawałka kodu?
Z tego co rozumiem, to można:
https://wiki.freepascal.org/Turn_warnings_and_hints_on_or_off

Skoro chcesz zachować obsługę na string to dla tego kawałka kodu wyłącz ostrzeżenia.
A nie dal wszystkiego; naprawdę nie ogarniam co Wy z tym kodem robicie ;-)

Dokładnie – trzeba wiedzieć o tym co się dzieje w kodzie. Jeśli używasz Lazarusa, to kompilacja projektu w trybie debug zawsze powinna skutkować dodaniem jednej linijki do okienka komunikatów:

Compile Project, Mode: Debug, Target: foo.exe: Success

przy ustawionej opcji Filter non urgent Messages na domyślne Filter hints and below. Tryb release to już inna bajka, bo tam z reguły pojawiają się ostrzeżenia wynikające z nadgorliwości kompilatora przy włączonych mocnych optymalizacjach.

Natomiast same buildy debug i release polecam sobie wygenerować w oknie ustawień projektu.

Czyli on nadal hinty jakoś klasyfikuje, ukrył hint o SetLength ale zostawił np. o nieużywanych zmiennych. Fajna opcja, dzięki.

RTFM drogi kolego :)

0
wloochacz napisał(a):
somedev napisał(a):
furious programming napisał(a):
somedev napisał(a):

[…] ponieważ sugestia, że zmienna nie jest alokowana nadal pozostaje.

Sugestia (hint) dotyczy inicjalizacji, nie alokacji. SetLength w działaniu jest identyczny jak np. GetMem – dostajesz blok pamięci wypełniony losowymi danymi. Aby sobie taki blok przygotować i mieć pewność, że zawiera on konkretne dane, kolejnym krokiem jest np. FillChar lub dla dużych bloków FillWord.

Nie mogę znaleźć źródeł SetLength - w jakim pliku je znajdę?

Podpowiedź na temat braku inicjalizacji jest słuszna – w końcu nie zdefiniowałeś wartości wszystkich komórek tego bloku, więc program może zadziałać nie tak jak sobie tego życzysz. Pierwszy problem może się pojawić np. gdy zrzutujesz ten ciąg znaków na PChar – jeśli wewnątrz bloku znajdzie się choćby jeden znak NULL, to w rezultacie otrzymasz za krótki ciąg (do pierwszego #0).

Zgadzam się, przy tym, jak używa się stringa "normalnie". Ja używam jako bufor wyjściowy. Kod, którego nie zamieściłem skrupulatnie wypełnia każdą komórkę stringa, więc jest on w pełni zainicjowany.

Czyli dokładnie jak tablicy.

Tak masz racje, ale korzystam z przeciążenia +, żeby czasem połączyć bufory.

Dlatego uważam, że stosowanie FillChar, czy StingOfChar jest zbędne i nadmiarowe. Niestety analizator kodu Lazarusa nie radzi sobie z detekcją, że w dalszej części kodu jest tablica/łańcuch wypełniona.

Testy też uważasz za nadmiarowe?
Praktyki programowania defensywnego też niepotrzebne?
Może i nadmiarowe, ale to po prostu dobra praktyka jest.
Nikt, kto spędził dziesiątki/setki godzin na szukanie niedeterministycznego błędnego kodu z dobrymi praktykami nie będzie dyskutował.

Sam mi zarzucasz wyrywanie z kontekstu, a sam to robisz.... W tym jednym przypadku uważam, za nadmiarowe, gdzie linijkę niżej wypełniam cały łańcuch. Jeśli łańcuch miał by iść gdzieś dalej w ramach jakiej logiki być wypełniany lub nie, sklejany etc. to ofc bym to wypełnił na początku jakimiś wartościami początkowymi.

Dodatkowo używanie array of char nie jest zalecane […]

Nie słyszałem o takich zaleceniach. Zresztą w większości przypadków tego typu zalecenia to bulshit – używasz tego co spełnia wymagania i pozwala zaimplementować dany algorytm. A czy skorzystasz z ciągu znaków, tablicy znaków czy surowego bloku to już mało istotne. Byle dało się z kodem wygodnie i szybko pracować.

Zgodzę się i nie zgodzę ;) Jeśli ktoś zrobi tablicę tablicę wskaźników na na obiekty zawierające obiekt z kluczem stringowym to na review odrzucę to, bo winny użyć TStringList.

Może 10 lat temu, ale dziś to raczej powinien użyć TDictionary<string, class> a w FPC może bardziej TFPObjectHashTable; nie wiem, nie znam się na FPC.

Jak ktoś ma komfort używania nowszych Delphi to używa TDictionary ;) Zgodzę się, jest to lepsze.

Używa się do danych celów takich struktur które spełniają minimalne warunki.
Używania TStringListy do takich celów uważam za niepotrzebną zaszłość.
A tekst w stylu "używanie array of char nie jest zalecane" jest po postu głupi i nie da się tego obronić, zwłaszcza że padł bez kontekstu.

Fakt wyrwałem to z dokumentacji, ale patrząc na to, że chce używać +, to nie wiem dlaczego ten Array of Char miał by być zyskiem nad String.

Patrząc na tworzenie kody w zespole, powinno stosować się bezpieczne i powszechnie używane rzeczy.

U mnie powszechnie używane rzeczy to typy generyczne na przykład.
A u Ciebie TStringList i broń Boże na pewno nie TArray<char>?

Sądzę, że to niezalecanie array of char, jest w sprawie używania tego jako łańcuchów reprezentujących tekst, do składania komunikatów etc. Faktycznie, ja nie używam łańcucha jako komunikatu, a jako bufora więc może array of char nie jest tutaj niebezpieczne, niemniej nie widzę żadnych korzyści w jego stosowaniu.

Nie jest niebezpieczne, tylko właśnie w takim celu jest powszechnie używane.
Period.
Strach się bać, co jeszcze odrzucasz/sugerujesz na code review...

Strach raczej patrzeć na kod w którym składa się komunikaty użytkownika w tablicach.... to do czego niby i czy kiedykolwiek stosujesz String?

Co do niezalecania - podaje źródło - https://wiki.freepascal.org/Character_and_string_types rozdział o Array Of Char.

Dobrze, nie znam tajemnej wiedzy FPC i być może trzeba umieć tamtejszą dokumentację, ale...
Ja to rozumiem tak, że Array Of Char nie jest zalecane jako substytut (zamiennik) dla typu string.
Można tak tego używać, ale już nie trzeba bo FPC (hurra! :D) obsługuje typ string.
I super, ale u Ciebie jest dokładnie odwrotnie - Ty używasz typu string jako zamiennika dla array of char i jeszcze twierdzisz, ze array of char jest niezalecany.
No nie.

Ja też poznaję tajniki samego FPC, bo zawsze się zrażałem przez kiepskie środowisko... niemniej staram się czytać dokumentacje ;) Co do używania stringa jako tablicy - nie można nie przyznać Ci racji, jednak korzystam z operatora + do prostego łączenia takich stringów.

Ostatecznie każdy powinien przemyśleć decyzje i nie stosować na ślepo dokumentacji, ale ja nie widzę takiego powodu, by zastępować array of char stringa.

Wyłączać ogólnie go nie będę bo może gdzie indziej mi podpowie coś mądrego.

W FPC nie można ostrzeżeń wyłączyć tylko dla danego kawałka kodu?
Z tego co rozumiem, to można:
https://wiki.freepascal.org/Turn_warnings_and_hints_on_or_off

Skoro chcesz zachować obsługę na string to dla tego kawałka kodu wyłącz ostrzeżenia.
A nie dal wszystkiego; naprawdę nie ogarniam co Wy z tym kodem robicie ;-)

No jest to jedno z rozwiązań.

Dokładnie – trzeba wiedzieć o tym co się dzieje w kodzie. Jeśli używasz Lazarusa, to kompilacja projektu w trybie debug zawsze powinna skutkować dodaniem jednej linijki do okienka komunikatów:

Compile Project, Mode: Debug, Target: foo.exe: Success

przy ustawionej opcji Filter non urgent Messages na domyślne Filter hints and below. Tryb release to już inna bajka, bo tam z reguły pojawiają się ostrzeżenia wynikające z nadgorliwości kompilatora przy włączonych mocnych optymalizacjach.

Natomiast same buildy debug i release polecam sobie wygenerować w oknie ustawień projektu.

Czyli on nadal hinty jakoś klasyfikuje, ukrył hint o SetLength ale zostawił np. o nieużywanych zmiennych. Fajna opcja, dzięki.

RTFM drogi kolego :)

Tak, nie znam jeszcze na wskroś środowiska Lazarusa.

2
somedev napisał(a):

Nie mogę znaleźć źródeł SetLength - w jakim pliku je znajdę?

Nie znajdziesz go, dlatego że jest to pseudoprocedura, której kod generowany jest w locie podczas kompilacji. Jej działanie jest różne dla różnych elementów języka – ogólnie sprowadza się do (re)alokacji bloku oraz zaktualizowania metadanych (długość, licznik referencji, strona kodowa itd.).

Niestety analizator kodu Lazarusa nie radzi sobie z detekcją, że w dalszej części kodu jest tablica/łańcuch wypełniona.

A jak jest w Delphi? FPC co nieco wykryć potrafi, ale cudów nie należy się spodziewać, bo taka skrupulatność negatywnie odbiła by się na czasie kompilacji. Gdybyś miał jawną pętlę iterującą po wszystkich znakach ciągu, to pewnie by tego hinta nie było.

Patrząc na tworzenie kody w zespole, powinno stosować się bezpieczne i powszechnie używane rzeczy.

I jedną z nich jest FillChar, rzadziej można spotkać ZeroMemory (bo stricte windowsowe), ale się zdarza. :)

Sądzę, że to niezalecanie array of char, jest w sprawie używania tego jako łańcuchów reprezentujących tekst, do składania komunikatów etc.

Dokładnie o tym jest ta wzmianka w wiki. Tablice znaków były używane 40 lat temu, kiedy język nie posiadał konkretnego typu do reprezentowania ciągów (czyli ShortString na początku, później String i kupa innych).

Czyli on nadal hinty jakoś klasyfikuje, ukrył hint o SetLength ale zostawił np. o nieużywanych zmiennych. Fajna opcja, dzięki.

Nom – komunikaty kompilacji mają swoje ”wagi”. Niektóre będą zawsze widoczne, niektóre tylko przy słabszym filtrowaniu, bo dotyczą pierdół lub rzeczy dotyczących internalsów biblioteki standardowej i/lub funkcjonalności kompilatora. Jednym z nich jest np. ten:

Hint: "inherited" not yet supported inside inline procedure/function

Pojawia się ich kilkaset przy wyłączonym filtrowaniu w moim projekcie CTCT. Nie posiadają numeru linii i modułu źródłowego, nie da się dwuklikiem przejść do linii, której dotyczą. Nie wiadomo skąd się biorą i czego dotyczą – pojawiają się nie z mojej winy.

Obstawiam, że gdzieś głęboko w internalsach stdliba ktoś użył inherited w inline'owanej rutynce w którejś metodzie którejś bazowej klasy, a że kompilator takiej konstrukcji nie wspiera to teraz za każdym razem gdy używam jakichś klas, to ten hint wyłazi. Jedyne co można z nim zrobić to odfiltrować, bo ma niską wagę.


wloochacz napisał(a):

Może 10 lat temu, ale dziś to raczej powinien użyć TDictionary<string, class> a w FPC może bardziej TFPObjectHashTable; nie wiem, nie znam się na FPC.

W module FPG jest generyczna klasa TFPGMapObject – powinna pasować do wymagań. Używam jej np. do przechowywania par łańcuch-obraz w takiej postaci:

type
  TFlagsMap = class(specialize TFPGMapObject<String, TPortableNetworkGraphic>)
  {..}

Kluczem jest nazwa państwa, a na wyjściu dostaję obraz tła. Wygodne, bo nie dość że łatwo pobrać interesujący obraz, to pamięcią obiektów zarządza klasa, więc dealokacją się nie przejmuję.

W FPC nie można ostrzeżeń wyłączyć tylko dla danego kawałka kodu?

Można, można. Wszystkie kompilatory Pascala obsługują np. {$HINTS OFF/ON} i inne, którymi można wykluczyć generowanie komunikatów dla zadanych fragmentów. Jest jeszcze makro {%H-}, ale to jest dyrektywa IDE, która pozwala ukryć dany hint w oknie komunikatów kompilacji, choć nadal będzie on generowany.

Dla wyjaśnienia – frazy z prefiksem {$ to dyrektywy kompilatora, a z {% to makra IDE.


somedev napisał(a):

W tym jednym przypadku uważam, za nadmiarowe, gdzie linijkę niżej wypełniam cały łańcuch.

Jeśli zawsze wypełniasz cały łańcuch to zignoruj ten hint – wyklucz go i z głowy.

Jak ktoś ma komfort używania nowszych Delphi to używa TDictionary ;) Zgodzę się, jest to lepsze.

Rozglądnij się po modułach dla FPC – znajdziesz w nich różne generyczne kontenery. W razie czego możesz też dociągnąć sobie bibliotekę Generics.Collections, w której znajduje się dużo więcej klas.

0
furious programming napisał(a):

Niestety analizator kodu Lazarusa nie radzi sobie z detekcją, że w dalszej części kodu jest tablica/łańcuch wypełniona.

A jak jest w Delphi? FPC co nieco wykryć potrafi, ale cudów nie należy się spodziewać, bo taka skrupulatność negatywnie odbiła by się na czasie kompilacji. Gdybyś miał jawną pętlę iterującą po wszystkich znakach ciągu, to pewnie by tego hinta nie było.

Niestety nawet wtedy tego nie wykrywa.

Jak ktoś ma komfort używania nowszych Delphi to używa TDictionary ;) Zgodzę się, jest to lepsze.

Rozglądnij się po modułach dla FPC – znajdziesz w nich różne generyczne kontenery. W razie czego możesz też dociągnąć sobie bibliotekę Generics.Collections, w której znajduje się dużo więcej klas.

Nie o FPC chodzi, często używam starych wersji delphi do bardzo starego kodu. FPC obecnie się bawię, bo o dziwo jeszcze mnie IDE nie wkurzyło tak bardzo.

Dziękuję wszystkim kolegom, za wszelkie uwagi. Dużo się dowiedziałem.

1 użytkowników online, w tym zalogowanych: 0, gości: 1