Příspěvky

121

Vývoj / Re:Ako ukladáte binárne dáta a texty v C++?

« kdy: 06. 10. 2020, 15:34:41 »

Raději ani nebudu počítat, kolikrát jsem něco takového viděl. Občas té obalované Cčkové knihovně ani ten pointer + délka předat nejde.

Skutečně existují situace, kdy je nulový bajt legitimní součástí řetězce a zároveň funkce nepřijímá pointer + délku, ale jen pointer a čeká, že bude ukončený nulovým bajtem?

Legitimní nevím. Ale ve vrstevnatém legacy kódu existuje spousta situací, kdy funkce bere std::string a není jasné jestli nuly uvnitř snese nebo ne.

Podle mého je využití std::string pro binární data v pořádku. String a char v C++ totiž nejsou textový řetězec a znak (byť se tak často používají), ale právě řetězec bajtů resp. bajt.

Typický příklad : Mám nějakou síťovou nebo serializační vrstvu třetí party. Jsou tam metody co zapisují std::string. V dokumentaci samozřejmě není, jestli to tu nulu snese nebo ne.

Netvrdím že je to dobře. Jen že je s tím třeba počítat, protože se to vyskytuje nepříjemně často. A dualita std::stringu k tomuhle použití navíc dost svádí.

122

Vývoj / Re:Ako ukladáte binárne dáta a texty v C++?

« kdy: 05. 10. 2020, 13:16:33 »

No, kombinovat C a C++ funkce nikdy neni dobre. A pouzivat strlen na string::c_str() je jeden z pripadu Pokud se predava vsude jako kontejner std::string, tak nevim, jak by se k tomu strlenu clovek dostal. Krehky neni kontejner, krehke je michani C a C++

Kombinace C a C++ je standardní stav. OS mají Cčkové api, hromada knihoven má Cčkové api atd. C++ api bývá jen tenký wrapper. A pak stačí aby ten wrapper nečekal ve stringu nuly a jen ho přes c_str překlopil na char* a předal dál.

Raději ani nebudu počítat, kolikrát jsem něco takového viděl. Občas té obalované Cčkové knihovně ani ten pointer + délka předat nejde.

Není vlastně jedno, co přesně je křehké? String s nulama je past a bugreporty půjdou za tebou bez ohledu na to o kolik úrovní níž to bouchne.

EDIT : Tím nechci říct aby to tazatel za žádnou cenu nedělal. Jen by si měl být vědom rizik.

123

Vývoj / Re:Ako ukladáte binárne dáta a texty v C++?

« kdy: 05. 10. 2020, 09:01:42 »

pouzij klasicke C-like ukladanie:

char[] pole = {0x01, 0x02, 0x03}
char* string = "\x0A\x0D\0x61\x00";

Není naprosto žádný rozumný důvod použít něco takového. Mnohem lépe použít std::array<unsigned char> pro fixed-length buffer.

Jop, rozumné implementace std::array v sobě mají navíc asserty na správných místech. Až se zase utneš při indexování (až, ne jestli ) tak za to budeš jen rád.

124

Vývoj / Re:Ako ukladáte binárne dáta a texty v C++?

« kdy: 05. 10. 2020, 08:56:35 »

std::string by měl zvládnout i nějakou tu nulu uvnitř, ale bude to křehké. Čtenáře kódu by mohlo třeba zaskočit pokud .size() vrátí něco jiného než strlen. Na druhou stranu jsou implementace docela vychytané. Třeba clangový string zvládne do svých 16B nacpat 15B SSO string.

Na obecnou sekvenci bytů bych pravděpodobně použil std::vector<uint8_t>, případně std::vector<std::byte>. Byte je tenounký obal nad uint8, pak to není číslo ani znak ale jenom hrst bitů.

Overhead vectoru bych neřešil, pokud jich nebude extrémně moc. Vector jsou obvykle 3 pointery + je tu samozřejmě overhead schovaný za mallocem. Pokud už budeš ten overhead muset řešit, pak se dá na pár místech ušetřit. Ale bude to za cenu kompromisů a šité na nějaké konkrétní použití.

125

Vývoj / Re:Nový projekt vs. cizí kód

« kdy: 16. 09. 2020, 13:29:45 »

No ja navrhuju s abysme zacali u sebe.
Myslim si, ze nevyrabet hnuj by byl slusny zacatek ;-).
Treba prijdem na to, ze vyrabet slusny SW neni o nic casove narocnejsi nez vyrabet hnuj.
Mentalne mozna... ale to dame.

Tak vám děkujeme, pane hrabě.

Je to jen můj dojem, nebo jsou autoři podobných prohlášení podezřele skoupí na ty malé bezvýznamné implementační detaily? 

126

Vývoj / Re:Nový projekt vs. cizí kód

« kdy: 15. 09. 2020, 11:37:29 »

Ale OK shodneme se, ze je to spatne...
Tak a ted se jen dohodnout jak to zmenime k lepsimu.
Co navrhujes?

Jak "dohodnout se"? tomas88 napsal v podstatě to, že tenhle stav je Nashovo ekvilibrium. Výplatní funkce je daná korporátními směrnicemi. Můžeš leda tak jít hrát jinou hru.

127

Vývoj / Re:Nový projekt vs. cizí kód

« kdy: 14. 09. 2020, 16:41:16 »

...
To je prave to co tady resim.
...

Ale ty jsi se ptal na preference vývojářů. Tahleta špinavá taktika je spíš manažerské rozhodnutí.

Pravda ze sem chtel resil predevsim tu motivaci odspodu.
To manazerske rozhodnuti je ale vyvojari vitano a podporovano (vetsinou) a proto tam vidim souvislost.

Nevim uplne co je pricina a nasledek...
Jestli programatori nechteji delat na legacy a proto nejdou sehnat lidi a tak se porad offshoruje...
Nebo jestli manazeri tlaci na offshoring kvuli vetsim ziskum za vyvoj noveho a proto vyvojari zanedbavaji kvalitu, protoze vedi ze to nebudou muset udrzovat...

Ještě je tu třetí možnost. O nějaký tlak na vývoj nového nejde. A je to akorát důsledek krátkodobého tlaku na minimální cenu, bez nějaké dlouhodobější vize.

Ale to uz potom nema nic spolecneho s tou spinavou managerskou taktikou ne?

Nemá. Tu ale IMO předpokládal už tvůj příspěvek z 12:48.
Já osobně bych se spíš přikláněl k "po čtvrtletní uzávěrce potopa" bez nějakých dlouhodobějších zlých plánů.

128

Vývoj / Re:Nový projekt vs. cizí kód

« kdy: 14. 09. 2020, 16:26:55 »

Dovolte mi menší offtopic, ze zvědavosti:

Architektura stála na dvou vrstvách. JSP stránky a PL/SQL procedury v oracle databázi.

...

Databáze (PL/SQL) ... přes SOAP někam posílala data (!!) a posílala i třeba e-mailové notifikace.

V čem vidíš zrovna v tomto problém?

Za me teda:
1. (subjektivne) Nemam rad ani JSP ani PL/SQL ... nechtel bych s tim pracovat takze bych to tak ani nenavrhoval... ;-)
2. (Snad objektivne) Vendor lock-in. Business logika by mela byt implementovana v prenositelne forme jinak to prodrazi prechod na jinou DB.

Ptal jsem se z pohledu architektury, nikoliv z pohledu zvolené technologie. Viz kontext jeho příspěvku.

No architekturně mi přijde, že je to hodně neočekávané chování databáze. Databáze je úložiště, které obsluhuje požadavky. Od PL/SQL věcí bych čekal, že budou nějak přežvykovat data v rámci té databáze.

Kdybych hledal místo, kde se rozesílají notifikace nebo přeposílají data, tak je databáze jedno z posledních míst, kam bych se díval.

129

Vývoj / Re:Nový projekt vs. cizí kód

« kdy: 14. 09. 2020, 14:48:45 »

...
To je prave to co tady resim.
...

Ale ty jsi se ptal na preference vývojářů. Tahleta špinavá taktika je spíš manažerské rozhodnutí.

Pravda ze sem chtel resil predevsim tu motivaci odspodu.
To manazerske rozhodnuti je ale vyvojari vitano a podporovano (vetsinou) a proto tam vidim souvislost.

Nevim uplne co je pricina a nasledek...
Jestli programatori nechteji delat na legacy a proto nejdou sehnat lidi a tak se porad offshoruje...
Nebo jestli manazeri tlaci na offshoring kvuli vetsim ziskum za vyvoj noveho a proto vyvojari zanedbavaji kvalitu, protoze vedi ze to nebudou muset udrzovat...

Ještě je tu třetí možnost. O nějaký tlak na vývoj nového nejde. A je to akorát důsledek krátkodobého tlaku na minimální cenu, bez nějaké dlouhodobější vize.

130

Vývoj / Re:Nový projekt vs. cizí kód

« kdy: 14. 09. 2020, 13:57:46 »

...
To je prave to co tady resim.
...

Ale ty jsi se ptal na preference vývojářů. Tahleta špinavá taktika je spíš manažerské rozhodnutí.

131

Vývoj / Re:Nový projekt vs. cizí kód

« kdy: 10. 09. 2020, 23:50:29 »

Dobre... zpet k zakladni otazce a motivaci k ni.
Myslim, ze dlouhodobe neni udrzitelne kazde 2 roky vsechno prepisovat.

Ono to není nejen udržitelné, ale ani možné. Takže se to zas tak moc nedělá. Co má šanci na úspěch je přepis dílčích částí. Ale tak aby celý systém zůstal funkční.

Ja  som zazil projekty, ktore mali pravidlo "program moze byt len tak velky, aby ho jeden koder dokazal za mesiac napisat nanovo". Toto fungovalo fajn.

Jo, takovéhle jednoduché projekty se píšou fajn. Akorát že Běžný Franta Uživatel si zvykl používat počítač i k věcem, jejichž inherentní složitost je o pár řádů někde jinde.
Fakt bych rád viděl, jak by nějaký kodér napsal za měsíc třeba korektní práci s daty a časy. Nebo vykreslování unicodu. A to není ani celý program, to je jenom malý bezvýznamný dílek.
To pravidlo by mohlo fungovat pro nějakého lepiče lopatiče, který lepí dohromady prefabrikáty.

132

Vývoj / Re:Nový projekt vs. cizí kód

« kdy: 10. 09. 2020, 17:29:54 »

OK. takze odpoved na moji otazku z toho by byla...
"Na dlouhobezicich projektech se stihne vystridat vic lidi, a proto logicky i vic spatnych programatoru, a proto je to logicky vetsi hnuj a proto to nikdo nechce delat."

Chapu te spravne?

Ono to není primárně o kvalitě jednotlivých programátorů, ale procesu jako celku. Tým mizerných programátorů dobrý proces nespáchá. Ale dobří senioři zvládnou využít i mizerného programátora (samozřejmě v mezích).

Jak dobrý byl původní návrh? Každou chybějící informaci si musel tým vycucat z prstu.
Jak moc se nové požadavky odchýlily od původního návrhu? Vždycky je to o kompromisu a nedá se připravit na všecny možné změny.
Jak moc se tlačilo na čas a kašlalo na technologický dluh?
Jak dobře je zvládnuté testování? Bez pořádných testů se do kódu nedá v podstatě hrábnout.

133

Vývoj / Re:Nový projekt vs. cizí kód

« kdy: 10. 09. 2020, 17:21:17 »

Software se snad jmenuje "soft" proto ze ho jde snadno(levne) zmenit... na rozdil od hardware ktery se musi vetsinou vymenit.... Uz sme se dostali tak daleko, ze i software se musi zahodit a prepsat?

Odkud se vzalo slovo software je zajímavá otázka.

Ale že by se dal software nějak snadno a levně měnit je dost úsměvné. Vždyť spousta věcí změnit vůbec nejde, protože by to bylo tak drahé, že to nikdo nezaplatí. Právě z tohohle důvodu je spousta legacy systémů hromada rovnáků na vohejbáky na předchozí rovnáky. Nasbírat nesplatitelný technologický dluh je strašně jednoduché. Vlastně stačí předpokládat, že změny jsou jednoduché a tlačit na to aby byly i levné.

Změny jsou brutálně drahé. A čím dál je ta změna od původního návrhu, tím je dražší. Agilní metodika dělá změny trochu zvládnutelnější, ale i tak to není žádná hitparáda.

134

Odkladiště / Re:Bezpečnost elektronických voleb

« kdy: 04. 09. 2020, 10:30:32 »

Jo, do chvíle než by si náčelník svůj hlas zkontroloval, zmlátil voliče jak psa (příklad) a znova to přebil svým hlasem. Pokud by volič náhodou zvládl zahlasovat tak, aby to náčelník přebít nestihl, tak dostane nakládačku na jakou do smrti nezapomene. Pokud si svůj hlas může zkontrolovat volič, pak to samé může udělat i náčelník.

Pořád řešíte věc, která se reálně nijak neliší od současného stavu papírových voleb. V komunitě, kde to funguje způsobem nakládaček, nějaká fakticky správná kontrola nikoho nezajímá. Prostě pokud bude mít náčelník pocit, že někdo nejednal podle jeho příkazu, dostane dotyčný nakládačku – bez ohledu na to, jak jednal ve skutečnosti.

Mít pocit a důkaz se reálně sakra liší. Pohlídat si aby nějaký náčelník neměl podezření se dá, pokud nemá jednoduše k dispozici důkazy. Ani v komunitě která funguje způsobem nakládaček nemůže náčelník nechat zmlátit koho se mu zamane, ale musí k tomu mít přiměřenou podporu.

135

Odkladiště / Re:Bezpečnost elektronických voleb

« kdy: 04. 09. 2020, 09:06:29 »

Ano, což ale není zhoršení oproti papírovým volbám, kde je možné úplně to samé. Za peníze také můžete někomu slíbit, jak budete hlasovat – a většina lidí, která by to udělala, by tak skutečně i hlasovala. Ten, kdo by takhle hlasy nakupoval, samozřejmě riskuje, že se pár lidí pokusí podvést podvodníka, slíbí hlasovat nějak, ale pak ve skutečnosti budou volit podle sebe. A to samé by bylo i u elektronické volby – většina lidí, která by se nechala zlákat penězi, by svůj průkaz předala a nevolila by, no a pár lidí by kopii svého průkazu dala tomu „náčelníkovi“, ale pak by po něm stejně odvolila podle sebe – a protože by to bylo později, platil by jejich hlas.

Jo, do chvíle než by si náčelník svůj hlas zkontroloval, zmlátil voliče jak psa (příklad) a znova to přebil svým hlasem. Pokud by volič náhodou zvládl zahlasovat tak, aby to náčelník přebít nestihl, tak dostane nakládačku na jakou do smrti nezapomene. Pokud si svůj hlas může zkontrolovat volič, pak to samé může udělat i náčelník.

Edit :
Nebo ještě přímočařejší verze. V elektronických volbách by náčelník platil až po volbách, protože si to na rozdíl od papírových může zpětně ověřit.