Czytanie tablicy dynamicznej z pliku

0

Cześć wszystkim. Mam napisać program, który ma najpierw zapisać dane na dysk a później je odczytać. Wygląda to tak:

type
  TData = record
    Stringi: String[64];
    Krotkie: String[64];
    I: String;
    Dlugie: String;
  end;

  TAData = array of TData;

  TConfig = record
    Left: Integer;
    Top: Integer;
    Width: Integer;
    Height: Integer;
    Count: Word; 
  end;

var
  Data: TAData;

Zapisywanie danych wydaje się odbywać poprawnie:

function TFormMain.SaveSettings: Boolean;
var
  I: Word;
  Config: TConfig;
  Count: Word;
  F: File;

begin
    AssignFile(F, 'plik');
    FileMode := fmOpenWrite;
    Rewrite(F, 1);

    with Config do begin
      Left := Self.Left;
      Top := Self.Top;
      Width := Self.Width;
      Height := Self.Height;
      Count := Length(Data);
    end;

    BlockWrite(F, Config, SizeOf(TConfig));

    if Config.Count > 0 then for I := 0 to Config.Count - 1 do begin
      BlockWrite(F, Data[I], SizeOf(TData));
    end;
    CloseFile(F);

end;

Problem pojawia się przy próbie odczytania zapisanych danych:

function TFormMain.LoadSettings: Boolean;
var
  I: Word;
  Config: TConfig;
  Count: Word;
  F: File;

begin
    AssignFile(F, 'plik');
    FileMode := fmOpenRead;
    Reset(F, 1);

    BlockRead(F, Config, SizeOf(TConfig));
    Left := Config.Left;
    Top := Config.Top;
    Width := Config.Width;
    Height := Config.Height;
    Count := Config.Count; // ilość elementów tablicy Data

    SetLength(Data, Count);
    if Count > 0 then for I := 0 to Count - 1 do begin
      BlockRead(F, Data[I], SizeOf(TData));
      // Tutaj program się wysypuje na pierwszym rekordzie z komunikatem I/O error 103
    end;
    CloseFile(F);

end;

Wcześniej próbowałem to samo zrobić za pomocą TFileStream, ale efekt był podobny (AV). Co robię nie tak? Gdzie jest błąd? Z góry dziękuję za wszelką pomoc.

0

Nie można zapisać string'ów do pliku; co najwyżej shortstring (czyli string z określoną długością), być może w tym jest problem.
Edit: string jest niejawnym wskaźnikiem, więc BlockWrite może zapisywać (a nawet na pewno zapisuje) tylko ich tymczasowe adresy, które po drugim włączeniu programu są niepoprawne.

0

Chyba zapisywałem/odczytywałem do/z pliku tego rodzaju rekordy (bodajże tagi ID3v1 do plików mp3) i nie było problemów.
Stringi muszą być być oczywiście typu ShortString, z zadeklarowaną długością albo zapisane jako tablice array[0.. n] of Char;.
Rekord musi być zadeklarowany jako packed record.

Sprawdź debuggerem jaką wartość ma Count w SetLength(Data, Count);

0

Tak jak koledzy wspomnieli - ten rekord;

type
  TData = record
    Stringi: String[64];
    Krotkie: String[64];
    I: String;
    Dlugie: String;
  end;

jest do bani; Każde pole w rekordzie musi mieć określoną długość (w bajtach), więc String się do tego nie nadaje; Co prawda błędu taki kod nie wygeneruje, ale nie zapisze na pewno poprawnie danych w takim polu zawartych; Musisz dla każdego pola tego typu określić długość, maksymalnie może to być 255 znaków (typ ShortString);

Jeżeli jednak nie możesz ustalić na sztywno długości tych łańcuchów to zawsze możesz zapisywać je ręcznie, np. pierwszy bajt (czy tam dwa dla Word) określają długość łańcucha, a dalej zapisuejsz już sam łańcuch; No niestety taki urok plików amorficznych, że ich budowa jest nieregularna, przez co jest trochę więcej roboty... :]

pelsta napisał(a)

Rekord musi być zadeklarowany jako packed record.

Dlaczego musi...? Bez pakowania też będzie działać, jednak ze względu na zajmowane miejsce w pamięci zaleca się stosowanie packed na rzecz niestety szybkości odczytu;


@MACu - jak to jest możliwe, że dopiero po ponad czterech latach napisałeś pierwszego posta...? :]

0

Zmieniłem wszystkie Stringi na ShortString i w tej chwili sytuacja wygląda tak, że program czyta tylko pierwszy rekord. Gdy jest ich więcej to przy drugim wywołaniu BlockWrite pojawia się I/O error 103. SetLength(Data, Count) ustawia długość tablicy poprawnie... :/

furious programming napisał(a):

@MACu - jak to jest możliwe, że dopiero po ponad czterech latach napisałeś pierwszego posta...? :]

Jakoś tak wyszło, że do tej pory wszystkie problemy jakie się pojawiały udawało się rozwiązać z pomocą kompendium/google ;)

0

Sprawdziłeś hexedytorem/Notatnikiem/wtf treść pliku, czy jest poprawna?

0
Patryk27 napisał(a):

Sprawdziłeś hexedytorem/Notatnikiem/wtf treść pliku, czy jest poprawna?

Tak, dane wydają się być na właściwym miejscu, długość pliku się zgadza.

0

F: File;
Jeżeli używasz FPC to zmień na F:file of byte; i sprawdź wtedy.

0

Chyba znalazłem rozwiązanie :)
Przy każdym przejściu pętli otwierać plik

    AssignFile(F, 'plik');
    FileMode := fmOpenRead;
    Reset(F, 1);
    BlockRead(F, Config, SizeOf(TConfig));
    Left := Config.Left;
    Top := Config.Top;
    Width := Config.Width;
    Height := Config.Height;
    Count := Config.Count;
    CloseFile(F);

    SetLength(Data, Count);
    if Count > 0 then for I := 0 to Count - 1 do begin
      AssignFile(F, 'plik');
      FileMode := fmOpenRead;
      Reset(F, 1);
      Seek(F, SizeOf(TConfig) + I * SizeOf(TData));
      BlockRead(F, Data[I], SizeOf(TData));
      CloseFile(F);
    end;

Dziekuję wszystkim za pomoc. Bez Was by się nie udało :)

0

Przy każdym przejściu pętli otwierać plik

Ależ IDEALNE rozwiązanie! Pogratulować. Po co rozwiązywać problem, lepiej go omijać.
Dlatego gdy moja aplikacja raz działała raz nie powiniem był zrobić system który będzie odpalać aż do skutku! Jeszcze raz pokłony za głupie podejście.

0

@MACu - przetestowałem sposób jaki próbujesz okiełznać pisząc prostą aplikację (zwykła konsolówka) i działa, popatrz na kod:

program Project1;

{$mode objfpc}{$H+}

uses
  SysUtils;

type
  TDataRec = packed record
    Str, ShortStr: String[64];
    I, LongStr: String[255];
  end;

type
  TDataArr = array of TDataRec;

type
  TConfigRec = packed record
    Left, Top, Width, Height, Count: Word;
  end;

const
  BINARY_FILE_NAME = 'C:\File.dat';

  procedure SaveSettings();
  var
    fOutput: File;
    crConfig: TConfigRec;
    aData: TDataArr;
    sID: String[4];
    I, J: Byte;
  begin
    { CONFIG REC }
    with crConfig do
      begin
        Left := 300;
        Top := 200;
        Width := 800;
        Height := 600;
        Count := 2;
      end;

    { DATA REC }
    SetLength(aData, 2);

    for J := 0 to 1 do
      with aData[J] do
        begin
          sID := '[' + IntToStr(J) + '] ';

          Str := sID + 'Str';
          ShortStr := sID + Str;
          I := sID + 'I';
          LongStr := sID + 'LongStr';
        end;

    { SAVING TO FILE }
    AssignFile(fOutput, BINARY_FILE_NAME);
    try
      ReWrite(fOutput, 1);
      { CONFIG REC }
      BlockWrite(fOutput, crConfig, SizeOf(crConfig));
      { DATA ARRAY }
      for I := 0 to 1 do
        BlockWrite(fOutput, aData[I], SizeOf(aData[I]));
    finally
      CloseFile(fOutput);
    end;
  end;

  procedure LoadSettings();
  var
    fInput: File;
    crConfig: TConfigRec;
    aData: TDataArr;
    I: Byte;
  begin
    if FileExists(BINARY_FILE_NAME) then
      begin
        AssignFile(fInput, BINARY_FILE_NAME);
        try
          Reset(fInput, 1);
          { CONFIG REC }
          BlockRead(fInput, crConfig, SizeOf(crConfig));
          WriteLn('Loaded Config:'#10);
          WriteLn('Config.Left:   "', crConfig.Left, '"');
          WriteLn('Config.Top:    "', crConfig.Top, '"');
          WriteLn('Config.Width:  "', crConfig.Width, '"');
          WriteLn('Config.Height: "', crConfig.Height, '"');
          WriteLn('Config.Count:  "', crConfig.Count, '"'#10);
          { DATA ARRAY LENGTH }
          if crConfig.Count > 0 then
            begin
              SetLength(aData, crConfig.Count);
              { DATA ARRAY }
              for I := 0 to crConfig.Count - 1 do
                begin
                  BlockRead(fInput, aData[I], SizeOf(aData[I]));
                  WriteLn('Loaded Data[', I, ']:'#10);
                  WriteLn('Data[', I, '].Str:      "', aData[I].Str, '"');
                  WriteLn('Data[', I, '].ShortStr: "', aData[I].ShortStr, '"');
                  WriteLn('Data[', I, '].I:        "', aData[I].I, '"');
                  WriteLn('Data[', I, '].LongStr:  "', aData[I].LongStr, '"'#10);
                end;
            end;
        finally
          CloseFile(fInput);
        end;
      end;
  end;

begin
  WriteLn('Binary File Test'#10);
  { SAVE CONFIG TO BINARY FILE }
  WriteLn('--------------------'#10'Saving in progress...');
  SaveSettings();
  WriteLn('Saving complete.');
  { LOAD CONFIG FROM BINARY FILE }
  WriteLn('--------------------');
  LoadSettings();
  WriteLn('Loading complete.');
  Write('--------------------'#10'Press ENTER to exit...');
  ReadLn;
end.

Działa jak należy, dane po odczytaniu są idealnie takie, jakie przy zapisie; Przejżyj sobie ten kod i porównaj najważniejsze elementy ze swoim - byc może znajdziesz rozwiązanie; Niektóre rzeczy pozmieniałem (jak np. identyfikatory pól w strukturach), ale większego znaczenia to nie ma - chodzi o samą zasadę;

Pierszy programik w Lazarus'ie napisany, coraz bardziej zaczyna mi się podobać to środowisko :]

Pousuwałem jeszcze puste linie bo nie bardzo je lubicie, poza tym zmieniłem uzupełnianie struktur w macierzy z ręcznego na pętlę - mniej pisania;

0
-123oho napisał(a):

Ależ IDEALNE rozwiązanie! Pogratulować. Po co rozwiązywać problem, lepiej go omijać.

No jest to trochę ominięcie problemu ale na moje potrzeby wystarczyłoby. Tam będzie max kilkanaście rekordów. Przejże jeszcze raz wszystko i porównam z kodem od Furious Programming. Może uda się to napisać normalniej.

0

No jest to trochę ominięcie problemu ale na moje potrzeby wystarczyłoby. Tam będzie max kilkanaście rekordów. Przejże jeszcze raz wszystko i porównam z kodem od Furious Programming. Może uda się to napisać normalniej.

Dobrze, odwlekaj ten problem na później. Potem będziesz miał całą appkę która się kraszuje z bliżej nieznanych powodów. Powodzenia w takim rozwiązaniu problemów, prędzej czy później zapłacisz za swoją głupotę.

0

[Ile waży exe?] Ponad 7 MB :)

No to widać że z używaniem narzędzi też masz problem...

Taką appkę bez LCL można spokojnie upakować do 100-500kb zależnie od dodatkowych rzeczy w stylu biblioteki kryptograficzne/synapse etc etc.

@pelsta , ja wiem że na początku to dziwnie wygląda że aplikacja ma 600kb po maksymalnej kompresji ale wynika to z ogromnej ilości RTLu, LCLu itd. . Jak dorzucisz do tego 3000linii kodu to rozmiar EXE nie zmieni się bardzo...

Skompilowany program furiousa przy normalnym trybie release dał mi 82kb. Po moich 5minutowych przeróbkach zajął wynikowo 18kb. Dużo?

Może zamiast słuchać kolegi który jest początkujący posłuchasz osób które tutaj mają staż i coś umieją, zwłaszcza że pobranie, instalacja i przetestowanie nie kosztują nic poza twoim czasem którego możesz oszczędzić dzięki temu dużo...

0
pelsta napisał(a)

Ile waży exe?

Waga Funkcja odchudzająca Opis
144 Kb - normalnie skompilowana aplikacja
88,5 Kb -Xg wykorzystanie zewnętrznego pliku symboli debugger'a
88 Kb strip.exe --strip-all wykorzystanie stripera z opcją wyrzucającą co się da
35 Kb strip.exe --strip-all + upx.exe -9 wykorzystanie stripera i upx z najmocniejszym pakowaniem
Jak widać Lazarus nie taki straszny, jak o nim mówią;
-123oho napisał(a)

Po moich 5minutowych przeróbkach zajął wynikowo 18kb. Dużo?

Ciekawe co jeszcze masz przestawione że tylko tyle Ci wyszło... :]

0

Czas oszczędzę właśnie czytając o doświadczeniach użytkowników Lazarusa. W moim ulubionym Delphi7 konsolówki też wychodzą malutkie.

Rozmiar to akurat według wielu wada lazarusa/fpc. Jak widać aż tak źle to nie wychodzi w rzeczywistości. A o tym dlaczego Lazarus jest lepszy niż Delpi7 i dlaczego skróci twój development time możesz usłyszeć od Furiousa bo ja akurat nie wiem czego Delphi7 nie miał. Czas który poświęcisz na instalację i testowanie Lazarusa na pewno nie będzie czasem zmarnowanym, a może nawet pozwoli ci przejść na środowisko o 10 lat nowsze.

Ciekawe co jeszcze masz przestawione że tylko tyle Ci wyszło...

Po prostu umiem się dogadać z FPC i innymi narzędziami :P

0

Korzystając z Delphi 7 wypadło to tak:

Waga (Kb) Funkcja odchudzająca Opis
46Kb - normalna kompilacja
46Kb strip.exe --strip-all wykorzystanie stripera
24Kb upx.exe -9 wykorzystanie upx.exe z najsilniejszą opcją pakującą (rzekomo)
46Kb strip.exe --strip-all + upx.exe -9 błąd: CantPackException: writeable shared sections not supported (try --force)
24,5Kb strip.exe --strip-all + upx.exe --force użycie stripera i upx z zalecaną opcją pakującą
też nie wypada to źle - kwestia gustu; Używając tych samych zabiegów co wcześniej dla programu skompilowanego w Lazarus'ie ten wynik jest lepszy, ale mi nie przeszkadza różnica kilku/kilkudziesięci/kilkuset kilobajtów - wolę poświęcić mniejszą wagę aplikacji na rzecz po prostu lepszego środowiska, w którym znacznie przyjemniej tworzy się kod;

-123oho napisał(a)

Rozmiar to akurat według wielu wada lazarusa/fpc.

Zależy jak na to patrzeć - w dobie dzisiejszych komputerów aplikacja 10-megowa to teraz żaden problem przy kilkuterabajtowych dyskach i łączach światłowodowych; Mnie osobiście to nie przeszkadza, a i tak wersję ostateczną odchudzę maksymalnie i będę na pewno zadowolony (jak -123oho zdradzi mi jak się dogadać z FPC... :] );

-123oho napisał(a)

A o tym dlaczego Lazarus jest lepszy niż Delpi7 i dlaczego skróci twój development time możesz usłyszeć od Furiousa [...]

Ja nie uważam się za znawcę, ale różnica jest potężna - dziwie się samemu sobie dlaczego wcześniej nie pobrałem Lazarus'a?!; To jest to, o wiele większe możliwości, wygoda tworzenia kodu (dzięki licznym zabiegom przyspieszającym pisanie kodu) i przede wszystkim za darmo - to są dla mnie bardzo dobre wiadomości, resztę rzeczy, z których się cieszę napisałem we wcześniejszych postach i innych ostatnich tematach;

-123oho napisał(a)

[...] bo ja akurat nie wiem czego Delphi7 nie miał.

Ja miałem Delphi 7 i mam cały czas, dopóki całkowicie nie poznam Lazarus'a;
Zrozumiałem o co Ci chodziło... Delphi 7 dużo rzeczy nie ma, ale lista jest długa i nie chcę teraz bawić się w komparator;

Choć jak mam teraz oba włączone to wybór jest jeden - Lazarus :]


Poddaliście mi pomysł na napisanie artykułu z dogłębnym porównaniem ww. środowisk, może kiedys się skuszę i napiszę takowy;

0
Furious Programming napisał(a)
-123oho napisał(a)

Rozmiar to akurat według wielu wada lazarusa/fpc.

Zależy jak na to patrzeć - w dobie dzisiejszych komputerów aplikacja 10-megowa to teraz żaden problem przy kilkuterabajtowych dyskach i łączach światłowodowych;

Komputer mam jaki mam. Dla mnie problemem aplikacji 10MB jest za długi czas ładowania do RAMu. Po prostu denerwuje mnie czekanie. A dysku kilkuterabajtowego nie mam tylko 60GB :)
Delphi7 mam maksymalnie odchudzone i ładuje się 2-3 sekundy. A jak jest z Lazarusem?

Furious Programming napisał(a)

To jest to, o wiele większe możliwości, wygoda tworzenia kodu (dzięki licznym zabiegom przyspieszającym pisanie kodu)

A próbowałeś CnPack IDE Wizards?

Furious Programming napisał(a)

Poddaliście mi pomysł na napisanie artykułu z dogłębnym porównaniem ww. środowisk, może kiedys się skuszę i napiszę takowy;

Będę śledził Twoje opinie n/t Lazarusa i w końcu zainstaluję (pamiętam, że już kiedyś spróbowałem i po krótkim czasie poszedł do kosza).

0
pelsta napisał(a)

Komputer mam jaki mam. Dla mnie problemem aplikacji 10MB jest za długi czas ładowania do RAMu. Po prostu denerwuje mnie czekanie.

Mnie jeszcze nie udało się napisać aplikacji (nawet z GUI), której *.exe najowałby 10MB... Jeżeli muszę wykorzystać sporą ilość np. grafik (np. przy tworzeniu swojego MainMenu i PopupMenu) to nie łączę ich z plikiem wykonywalnym, tylko zamieszczam w zezwnętrznych bibliotekach (czy innych plikach o własnej budowie); Aplikacja wykonywalna jak dla mnie musi być lekka i w danej chwili wykorzystywać tylko te dane, które są potrzebne; Dzięki temu będę zadowolony pewnie z każdego środowiska, bo jakie ono by nie było to i tak plik wykonywalny można odchudzić;

pelsta napisał(a)

A dysku kilkuterabajtowego nie mam tylko 60GB

Nie przejmuj się bo to, że takie technologie istnieją już od dawna to nie znaczy, że każdy ma taki komputer/łącze; Ja do niedawna miałem łącze 1Mbps i wystarczało w zupełności, a pracuję na 10-letnim laptopie (IBM R31: Intel Celeron 1.13GHz, 512MB RAM, Intel 82830 48MB, 160GB HDD) - część podzespołów dokupywałem (tak jak HDD, bo miał tylko 10GB czy kość RAM, bo było tylko 256MB) - razem zapłaciłem za niego koło 600zł - nie żałuję;

pelsta napisał(a)

Delphi7 mam maksymalnie odchudzone i ładuje się 2-3 sekundy. A jak jest z Lazarusem?

Ja nic nie kombinowałem ze samym IDE Delphi 7 i ładuje mi się ok. 4 sekund (wraz z nowym projektem aplikacji); Uruchomienie Lazarus'a trwa mniej więcej tyle samo;

pelsta napisał(a)

A próbowałeś CnPack IDE Wizards?

Nie, nie próbowałem ale sprawdzę kiedyś co to takiego; W każdym razie już i tak nie powrócę do D7 - sprawdzę z ciekawości;

pelsta napisał(a)

Będę śledził Twoje opinie n/t Lazarusa i w końcu zainstaluję

Zainstaluj od razu, po co czekać - Lazarus - SourceForge :]

0

Dla mnie problemem aplikacji 10MB jest za długi czas ładowania do RAMu.

Największym EXEkiem (a właściwie ELFem) jaki wypluł mi Lazarus miał 20MB (nie licząc raz błędnej rekompilacji Lazarusa - Lazarus.exe - 50MB). Ale używając -Xg jego rozmiar od razu spadł do 2MB... Większość zajmują symbole, które można wywalić/przenieść do innego pliku i które nie są ładowane do pamięci przy ładowaniu procesu.

Ja nic nie kombinowałem ze samym IDE Delphi 7 i ładuje mi się ok. 4 sekund (wraz z nowym projektem aplikacji); Uruchomienie Lazarus'a trwa mniej więcej tyle samo;

U mnie (czyste Delphi7 którego nie używam, Lazarus "po przejściach") Lazarus włącza się widocznie szybciej dla prostych projektów, dla zaawansowanych może być nawet 6 sekund... (Komputerek ~4letni).

pracuję na 10-letnim laptopie (IBM R31: Intel Celeron 1.13GHz, 512MB RAM, Intel 82830 48MB, 160GB HDD)

Ja mam taki wolny laptop że XP+Antywirus strasznie muliły więc zainstalowałem Lubuntu i Lazarus nadal ładnie śmiga... (też Celeron ~1Ghz, 256MB ram)

A próbowałeś CnPack IDE Wizards?

A czy Twoje 'podrasowane' Delphi7 wspiera chociażby generyki? No właśnie... W FPC od 2.4.4 są generyki, co prawda póki co są jeszcze w fazie testów ale mi to nie przeszkadza ich stosować.
Już nie mówiąc o mnogości platform które Lazarus/FPC wspiera i tysiącach rzeczy które dla mnie są oczywiste a w Delphi7 problematyczne (np. TTrayIcon).
Zresztą do Lazarusa też jest Extension Pack, CodeTyphon - zawiera testowego Lazarusa z testowym FPC + masę komponentów. Nie pobieram go bo ma ~500MB :D .

Mnie jeszcze nie udało się napisać aplikacji (nawet z GUI), której *.exe najowałby 10MB...

To wywal -Xg i powinno zajmować 12MB. Nawet jeżeli ma 12MB to nie będzie całości ładować do pamięci bo symboli nie ładuje.

0

A czy Twoje 'podrasowane' Delphi7 wspiera chociażby generyki?

W temacie "Ciekawe linki" dałem link do strony jakiegoś kolesia, który modyfikował Delphi i dodał parę przydatnych funkcji do niego (string case, parę innych rzeczy i o ile dobrze pamiętam, także generyki).
To tak na marginesie ;)

0

Mnie na "Delphi 7" nie udało się tak dużego pliku wykonywalnego wygenerować (bez optymalizacji i innych zabiegów odchudzających), w "Lazarus"ie pierwsza aplikacja okienkowa zajmowała 13MB (sam formularz) zanim zacząłem bawić sie ustawieniami :)

Bo w Delphi7 masz symbole tylko do swojego pliku a w Lazarusie masz symbole też do rzeczy systemowych jak LCL i RTL. Dlatego też Lazarus czasami po wyjątku wewnątrz LCL zatrzymuje się w kodzie LCL...

Jak Delphi7 wygeneruje mi exe powyżej 1MB to wpadam w czarną rozpacz i ślęczę nad projektem żeby go zmniejszyć (bez UPXa) :) Tak już mam. Ale za to aplikacje wychodzą mi lekkie i szybkie.

Lekkie i szybkie to często odwrotność krótkie i małe. Skoro aż tak ci zależy na małym rozmiarze to najlepiej pobierz Delphi1, bo jego RTL był najkrótszy wobec czego pliki wychodzą najmniejsze. A to że nie jest on w stanie skorzystać z możliwości współczesnych procesorów to sprawa drugorzędowa. Dzisiaj kompilatory nie są robione pod minimalny rozmiar, nawet nie pod maksymalną wydajność a pod wygodę programowania.

Nie wiem co to są generyki. Stary dobry Pascal rozbudowany w Delphi wystarcza mi w zupełności.

Jeszcze jeden dowód że ograniczasz się.

0

Twoje komentarze są żałosne. To tyle.

Hatters gonna hate. Również pozdrawiam.

0
-123oho napisał(a):

Nie wiem co to są generyki. Stary dobry Pascal rozbudowany w Delphi wystarcza mi w zupełności.

Jeszcze jeden dowód że ograniczasz się.

Nie każdy musi korzystać ze wszystkiego, co oferuje najnowsze FPC (do tego biorąc pod uwagę, że - o ile mi wiadomo - generyki są jeszcze w fazie tworzenia) lub Delphi (chyba najnowsze Delphi ma już typy generyczne?).
Ja osobiście tylko raz korzystałem z generyków (patrz post #874673) a i sam o ich istnieniu dowiedziałem się niedawno.
Skoro ktoś z nich nie korzysta, to znaczy, że nie ma póki co takiej potrzeby, a komentarze w stylu "Jeszce jeden dowód, że ograniczasz się." możesz zachować dla siebie.
Jakby nie patrzeć, składnia nawet w Delphi 7 wystarczy do wygodnego stworzenia wielu rzeczy, a przecież nie posiada dodatków typu anonymouse functions czy generyki...

0

Nie każdy musi korzystać ze wszystkiego, co oferuje najnowsze FPC (do tego biorąc pod uwagę, że - o ile mi wiadomo - generyki są jeszcze w fazie tworzenia) lub Delphi (chyba najnowsze Delphi ma już typy generyczne?).

Używanie nie znaczy znanie.

Skoro ktoś z nich nie korzysta, to znaczy, że nie ma póki co takiej potrzeby, a komentarze w stylu "Jeszce jeden dowód, że ograniczasz się." możesz zachować dla siebie.

Moim zdaniem jest to ograniczanie się zwłaszcza gdy popatrzeć na resztę zachowań pelsty, chociażby "wpadanie w czarną rozpacz gdy exek ma >1mb".

Jakby nie patrzeć, składnia nawet w Delphi 7 wystarczy do wygodnego stworzenia wielu rzeczy, a przecież nie posiada dodatków typu anonymouse functions czy generyki...

To piszmy w TP7 bo przecież też się da... Ja wiem że bez generyków też się da pisać, nie bez powodu nie są one na pierwszym miejscu w FPC, ale wiele języków, np. C++ już ich używa na każdym kroku. IMO nawet jeżeli się ich nie stosuje to powinno się je znać, zwłaszcza że nie cały świat to Delphi i wypada znać chociaż trochę innych języków.

Proponuję jednak ignorować te jego żałosne komentarze.

żałosne bo śmiem Ciebie skrytykować? Jak już mówiłem hatters gonna hate.

0

Używanie nie znaczy znanie.

No ok, z tym się zgadzam, że wiedzieć nie znaczy używać.
Ale po co wiedzieć coś, czego się i tak nie będzie w większości używać?

Moim zdaniem jest to ograniczanie się zwłaszcza gdy popatrzeć na resztę zachowań pelsty, chociażby "wpadanie w czarną rozpacz gdy exek ma >1mb".

Zbyt dosłownie to rozumiesz imho.

To piszmy w TP7 bo przecież też się da...

No tak, da się.
Inna sprawa, że jest od dawien dawna nie rozwijany i nie posiada sensownego IDE.

0

Ale po co wiedzieć coś, czego się i tak nie będzie w większości używać?

O właśnie, i dochodzimy do sedna. Żeby się rozwijać, znać coś innego niż swoje podwórko i to nie tylko dlatego "bo tak" ale też dlatego że można wiele modeli i rozwiązań przenieść do siebie.
Tak właśnie też powstały generyki dla Pascala, przeniesione z C++, co prawda nie aż na taką skalę, ale jako dodatkowe rozwiązanie które ma swoje zalety.

Zbyt dosłownie to rozumiesz imho.

Ja się domyślam że to tak pół żartem pół serio, ale moim zdaniem to głupota. Niestety nie wiem jak to dokładnie wygląda, ale skoro on się ciągle zasłania większymi EXEkami w Lazarusie to uznałem że to jednak poważniejsze.

No tak, da się.
Inna sprawa, że jest od dawien dawna nie rozwijany i nie posiada sensownego IDE.

Mnie coś strzeliło jak się okazało że w TP7 nie można rekordów z funkcji zwracać i musiałem przepisać kod na procedury z dodatkowym parametrem (kod był wcześniej pisany w FPC ale docelowo miał działać na TP7). Stare rozwiązania są słabsze niż nowsze, a chciałbym zauważyć że Delphi7 ma 10 lat. Brak zainteresowania nowymi rozwiązaniami to właśnie ograniczanie się. Są nowsze rzeczy niż klasy.

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