Dziwny problem z kodem w C (gcc mips/pic32)

Rozmiar tablicy.

Co kogo obchodzi jej rozmiar w bajtach, poza allokatorami?

C++ nie wspiera UTF-8. Nie wspiera też Mazovii ani ATASCI.

U mnie true i false są zdefiniowane przez standard.

Patrz, jeszcze jeden powód żeby porzucić guano C.

Nie przejdzie przez review.

To *ty* sie zwalniasz.

Dużo nie zrobią hackując zamiast programować.

Teraz znowu eskalujesz do zupełnie innego języka. To nieuczciwe.

To że Fordy się psują nie oznacza, że nie powinieneś kupować Mazdy.

Pisanie obiektowe, szczególnie modelów danych, wymaga ogólnej orientacji w temacie modelowania danych. Nie bez powodu płaci się tym ludziom więcej niż wklepywaczom faktur.

Zazwyczaj masz określoną złożonośc operacji. Reszta, to detale implementacyjne.

Wrappery na BLAS/LAPACK są bardzo cienkie. Nie wiem w jaki magiczny sposób miały by liczyć coś wolniej, keidy 99.99% kodu to ten sam kod co w Fortranie.

Ludzie piszący poważny soft myślą o tym. Przesadzasz w drugą stronę starając się udowodnić koncept, że kod obiektowy jest wolniejszy, bo programista dupa.

Myślę, że nie rozumiesz jakie problemy rozwiązuje się z użyciem C++. C też magicznie nie wyczaruje więcej RAMu. Probem z algorytmiką i miejscem jest dokładnie taki sam. Natomiast C++ oferuje gotowe, przetestowane algorytmy operujące na tych danych. Co w przypadku C zazwyczaj oznacza qsotr i tyle, reszta to kwadratowe koła wymyślane przez brodatych

A może chcę zapisać na dysk?

Ale programy wymagają UTF-8. To sobie klase zdefiniuje ... taki u8string :-)

W C/C++

A to moze być np program do komunikacji z czytnikiem kart bankowych.

Przeciez w C tez są zdefiniowane przez standard. Tylko trochę słabo. Albo lepiej niz w C++, bo brak wartosci nieokreślonych :-)

Oby. Bo jak bedzie dobrze zaciemniony ... to przejdzie ?

Ja sie rozumiem z zespołem :-)

Zaraz tam hackować ...

Jest i w C++. Tylko nie moge znależć dokumentacji MS.

Taki tam mały przykład

oj, ja bym tam sprawdził kto komu rozwiązania narzuca :-) Bo może Mazda to juz nie Mazda. Choc akurat związki z Fordem ma juz dosc stare.

Nie o to chodzi. Sorry za zmiane z c++ na .net/c#, ale masz klase DataGridView, która jest taką tabelką na ekranie,

Ale mozesz też podłączyc inne źródło danych

I sie teraz nie interesuj jak to jest zrobione, tylko powiedz czy np mogę kolor komórki zmienić? Albo co się stanie, jak wpiszę nową wartość w komórkę?

Albo np chcę jakąs funkcje wywołać po kolei dla dla wszystkich wierszy, czy dla zakresu wierszy ... szybka sprawa, bo kolekcja Rows juz sie składa z pojedynczych wierszy, czy taki pojedynczy wiersz trzeba będzie dopiero zbudować?

Nie bez powodu doświadczeni programiści zarabiają dużo, a juniorzy mało :-)

Być moze te wrappery obchodzą problemy, ale ... Fortran potrafi operowac na liczbach zespolonych, bo to jego natywny typ. W c++ to typ skonstruowany z innych. Jako, że było za wolno, to nawrzucano inline. Ale nadal, jak gdzies jest zwracana wartosc zespolona, to fortran używał dwóch rejestrów, a c++ ... nie musi budować obiektu?

Nie tylko, wszystko robią, żebym sie jak d* zachowywał :-)

No fakt, sort w c++ szybki ... zrobili wieloprocesorowo/wielordzeniowo?

owszem ... ale czy nie wynika to z tego, ze różne wymagania, czy różne optymalizacje mogą być?

a ta z c++ dobra na wszystko? I wydajna?

J.

To musi napisać serializator. Prawdopodobnie będzie miał w środku std::size() aby zserializować każde pole osobno. Nie chcesz przeciez zapisywać śmieci z paddingu pamięci, prawda? Albo, o zgrozo, gołych pointerów, co w naszym wypadku zrzutu tablicy stringów miało by miejsce.

I dlatego możesz wybrać Qt, które używa natywnie UTF-16 i potrafi, jesli potrzebujesz, policzyć ile jest tam *znaków* jak również przemieszczać się między UTF-8. Tylko że od razu mówię, że policzenie ilosci znaków w UTF to zagadnienie na habilitację. Nie bez powodu jest skomplikowane a zdaje się że w kilku wypadkach (bodaj Koreański) mocno mętne. QTextBoundaryFinder.

Innymi słowy, jeśli masz zagadnienia związane z tekstem UTF, to masz zagadnienia związane z jego wyświetlaniem, a to jest cecha biblitek graificznych, nie C++. C++ nie posiada w standardzie nic [G]UIowego.

Już to zrobiono i to znacznie lepiej niz tylko u8. QString.

Wtedy masz połaczenie z hardware i wtedy piszesz translator z hardwarowego true na softwareowy true.

Reszta algorytmini nie powinna nic wiedzieć o jakims hardware, a prawidłowo napisana powinna dać się uruchmić i przetestować bez hardware.

C nie wspiera typu bool. Różne OSy różnie definiują TRUE/FALSE. Napisanie w tym bałaganie generycznego/przenośnego algorytmu jest utrudnione.

Prawie każda przenośna bibliteka, z korzeniami w C, redefiniuje wszstko. To świadczy o tym, jak kiepski to język, skoro nawet podstawowe typy nie mają sensownie okreśonych sizeof i trzeba to łatać ręcznie.

A są jakieś nieokreslone wartości bool?

Jak chcesz świadomie, to w boost jest tribool. On ma trzecią wartość, niezdefiniowaną.

Jest też boost::optional<bool> który może służyć za to samo.

Zakładasz corner case.

Tak, czasmi trafia się cieżki kod na review. Ale nie na tyle cieżki, aby ktoś przerzucił przez niego sabotaż. Kod obiektowy jest relatywnie czytelny. Schowanie tam jakiejś niegrzecznej logiki jest trudne jeśli review przegląda doświadczony programista.

Jeszcze raz: jeśli masz w zespole sabotażystę, to nie tylko wylatuje on z automatu z teamu, jego wrzuty też się przegląda i wycofuje/naprawia.

Nie zawsze tak jest. Część ludzi z którymi pracowałem zwalniała się z poprzednich firm z powodu toksycznej atomsfery, intryg, czy zwykłego bullying. Rózne były opowieści, ale zazwyczaj po czyms, co amerykanie nazywają "red flags" ludzie się zwalniają. Są firmy i korpo, gdzie red flags jest widoczne na wejściu a są też takie, że pojawiają się po tygodniach pracy.

Hackowanie to pisanie kodu w sposób, który jest czytelny tylko dla piszącego, albo powodujący rózne problemy w teamie, w przyszłych refactoringach itd itp.

Na przykład wykorzystywanie, nielegalnie, pamięci poza zakresem allokacji, bo "tam przecież jest padding", co powoduje milion błedów valgrinda, choć aplikacja działa. To jest hacking. Można zrobić to normalnie i poprawnie, ale można też pokazać że jest się samcem omega, wprowadzajac fikuśne rozwiązania mające na celu zdenerowwanie wszystkich na około.

Ale co jest?

To jest Managed C. Nie ma nic wspólnego z C++.

Zazwyczaj odpowiada za to, w typowym GUI, Delegat. Poszukaj możliwosci nadania delegata, którego zadanime jest rysowanie zawartości komórki.

Zobacz na przykąłd w Qt:

To masz zazwyczaj jakiś "Editor" podpięty pod View (zobacz delegata z Qt). W różnych biblitekach GUI to może się róznie nazywać (np. Setter) ale ogólnie to jest cecha niezwiązana z modelem, choć model będzie miał możliwośc akceptacji wyniku tego wpisania.

To jest wielopoziomowo rozbite w taki sposób, aby zadowolić jakiś wariant wzorca MVC. Jeśli zrobiono to poprawnie, to każdy z elementów tego mechanizmu ma ściśle określone zadania.

Dlaczego chcesz wywołać jakąś metodę chodząc po modelu tabelki, a nie po danych wprost?

Jeśli chcesz chodzić po np. selekcji, to na 100% z selekcji możesz wydłubać element modelu. Ponieważ to Ty kontrolujesz model, to masz dostęp do tego, co tam trzymasz.

Detale są rózne w róznych implementacjach, ale prawdę mówiąc, czy to Java Swing, C# Forms czy Qt, podobieństwa są znaczne w ogólnej organizacji koncepcji MVC.

I jak go reprezentuje w pamieci? W C++ reprezentacja to dwa floaty/double, czyli sizeof(double)*2. Fortran dał radę magicznie zrobic to lepiej?

Nie. Natomiast jest to typ szablonowy. Możesz chcieś zamiast float mieć double. Szablon jest bezkosztowy - wynikowy kod asm jest perfekcyjnie dobrany do danego typu i nie generuje w runtime śladu narzutu.

inline jest w gestii kompilatora. jak uz na, że to coś da, to wstawia.

Nie.

Sposoby zwracania złożonych typów w C++ to osobny temat i jest to dość skomplikowane jesli chcesz odpowiedzi na poziomie asm. To, co się stanie w kodzie wynikowym, zależy od optymalizacji. Ogólnie dla x86, jak to sprawdzałem wiele lat temu, skomplikowane funkcje zwracające dane złożone były bardzo często optymalizowane tak, że nie było wywołań funkcji i używane było wiele rejestrów (taki żart z x86). Wszystko zależy od typu CPU i zakresu optymalizacji, w dodatku często podlega wagowemu ocenianiu przez kompilator, biorący wiele pod uwagę (w tym pipeline i out of order execution). Nie bez powodu poważniejsze kompilatory akcpetują nawet konkretny typ achitektury CPu (np SandyBridge) aby te wybory były trafniejsze.

I mała uwaga: współcześnie cache jest prawie tak samo szybki jak rejestry. Na tyle, że mało kogo obchodzi czy dana jest w rejestrze czy cache, przy pipeline w procesorze robiącym kilka instrukcji w cyklu te detale nie mają większego znaczenia.

Może po prostu ktoś wie jak poprawnie używać słowa const, std::move itp, aby wyjaśnić kompilatorowi co chce, a nie jak w C jak to coś uzyskać. C++, dzięki określaniu intencji, ma wiecej swobody w wyborze narzędzi do jej uzyskania.

Może nalezy zacząc od tego, czy te funkcje są w ogóle poprawne. W C bardzo cieżko testować unit testami, wiec nie dowiesz się tego łatwo.

std::unordered_set jest tak wydajny, jak dobrze rozumiesz jak działają wysokopoziomowe elementy języka i jak dobry jesteś w pisaniu poprawnych funkcji haszujacych. Więc, jeśli napiszesz funckję haszującą { return 1; } to wydajny nie będzie, jeśli nie dostarczysz operatora && to wydajny nie będzie, jeśli wstawisz za dużo std::shared_ptr trzymajacych inty to wydajny nei będzie itd.

Dodatkowo standard nic nie mówi o implementacji. Implementacja jest rózna w różncyh wersjach kompilatora, OSa itd itp. Kiedyś był na przykład zewnętrzny zestaw, o nazwie STLPort. W niektórych przypadkach lepszy (szybszy, mniejszy narzut) od dostaczonego przez MS. Obecnie jest też alternatywny zestaw w boost.

Jeśli szukasz czegoś konkretnego, prawie na pewno ktoś to juz napisał:

Nie wiem tego, ale idę o zakład, że we współczesne C (od C99) i C++ (chyba od C++98), czyli tak mniej więcej od ćwierćwieku operują na liczbach zespolonych nie gorzej niż Fortran. W C wprowadzono wtedy słówko kluczowe _Complex, natomiast w C++ jest to zrobione na templejtach. A strukturę w tych językach można przekazać/zwrócić do/z funkcji w rejestrach „od zawsze”, o ile się tam zmieści (AFAIR kompilator robi to po prostu automatycznie, w papierach trzeba sprawdzić), a jak nie, to przez stos. Z drugiej strony zastanawiam się, jak program napisany w Fortranie uruchomiony np. na 32-bitowym Intelu mógłby przez rejestry zwrócić kompleksa gdzie re i im są to 128-bitowe floaty (albo 256-bitowe). Rejestrów zabraknie. :-)

On 22.05.2023 22:29, heby wrote: [...]

No i zdaje się dlatego Qt pod spodem używa ICU:

Śmiem się nie zgodzić. Już jakieś ćwierć wieku temu, w C99, wprowadzono słówko kluczowe _Bool, a do tego plik stdbool.h z przydatnymi duperelami.

heby snipped-for-privacy@poczta.onet.pl> napisał(a):

Wspiera, <stdbool.h> się kłania.

OSy nie są od definiowania elementów języka.

C99 leży w trumnie. Nie budzić.

To jest martwy C99 a nie C.

A jednak robią to z uporem maniaka.

#ifdef TRUE #undef TRUE #endif #define TRUE 1

typedef int BOOL, *PBOOL, *LPBOOL;

heby snipped-for-privacy@poczta.onet.pl> napisał(a):

Kto Ci powiedział, że to C99? Bo akurat w C99 ten typ się pojawił? Przecież nie znikł i w nowszych wersjach też występuje.

Tak. Pojawił się w C99. Programiści C niespecjalnie mają oficjalny dostęp, ale bez problemu mogą sobie taki sami napisać. I piszą. W milionach wersji. TRUE, True, true, T_, OK, STATUS_OK, itd itp. Można by powiedzieć, że C to ostatnia ostoja wolności.

C99 i następne, jako koncept, są martwe.

Przez całe lata clang nie posiadał na przykład varrays z C99. Dodali niedawno. Psa z kulawą nogą to nie obchodziło, czy są, czy nie varrays. Kogo niby obchodzi jakiś C99?

Nastepne wersje C są tylko życzeniem:

heby snipped-for-privacy@poczta.onet.pl> napisał(a):

Bez znaczenia co sobie uznasz za martwe. C jest używany przez miliony ludzi i mają oni do dyspozycji typ bool od lat. Typów char i int też nie ma w C bo jest według kogoś koncepcyjnie martwym językiem?

Bo nauczono sobie radzić bez tego, podobnie jak bez typu bool. Tylko co z tego ma wynikać? Fakt bez znaczenia.

Nie wiem, to Ty z nim wyskoczyłeś. Ja tylko napisałem, że typ bool jest w języku C.

C czy C99? Dla embedowca to krytyczna różnica. Jeden koszerny, drugi to lewackie fanaberie.

Ależ one są. Bo nie umarły w C++. Cały C nie umarł w C++. Natomaist C99 i następcy umarli. Już dawno.

Świat w pewnym momencie poszedł w dwie strony. Jedni podążyli drogą "lubie pisenki, które już raz słyszałem" i od wielu lat dreptają w kółko na dziedzińcu Cxx od czasu do czasu odkrywając, że można czasem zmienić krok na centymetr dłuższy i nazywaja to "rozwojem". Inni poczekali dość długo, ale ostatni ow tempie eksresowym poznają znacznie ciekawszy język programowania jakim stał się C++. Co bezczelna, C++ oakzał się tak samo dobry do liczenia wybuchów jądowych, co do migania diodą.

Oba są turing complete.

Oba można użyć do dowolnego zastosowania.

Ale jak patrzysz na to wydeptane kółeczko na dziedzińcu, to ciężko porzucić te lata kręcenia się w kółko. Ja to doskonale rozumiem. Ludzie nie lubią zmian. Ja też nie lubię. Zmieniłem ostatnio pracę właśnie po to, aby nie znaleźć się za nastepna 20 lat 5m w dole jakiegoś dziedzińca.

Mamy standard, ale nie mamy użytecznej współcześnie implementacji. Oh well.

Co do bool używam od zawsze. W zasadzie od połowy lat 90 na Amidze, gdzie był SaSC i miał on kulawy, ale jednak C++.

Wynika pogłebiające się, wydeptane kółeczko, kiedy reszta odjechała pociągiem goniąc postęp.

Nie. Wyskoczył razem z pojawieniem się bool w C i okazało się że to nie C tylko C99. Argumentacja z gatunku "Forth jest znakomitym językiem, bo w Fortranie..." i liczenie na to że nikt nie zauważy różnicy.

W C99. A to ważne, bo C99 nikogo nie obchodzi, wliczajac w to twórców współczesnych kompilatorów. Być może ma istotne znaczenie archeologiczne i w zasadzie to mogło by pasować do tematu dyskusji.

heby snipped-for-privacy@poczta.onet.pl> napisał(a):

Tak samo bool nie umarł w C++, więc nie wiem skąd to zaprzeczanie jego istnieniu w C.

C99 to też C. Tak samo C++ ma kolejne wersje.

Czyli tylko K&R C to jest C, a kolejne wersje to już nie jest C?

W C99 i kolejnych, współcześnie używanych. Uparcie zawężasz temat do C99. Chodzi o to, że nowszych wersji nie używają ci mityczni embeddowcy więc wersje te się nie liczą?

Ależ mi nie chodzi o obiektowość, czy rodzaj interfejsu UI, czy nawet nie chodzi o to w jakim języku go napisano...

Chodzi o to, że na tamten sprzęt "skrojono" programowo niemal wszystko "na wymiar", a "embedowcy" potrafili wycisnąć z niego niemal siódme poty. Jednym zdaniem: soft skrojony do hadware'u.

Teraz do oprogramowania - NIEZALEŻNIE JAKIEGO - dorzuca się rzeczy zbędne, wrogie użytkownikowi a czasem tak bzdurne, że szkoda słów. I nie myślę tu tylko o OS'ach, ROMACH czy aplikacjach. Dzisiaj kod jest przeważnie śmietniskiem i wylęgarnią wszelkiego crapu.

Pozwolę się nie zgodzić: eskalacja kodu jest pomiędzy tamtymi a obecnymi czasami już nie liniowa a logarytmiczna - i to nie w dobrym kierunku.

No nie - to problem sprzętu nienadążającego za stale rosnącymi zapotrzebowaniami oprogramowania.

Owszem, ale osobiście uważam, że ponad 60% kody obecnego windowsa SPOKOJNIE można by z niego wyrzucić ujmując mu najwyżej 5% "zajebistości". Kolejne 15% skierować na elementy niezwiązane z systemem w postaci dołączanych plików, które użyte przez usera byłyby może raz lub w ogóle. Reszt to aktywnie działający system.

Tak go widzę.

Bo w C go nie ma. Jest w C99 lub C++. Przy czym ten w C99 to takie śmieszne coś.

I dlaczego należy wybrać Cxx zamiast C++xx? Masz jakieś merytoryczne argumenty?

Kolejne wersje nie są tutaj dyskutowane, drogi Sherlocku.

Była mowa o przejściu z C na C++ bo to akurat nie jest ślepa uliczka.

Jeśli będziesz chciał przejść z C99/11 na C++ to proszę bardzo. Musisz się jednak liczyc z faktem, że ponieważ Cxx nikogo nie obchodzi, to i wsparcie niektórych konstrukcji z Cxx w C++ istnieje tylko przypadkiem o ile w ogóle (bo nie musi). clang ma je w nosie i są robione w 4 kolejności. Clang zaś, na chwile obecną, jest nie do zignorowania w embedded.

Można wybierać mądrze, ale można też ideologicznie.

Kolejne to tylko sterta papieru. Ich wsparcie jest zupełnie niepotrzebne z powodu ujemnej ilości kodu planowanego w tych standardach, zerowego zainteresowania przemysłu i niejasnych "ulepszeń", których kiedyś szukałem i nie znalazłem w jakiś oczywisty sposób. Dreptanie w miejscu typu "dodajmy jeszcze jedną literę do fopen, to rozwiązuje połowę problemów ludzkości".

A używasz C17? I jakie problemy z rozmiarem liczonym przez sizeof zostały tam rozwiązane? Albo w ogóle jakieś inne?

O ile dobrze kojarzę, to w najnowszym standardzie planują dodać głównie operacje na bitach.

Zaś w poprzednich (C11) jest wiele rzeczy z C++, tylko zrobionych inaczej.

Po co ten ezoteryczny język komukolwiek potrzebny? Wychodzi na to, że nie tylko ja zadaje sobie to pytanie, sądząc po ilości przemysłowego kodu napisanego w C++xx vs Cxx.

Mimo to Amiga OS jest obiektowy, przynajmniej częściowo. I to, co najzabawniejsze, w ogóle nie zależnie od języka programowania. W asm też się dało pisać z BOOPSI obiektowe aplikacje. W tym momencie embedowcom trzeba chyba podawać tlen.

Amiga OS jest już na granicy OSa uniwersalnego, gdzie abstrakcja na hardware jest prawie kompletna.

Z każdą nastepna wersją stawał się coraz mniej skrojony na miarę a coraz bardziej uniwersalne. Amiga bez problemu obsługiwała tym samym OSem inne karty gfx, dzwiękowe, dodatki typu MMU itd itp. Nie, ten system nie był skrojony na miarę, był na granicy takiego.

Dobrze wiedzieć.

I dobrze też przeciwdziałać. Zamiast produkować tony krapu w C można najzwyczajniej napisać przejrzysty kod w wyższym poziomie abstrakcji. Czy to będzie C++ czy Rust, to drugorzędne.

Krap można pisać wszędzie. Są jezyki w których robi się to trudniej. Obecny zwrot z C(++) do Rust świadczy o tym, że w głowach wielu ludzi zaczeło kiełkować, że jednak uniwersalny asembler to niekoniecznie najlepsze narzędzie do pisania aplikacji z tysiącami kloc.

Prawdopodobnie wynika to z odchodzenia starych ideologów C na emeryturę. Bo z własnej woli Rust'a by nie tknęli kijem.

Wyjaśnij przyczynę.

Mogę migać diodą w C++ w takiej samej ilości instrukcji asm kodu wynikowego co w C. Nic tu nie rośnie.

Co rośnie i dlaczego?

Sprzęt, w szczególności układy specjalizowane grafiki, są obecnie wielokrotnie szybsze niż przeciętnej karty Trident czy amigowego Blittera. Biorąc w poprawkę cały postęp w rozdzielczości i głebokości kolorów.

Hardware jest super szybkie.

A natywne bibliteki, jak Qt, korzystają z tego całymi garściami.

Sugeruje odpalić demka z Qt, płynnośc i responsywnośc wgniata w podłogę.

Oczywiście do pierwszego imbecyla robiącego "for (;;)" w onkliku. Tutaj szukaj przyczyny. Nie ilość danych, nie język, a najzwyczajniej niepojmowanie jak się pisze aplikacje responsywne, powoduje wrażenie spowolnienia.

heby snipped-for-privacy@poczta.onet.pl> napisał(a):

C99 to też C. Możesz go uważasz za śmieszny, ale taki standard języka C został wydany. Podobnie jak zarówno C++98 i C++23 to C++.

Nic nie pisałem o wybieraniu więc nie mam czego argumentować. Ale skoro to poruszasz, to wolę C++ niż C.

Widzę, że tak sobie wymyśliłeś, ale nie wiem dlaczego.

Ale jest to tak samo C jak C90, C11 i inne wersje.

Tak, używam.

To nie ma znaczenia. Ja nie dyskutuję która wersja jest lepsza. Z jakiegoś powodu wybrałeś sobie jakąś wersję C (nadal nie wiadomo nawet którą i dlaczego) a inne arbitralnie odrzucasz bo tak.

Rozmiem. Dyskutujesz po prostu przez zwykłe czepialstwo detali.

Zaciekawiła mnie Twoja wypowiedź więc pytam. Co w tym czepialskiego? Niestety zamiast odpowiedzi dostaję wywody o C++, o rozwiązywanie problemów, opowieści o Linusie, marudzenie na embeddowców, rozważania o clangu i mnóstwie innych rzeczy, które właśnie nie mają znaczenia dla tej jednej prostej kwestii.