A po co jest zmieniana wielokrotnie?
Kompilator zauwazył że na koniec zawsze jest 7 i zrobił zamiast tego return 7. Miał prawo.
Al dalej zagadką jest, dlaczego to *ważne* aby ją zmieniać wielokrotnie.
A po co jest zmieniana wielokrotnie?
Kompilator zauwazył że na koniec zawsze jest 7 i zrobił zamiast tego return 7. Miał prawo.
Al dalej zagadką jest, dlaczego to *ważne* aby ją zmieniać wielokrotnie.
Przyjemności później. Teraz pytanie co z tym Harvardem, co miał nie działać z czymśtam.
Z powodu takich opini powstały systemy kontroli wersji.
Janusz <janusz snipped-for-privacy@o2.pl napisał(a):
Oraz co robili i kiedy. Przydatne też przy pojedynczym programiście.
90% funkcji systemu kontoroli wersjo mozna uzystkac kopiujac katologi: robisz sobie glowny katalog na wersje w nim podkatalog dla kazdej wersji. Co w takim razie daje system kontroli wersji w sytuacji pojednyczego programisty: - oszczedniejszy zapis danych - mniejsze ryzyko przpadkowych bledow (np. bledna nazwa katalogu moze spowodowac nadpisanie starszej wersji zmiast utworzenia nowej) - wygoda: system kontroli wersji pamieta parametry ktore podales i moze je uzyc. Zamiast kilku polecen dla jednej logicznej operacji wystarcza jedno polecenie.
Co do oszczedniejszego zapisu: w jedny z moich projektow repozytorium git-a zajmuje 65 M. Same zrodla to 25 M. Jest ok. 3000 wersji, co przy naiwnej metodzie "katalog na wersje" daloby rzedu 75 G (projekt zaczal od juz istniejacych zrodel, sporo kodu bylo usowane tak ze rozmiar wczesnych wersji jest podobny od obecnego). Dla oszczednosci miejsca zrodla moznaby kompresowac, wtedy dostane ok 4M, do 3000 wersji to ciagle rzedu 12 G na calosc. Przy skompresowaych zrodlach wiekszosc operacji wymagaloby najpierw dekompresji, wiec jest dodatkowa niewygoda.
Zamiast katalogow mozna by pamietach diffy (roznice) miedzy wersjami. Wtedy powierzchia dysku do pamietania wersji bylaby mniejsza (ale prawie na pewno wieksza niz 40 M narzutu git-a), ale odtworzenie wersji byloby klopotliwe.
Ja "powazniesze" projekty trzymam w systemie kontrolii wersji. Ale nie jestem fanatykim, kilkadzisiat (czy moze kilkaset) drobnych programikow jest poza system kontroli wersji. Jak nie robisz niczego powaznego to system kontroli wersji niewiele pomaga. Tzn. system kontroli wersji zacheca do porzadku i zmniesza opory psychiczne w stylu "czy warto zapamietac ta wersje" (w system kontroli wersji "koszt" kolejnej wesji jest maly).
Jak ktos jest z natury nieporzadny to system kontroli wersji mu nie pomoze, taki czlowiek bedzie "walczyl" z systemem albo nie bedzie go w ogole uzywal. Jak ktos jest bardzo porzadny to moze dac sobie rade bez systemu kontroli wersji (zakladajac ze miejsce na dysku nie bedzie problemem), ale system kontroli wersji to wygodniejsza praca. Przecietnym ludziom system kontroli mocno pomaga...
Gerbery z Autotraxa czy dowolnego innego programu są standardem w płytkarniach i łykają je bez problemu. Osobiście używam TraxMakera 3.03 z 1999 i po poprawce ręcznej buga z źle zapisywanymi średnicami otworów zamawiam pcb w JLCPCB itp chińczykach. Pliki pcb łykają firmy mające współczesnego Protela (Altium jeśli dobrze pamiętam) bo on sobie wyśmienicie radzi z tymi dosowymi plikami (zapomnieli popsuć bo pewnie nikt ich nie używa...)
Bo to była maszyna stanów, czyli jedna zmienna określa stan i jest wielokrotnie w petli zmieniana.
Kodem dynamicznym jak np '86 która możne sobie wygenerować kod w ram-ie i zaraz go wykonać, na avr-e tego nie zrobisz, możesz tylko wywoływać dynamicznie fragmenty kodu z rom-u i tyle.
W dniu 2022-07-19 o 23:03, Grzegorz Niemirowski pisze:
No tak to nawet widać, bardziej chodziło mi o część prawą że "Nic mi ten obrazek nie mówi" bo tam widzę tylko śmietnik.
A jakie są przykłady użyteczności trzymania 3000 wersji?
Jeśli jest tylko zmieniana i nigdy nie czytana, to kompilator ma prawo w pełni ją zoptymalizować do return 7.
Masz buga gdzie indziej, "rozwiązałeś" problem używając głupiego volatile.
W przypadku polimorfizmu statycznego i dynamicznego, nie ma "kodu dynamicznego", są indirect call.
Nie chcesz mi chyba powiedzieć, że cała drama o to, że pomyliłeś dwa rózne pojęcia dynamiczności?
Szkoda słów.
Nie to oznacza tylko tyle że w przypadku takich procków jak avr cały ten polimorfizm jest gówno wart.
W dniu 2022-07-20 o 04:27, snipped-for-privacy@math.uni.wroc.pl pisze:
Nigdy nie myślałem o przechowywaniu historii poszczególnych projektów. Lata temu zrobiłem sobie system backupowania polegający na tym, że zapisuje się zip wszystkiego, a potem codziennie zapisywane są tylko pliki zmodyfikowane od ostatniego zapisania wszystkiego. Gdy te codzienne pliki robią się coraz większe to któregoś dnia znów robię zapis wszystkiego i potem codzienne znów są małe.
Odtworzenie stanu z dnia nie jest wcale kłopotliwe - rozpakowuję ostatni cały przed tym dniem i na to rozpakowuję ten z danego dnia. Stan będzie różnił się od faktycznego stanu z tego dnia o pliki, które w międzyczasie były usunięte. Ale to raczej nie przeszkadza.
Mój plik wszystkiego teraz to 140M. Wszystko to tak ostatnie 20 lat. Starsze kiedyś trafiły do 'archiwum' i wypadły z tego systemu. Jak (po 3..5 miesiącach) te codzienne urastają do kilkunastu M to znów robię zapis wszystkiego.
Zaletą dla mnie jest, że za jednym zamachem mam załatwione wszystkie typy plików, które w czasie pracy modyfikuję. Nie tylko kody programów, ale też wszystko z KiCada, PSpie'a i mnóstwo *.ods bo najczęściej w tej formie robię sobie różne notatki czy obliczenia. P.G.
Czyli nie masz bladego pojęcia jak to działa, jednak.
Przedstawiłem Ci działajacy kod uzywajacy wywołań wirtualnych, na AVR, używający polimorfizmu dynamicznego z metodami wirtualnymi, bez żadnych sztuczek, goły C++.
Rozimiem, że Twoja ignorancja w temacie C++ jest już na etapie negowania faktów?
Bo u mnie miga diodą.
Dokładnie. Szkoa słów na zrzucanie na kompilator problemów, których nie potrafisz zrozumieć i "rozwiązujesz" używając iditycznego narzędzia które powstało po coś zupełnie innego.
Zacząłem się rozpisywać na temat zalet pracy pod VCS ale w sumie jeżeli trzymanie wszystko w plikach spełnia Twoje wymagania to po co psuć.
Ja wcześnie przerzuciłem się pierw na self-hosted SVN a po kilku latach na Git. Głownie bo nie chciało mi się utrzymywać tego serwera z SVN a bitbucket oferował mi cały Git za darmoszkę - włącznie z prywatnymi repo. Kilka lat temu Github tez zaczął oferować prywatne repo za darmo (kiedyś darmowe były tylko publiczne)
To że mogę powiedzieć po co została dorzucona dana linijka kodu jest dla mnie wielką zaletą bo moja pamięć jest dość słaba i cięzko jest zapamiętać "co autor miał na myśli" 5-10 lat temu.
c.
W dniu 2022-07-20 o 12:39, Cezar pisze:
A ja się cieszę, że się przy tej okazji dowiedziałem co to są systemy kontroli wersji i chyba już mniej więcej rozumiem z czym to się je.
Ten problem też nie jest mi obcy. Dlatego starałem się zrozumieć o czym się mówi. Ale ja bardzo mało piszę.
Co to znaczy utrzymywać serwera SVN. Czy to nie jest tak, że on dostaje jakąś kartotekę i trzeba ją tylko backupować na wypadek awarii HDD. Czy SVN jest gratis? Z tego co piszesz zrozumiałem, że co najmniej Github daje prywatne repo za darmo.
Czy którekolwiek z tych narzędzi da się użyć u siebie na komputerze odizolowanym od internetu? P.G.
To *jeszcze* nie jest pyskówka. Ciągle rozmowa jest o weryfikowalnych faktach.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.