Exe - konwersja na C++

[Mariusz1970]

Ok, to szukaj dalej na piechote np. nie zaincjowanych zmiennych z ktorymi miales zdaje sie problemy i straciles sporo czasu na identyfikacje problemu a to juz na tym etapie daloby sie zidentyfikowac albo poprzez gotowy albo wlasny analizator. Jesli chodzi o nieuzywane, to czesciowo juz mozna identyfikowac np. zmienne ktore sa hermetyczne w danej funkcji. Mialbys juz czysta nowa dodana funkcje, ale skoro twierdzisz, ze analizatory na tym etapuie sa bez sensu, ok. Ja nie zamierzam Cie uszczesliwiac na sile. Masz swoj styl pracy, swoje zasady, trzymaj sie ich :).

[firleju]

Problem nie leżał w tym, że zmienna nie była inicjowana w ogóle. Była. Tylko nie w konstruktorze a w funkcji inicjującej, i nie w klasie budowanej tylko w klasie matce. To było łatwo znaleźć. Większym problemem było zorientowanie się, że źle inicjowane są wartości poprzez brak uruchomienia funkcji klas matek (a nie nie inicjowane w ogóle). Tego żaden analizator mi nie znajdzie.

[Mariusz1970]

Byc moze, jednak nie wierze, aby nie dalo sie wymyslic analizatora te takie rzeczy, jesli jest warte zaintersesowania.

[firleju]

No, tylko analizator nie sprawdzi czy jest potrzeba uruchomienia danej funkcji. Może Ci sprawdzić czy robisz to optymalnie. Ale żeby nie było, żem beton (ciekawe czy Kuba się będzie rzucał), to szukam jakiegoś dobrego narzędzia i może w święta zrobię analizę. Jak będą oczywiste błędy to można poprawić, ale nie chcę grzebać w nowych miejscach jeśli jest rozgrzebane coś takiego jak cała fizyka.

[tmj]

Ale żeby nie było, żem beton (ciekawe czy Kuba się będzie rzucał), to szukam jakiegoś dobrego narzędzia i może w święta zrobię analizę.

Dla swietego spokoju mozesz kod przepuscic przez http://cppcheck.sourceforge.net/ zdaje sie ze jest calkiem przyzwoity i nie wymaga jakiegos specjalnego zaangazowania. Pisanie na wlasna reke jakis dedykowanych narzedzi raczej mija sie z celem, imo.
  Dodano: 22 Grudnia 2016, 15:57:28 Przepuscilem to co jest na githubie przez cppcheck, i troche kwiatkow znalazl, w tym kilka grubszych. Te z kategorii (error) trzeba by raczej poprawic, reszta to juz roznie. Czesc jest bardziej powazna, czesc mniej.

[firleju]

O, miło. Zerknąłem. Te z plików hamulce i Oerlikon są już nieaktualne. Tylko tych commitów nie wrzuciłem jeszcze na github-a. Chcę to jeszcze przetestować w wersji trial, któregoś z tych dużych komercyjnych analizatorów.
  Dodano: [time]23 Grudnia 2016, 10:33:42[/time] No i hamulce dalej nie działają tak jak trzeba. Lok nie luzuje. Jakaś masakra. Mam teraz 20k logów do porównania i będę szukał, gdzie to się sypie. Przez święta raczej postępów nie będzie bo wyjeżdżam.
  Dodano: 29 Grudnia 2016, 07:52:25 Jak narazie udało się rzucić okiem na logi i wychodzi, że ciśnienie w przewodzie głównym (???) - zmienna PipePress nie podnosi się tak samo wysoko jak w wersji paszczalowej. Przepływ z przewodu zasilającego jest teoretycznie kontrolowany przez Handle->GetPF() i wygląda, że wracam do tematu implementacji tablicy wartości przepływu dla poszczególnych pozycji kranu. Może dzisiaj coś więcej zrobię wieczorem.

[firleju]

Nosz wkurzyłem się. Błąd był spowodowany nieprawidłowym użyciem przez kompilator funkcji abs(). Zamiast używać tej z cmath używał z stdlib (pomimo includowania nagłówka). A w stdlib jest wersja tylko dla int, a funkcja używa wersji dla double. Więc obliczał sobie double a potem niejawnie, bez ostrzeżenia , rzutował na int (co w tym przypadku oznaczało, że zamiast 0.xxxx było 0). I w konsekwencji zbiornik sterujący w kranie się nie wypełniał.

[HTD]

Język Szatana! Ten problem to nawet jest popularny, programiści C++ lubią opisywać podobne przypadki na blogach. Ten język to jedno wielkie pole minowe.
To co, koniec blisko?

[tmj]

Nosz wkurzyłem się. Błąd był spowodowany nieprawidłowym użyciem przez kompilator funkcji abs(). Zamiast używać tej z cmath używał z stdlib (pomimo includowania nagłówka). A w stdlib jest wersja tylko dla int, a funkcja używa wersji dla double.

Z tego co widze w zrodlach to kompilator dzialal tutaj poprawnie -- abs() z <cmath> jest ulokowany w namespace std, czyli zeby go uzyc trzeba wywolac std::abs() a w kodzie jest tylko abs(). No i jakies ostrzezenie przy kompilacji powinno tam byc, chocby dlatego ze parameter typu double jest konwertowany do int na wejsciu. Nawiasem mowiac ten sam blad ma miejsce przy innych funkcjach -- jest tam np. sqrt() zamiast std::sqrt()

Jak juz przy tym jestesmy, to w std:: sa tez min() and max(), mozna nimi zastapic te z mctools. Sa o tyle wygodniejsze, ze dzialaja na wszystkich typach zmiennych wiec nie trzeba pamietac ktory wariant jest do int, a ktory do double, itp.

[firleju]

Najlepsze, że VS, którego używam jako IDE poprawnie łapie funkcję z double. Sprawę rozwiąże pewnie

Kod: [Zaznacz]

using namespace std;Teraz nie chcę się bawić w dostosowanie do użycia STL wszędzie gdzie się da, bo to nie jest ten etap. Teraz to ma działać. Czy koniec to nie wiem. Poprzednio kojarzę, że mogłem odhamować, ale już nie ruszyć ;) Więc wszystko po kolei.
Apropos szatana, to informatyka idealnie podpada pod definicję antychrysta ;)

[Cesky Kretek]

Jestem pełen podziwu dla Twojej wytrwałości. Coś czuję, że po zakończonej transformacji trzeba będzie zrobić duuużą zrzutę na forum na jakiś prezent w ramach wdzięczności. :)

[firleju]

W stosunku do średniej wytrwałości twórców tras to narazie to słomiany ogień.

[surgeon]

Najlepsze, że VS, którego używam jako IDE poprawnie łapie funkcję z double. Sprawę rozwiąże pewnie

Kod: [Zaznacz]

using namespace std;

Używanie using namespace std; to proszenie się o kłopoty. Dodawaj wszędzie std:: i problem z głowy, a  czytelność kodu większa. Jeśli chodzi o IDE to lepiej jednak byłoby używać coś, co jest wieloplatformowe, czyli np. CodeBlocks, albo notatnik, a nie microsoftowy VS, który pewnie ma tam jakieś swoje dodatki działające wyłącznie pod windowsem.

[HTD]

Ale MaSzyna nie jest wieloplatformowa. Mogłaby być, jak ktoś cały kod przepisze np do C#.
Na razie zależy od DirectX i Win32API.
W przyszłości widziałbym cały kod w C# + Unity, wtedy byłoby wieloplatformowe.
Nie ma lepszego IDE od VS, ale jest lżejsze wieloplatformowe Visual Studio Code. Tyle, że jest sens go używać jak kod jest wieloplatformowy. Do kodu natywnego najlepiej używać narzędzia specjalizowanego. VS CE jest darmowe, więc każdy może sobie pobrać i zainstalować, najnowsza wersja ma też opcję minimalną (bez wszystkich krowiastych ficzerów).

[Krzysiek626]

@HTD, @Surgeon to wie, rozpoczął 14 rok pobytu na tym forum. Jest od początku.
Ja nie widzę potrzeby, aby Maszyna była wieloplatformowa. A skoro już zacząłem, to coraz mniej widzę potrzebę multi playera co do tej pory wydawało się niezbędne.

[tmj]

Jeśli chodzi o IDE to lepiej jednak byłoby używać coś, co jest wieloplatformowe, czyli np. CodeBlocks, albo notatnik, a nie microsoftowy VS, który pewnie ma tam jakieś swoje dodatki działające wyłącznie pod windowsem.

IDE to tylko IDE; nie ma raczej wplywu na kod, a pisanie czegokolwiek przy uzyciu notatnika to bezsensowny masochizm, ktory tylko stwarza pole dla trywialnych bledow. Of tego jest glupi komputer, zeby pamietal definicje klas i funkcji, i pilnowal czy skladnia sie zgadza.

[AtapiCl]

A skoro już zacząłem, to coraz mniej widzę potrzebę multi playera co do tej pory wydawało się niezbędne.

Wpierw trzeba opanować samą w sobie symulację, a fajerwerki zostawić na potem.

[firleju]

Przecież nikomu nie bronię pisać w notatniku. VS potrafi pisać kod multiplatformowy jeśli pamiętasz o tym, że chcesz to robić i nie używasz MFC, czy rzeczy z Visual C++ albo WinAPI albo DirectX.
Od razu też powiem, że problem nie leżał w użyciu std::abs() czy using namespace. Obie metody nie działają, gdyż wygląda, że Borland nie ma w STL zaimplemetowanego abs dla czego innego niż int. Na szybko dodałem dwie implementacje w mctools i działa ok.
Inna rzecz, że hamulce nie działają po podłączeniu wagonów. Teraz szukam, dlaczego ucieka powietrze z przewodu głównego.

[Cesky Kretek]

W stosunku do średniej wytrwałości twórców tras to narazie to słomiany ogień.

Ale za to da nam to ogromny postęp i otworzy nowe możliwości.
Prowadzisz jakieś statystyki ile Ci jeszcze pozostało kodu do przepisania? Jakieś status-bary itp.? Tak z czystej ciekawości. :)

[firleju]

Z kodu do przepisania stricte pozostało już tylko wczytywanie za pomocą pascalowego parsera, co da się zmienić już teraz niezależnie od moich prac. Z tego co ja robię to teraz są poprawki błędów konwersji. Całość jest już na c++.
Jak na teraz to odkryłem, że mi ktoś włączył hamulec awaryjny w wagonach.

[El Mecánico]

Jak na teraz to odkryłem, że mi ktoś włączył hamulec awaryjny w wagonach.

Proponuję sprawdzić, czy aby ta zmienna/flaga jest inicjalizowana do właściwej wartości. Jeśli nie, trzeba prześledzić ścieżkę od parsera. Jeśli tak, to trzeba sprawdzić, czy od inicjalizacji do startu symulacji coś jej nie nadpisuje.

[firleju]

Już myślałem, że sprawdziłem wszystkie zmienne w konstruktorze, ale nie. Ciągle są braki. Cóż, wagon nie dość, że miał zaciągnięty hamulec to i uszkodzony silnik ;) Teraz jeszcze raz po kolei sprawdzam każdą zmienną jaka jest zadeklarowana w moverze czy jest inicjowana w konstruktorze. Jestem tak pi razy drzwi w 1/4. Może do końca tygodnia wszystko sprawdzę i wtedy kolejny test.
  Dodano: [time]03 Stycznia 2017, 21:00:10[/time] Zainicjowałem wszystko co brakowało. Dalej coś nie halo, ale już mniej. Z przewodu ma ubywać, ale teraz jest za szybko. Coś tam dalej źle się liczy. Mam lekko dość tej zabawy.
  Dodano: 03 Stycznia 2017, 22:55:29 Wstępnie obstawiam błędy w Oerlikonie wagonowym. Z pierwszych odkryć to nie działa mi typeid(T) i chciałbym się dowiedzieć dlaczego.

[tmj]

Z pierwszych odkryć to nie działa mi typeid(T) i chciałbym się dowiedzieć dlaczego.

Sprawdz, czy wlaczona jest generacja danych RTTI w ustawieniach kompilatora. Ale takie rzeczy to powinno sie raczej robic przez wirtualna funkcje w klasie bazowej, ktora konkretne warianty juz sobie implementuja tak, jak im to pasuje. Reczne sprawdzanie typow i wywolywanie odzielnych funkcji na tej podstawie to troche dokladanie sobie roboty i proszenie sie o klopot ;/

edit:
patrzac w kod, to najprawdopodobniej nie dziala bo porownujesz wskaznik do klasy z klasa, wiec tam rownosci nigdy nie bedzie. Czyli nie powinno byc

Kod: [Zaznacz]

typeid( foopointer ) == typeid( bar )
ale

Kod: [Zaznacz]

typeid( *foopointer ) == typeid( bar )


[firleju]

Ahh, ile jeszcze rzeczy do odkrycia w c++... ;) Czemu w innych językach to jest proste a tu nie może.
  Dodano: [time]04 Stycznia 2017, 07:54:53[/time] Chyba się przesiądę na VS2017RC ze względu na tą funkcję:

Find All References (Shift+F12) now helps you get around easily, even in complex codebases. It provides advanced grouping, filtering, sorting, searching within results, and (for some languages) colorization, so you can get a clear understanding of your references. For C++, the new UI includes information about whether we are reading from or writing to a variable.

  Dodano: [time]05 Stycznia 2017, 09:47:22[/time] Znalazłem błąd. Spowodowany moim gapostwem, gdyż to jest niedogodność konwersji, że czasem wrzuca słowa sterujące za komentarze i zamiast else if masz komentarz. Zawsze przeglądam pliki po konwersji, żeby to znaleźć, a w tym przypadku mi umknęło. Teraz powietrze nie ucieka już. Późno było to już nie robiłem znaczących testów. Dzisiaj odhamowanie składu i ruszenie. Jeśli się uda ruszyć ;)
  Dodano: [time]05 Stycznia 2017, 23:35:14[/time] No znalazłem więcej błędów. Jeden z nich to była błędna konwersja typu wkładki hamulca, i wszystko miało te same wkładki żeliwne ;) Było też parę innych błędów, ale ciągle wagon jest nieodhamowywalny. Bo ostatniej poprawce zrobiłem nową dziurę i teraz ciśnienie w przewodzie mam -1 ;)
  Dodano: [time]06 Stycznia 2017, 21:02:47[/time] Przewód załatany. Brak dopisania funkcji jako wirtualnej w klasie polimorficznej. Nadal źle liczy ciśnienie w hamulcu.
  Dodano: 06 Stycznia 2017, 23:58:48 No powiem, że ostatni błąd był najgłupszym jaki widziałem do tej pory. Otóż

Kod: [Zaznacz]

if ((BrakeStatus & b_on == b_on)) nie jest tożsame z

Kod: [Zaznacz]

if ((BrakeStatus & b_on) == b_on) Nie wiem czemu tak to działa ale po zmianie na poprawną wersję hamulce działają jak potrzeba.
Elektrykiem da się ruszyć, ale reaguje tylko na pierwszą pozycję i nie zwiększa prądu wraz z wejściem na kolejne.

[tmj]

Nie wiem czemu tak to działa ale po zmianie na poprawną wersję hamulce działają jak potrzeba.

Bo taka jest typowa kolejnosc operacji w c++ ( http://en.cppreference.com/w/cpp/language/operator_precedence )

kombinacje bitowe i logiczne (#10-14) sa z reguly wykonywane po porownaniach (#8-9) czyli ta pierwsza wersja to w praktyce

Kod: [Zaznacz]

if( BrakeStatus & 1 )
bo b_on == b_on bedzie zawsze prawdziwe.

porownanie to operator jak kazdy inny, a c++ te rzeczy sa w zasadzie defniowane luzno, jesli w ogole, dlatego prawie zawsze warto dla pewnosci wymuszac kolejnosc nawiasami itp, inaczej ugryzie cie to nie wiadomo kiedy.

[firleju]

W każdym razie w jednych if-aach było poprawnie a w innych nie.
Z dzisiejszych testów wynika, że czuwak nie działa, znaczy włącza się, ale nie hamuje ;)
Teraz sprawdzam czemu źle liczy prąd w obwodzie.
  Dodano: [time]07 Stycznia 2017, 16:50:31[/time] Uwielbiam C++. Do tej pory nie mogę zrozumieć co przyświecało twórcom kompilatorów, że jeśli wynik jest typu double, a pierwsza liczba wymnażana po prawej jest typu int to policzy całość mnożenia w liczbach całkowitych i wynik zrzutuje na double.
  Dodano: 07 Stycznia 2017, 16:58:50 Ahh, zapomniałem dodać, że kiedy wrzucam pozycje na czysto to nie przeskakuje zmienna, ale jeśli na funkcji obsługującej klawisze wrzucę breakpointa to ją przerzuca.

[tmj]

Uwielbiam C++. Do tej pory nie mogę zrozumieć co przyświecało twórcom kompilatorów, że jeśli wynik jest typu double, a pierwsza liczba wymnażana po prawej jest typu int to policzy całość mnożenia w liczbach całkowitych i wynik zrzutuje na double.

A to akurat dziwne. Standardowo jest w druga strone (https://msdn.microsoft.com/en-us/library/aetzh118.aspx) tzn jesli jest np float = int * float to kompilator promuje int do float i wszystko dziala: 1 * 1.5 = 1.5  Chociaz i tak dla pewnosci warto stosowac static_cast itp, ale to chyba cos z Borlandem, a nie c++ jako takim.

[ryba825]

Uwielbiam C++. Do tej pory nie mogę zrozumieć co przyświecało twórcom kompilatorów, że jeśli wynik jest typu double, a pierwsza liczba wymnażana po prawej jest typu int to policzy całość mnożenia w liczbach całkowitych i wynik zrzutuje na double.

A to akurat byłoby bardzo dziwnie, bo to nie ma żadnego sensu. Może bug kompilatora?

[firleju]

To musi być Borland, bo w jego przypadku double x = 3/2 => 1, a 3.0/2 => 1.5. Więc wczoraj wieczorem przeglądałem cały mover, żeby wychwycić te wszystkie miejsca gdzie liczy na całkowitych.
  Dodano: 08 Stycznia 2017, 18:25:41 Da się normalnie jeździć, tylko nie działa czuwak. Szukam przyczyny czuwaka. Chciałbym jeszcze też zrobić parę testów zanim puszczę do was, żeby nie było strasznego crapa.

[tmj]

To musi być Borland, bo w jego przypadku double x = 3/2 => 1, a 3.0/2 => 1.5. Więc wczoraj wieczorem przeglądałem cały mover, żeby wychwycić te wszystkie miejsca gdzie liczy na całkowitych.

A nie, 3/2 = 1 to akurat "normalne" -- konwersja z liczb calkowitych na zmiennoprzecinkowe ma miejsce, jesli przynajmniej jeden ze skladnikow operacji matematycznej jest typu float albo double. Jesli oba sa typu int, to kompilator tak je zostawi. Przypisanie wyniku do zmiennej nastepuje juz po fakcie, jako odrebna operacja, wiec nie wplywa na to jak przeprowadzana jest sama matematyka; o tym decyduja tylko typy skladnikow.