Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #33966 > unrolled thread

Embedded HTTP Server

Back to article view | Back to pl.comp.programming

Contents

  Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-05 13:57 -0700
    Re: Embedded HTTP Server Wojciech Muła <wojtek.mula@gmail.com> - 2020-06-06 03:44 -0700
      Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-06 11:34 -0700
        Re: Embedded HTTP Server Wojciech Muła <wojtek.mula@gmail.com> - 2020-06-08 02:39 -0700
          Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-08 11:33 -0700
    Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-06 14:34 +0200
      Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-06 11:42 -0700
        Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-06 22:22 +0200
          Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-06 15:02 -0700
            Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-07 00:36 +0200
              Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-07 12:46 -0700
                Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-07 23:21 +0200
                  Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-08 00:49 -0700
                    Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-08 11:52 +0200
                      Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-08 13:43 -0700
                        Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-08 23:24 +0200
                          Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-08 14:52 -0700
                            Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-09 00:08 +0200
                              Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-09 13:23 -0700
                                Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-09 22:47 +0200
                                  Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-09 14:14 -0700
                                    Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-09 23:32 +0200
                                      Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-10 11:57 -0700
                                        Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-10 22:52 +0200
                                  Re: Embedded HTTP Server Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2020-06-10 07:50 +0200
                                    Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-10 08:09 +0200
                  Re: Embedded HTTP Server Mateusz Viste <mateusz@xyz.invalid> - 2020-06-08 10:32 +0200
    Re: Embedded HTTP Server Wojciech Muła <wojtek.mula@gmail.com> - 2020-06-06 10:10 -0700
      Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-06 12:00 -0700
        Re: Embedded HTTP Server Wojciech Muła <wojtek.mula@gmail.com> - 2020-06-08 03:25 -0700
          Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-08 12:20 -0700
            Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-08 21:32 +0200
              Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-08 14:44 -0700
                Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-09 00:22 +0200
                  Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-09 13:43 -0700
                    Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-09 23:15 +0200
                      Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-10 12:13 -0700
                        Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-10 22:54 +0200
                      Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-10 13:35 -0700
                        Re: Embedded HTTP Server heby <heby@poczta.onet.pl> - 2020-06-10 22:55 +0200
            Re: Embedded HTTP Server Wojciech Muła <wojtek.mula@gmail.com> - 2020-06-23 00:33 -0700
              Re: Embedded HTTP Server Maciej Sobczak <see.my.homepage@gmail.com> - 2020-06-23 14:13 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#34000

> Zaczynasz emulować model event-based.

Nie emulować, tylko sztucznie te zagadnienia rozdzielasz.
Przecież biblioteka oparta w całości o callbacki jest eventowa niemal z założenia. To Ty usiłujesz jej przypisać jakieś inne cechy.

> > Muteks jest potrzebny, jeśli masz powody, żeby robić sekcje krytyczne. Tylko od Ciebie zależy, czy będziesz miał te powody.
> 
> Nie. Jeśli mam event-based to nie mam powodów aby z powodu bibloteki 
> robić coś ekstra.

Ciągle nie pokazałeś, dlaczego miałbyś robić coś ekstra.
I dlaczego to akurat miałoby być z powodu tej biblioteki.

Powtórzę: przykłady 1-5 *nie mają* muteksów. A jakie piękne GUI mają.

> >> Mały muteksiak to duży kłopot w kilku przypadkach.
> > Ale zapomniałeś je opisać.
> 
> Na przykład tam gdzie masz do czynienia z RT.

No i? Jest cała szkoła modelowania systemów RT z obiektami chronionymi (patrz np. Ada i związane z nią papiery akademickie), gdzie muteksy w niczym nie przeszkadzają. Jaki masz problem z tymi muteksami?

> Powiedzmy... piszesz soft do drukarki 3D sterujący wprost mechaniką.

Łał. Myślałem, że drukarki 3D to był szpan dwa lata temu. :-p
Teraz młodzież steruje dronami.
 
> Wystawiasz w nim serwer www do sterowania.

Masz na myśli, że serwer www lata na RaspberryPi, który jest ukryty w obudowie drukarki (no bo jeszcze USB, ekranik, update'y z pendrive'a, i inne tego typu oczywistości, bez których nikt by tej drukarki nie dotknął) a sterowanie leci z mikrokontrolera?
Czy może masz na myśli to, że jakiś masochista uparł się, że serwer www z niesterowalnym stosem TCP musi koniecznie być na jedynym mikrokontrolerze?

No to niech będzie ta wersja od masochisty.

> Mutexy są mało sensowne

Ale dalej nie pokazałeś, po co te muteksy. Masz jakieś fiksacje. :-)

> Prawie kazdy widział wątek. Promil wie jak działa pod maską.
[...]
> Fakt, w http cięzko takie zagadnienia znaleźć ...

O, to, to. Fajnie, że dostrzegasz bezcelowość swojego trollowania. :-)

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#34003

On 09/06/2020 23:14, Maciej Sobczak wrote:
> Nie emulować, tylko sztucznie te zagadnienia rozdzielasz.
> Przecież biblioteka oparta w całości o callbacki jest eventowa niemal z założenia. To Ty usiłujesz jej przypisać jakieś inne cechy.

Ale "eventowa z wątkami" to nie to samo co "coroutines/cooperative". 
Więc jeśli będziesz się upierał o to że callback z wątku to "event" to 
mamy rózne pojęcie co to jest event-based i oba do obrony.

>>> Muteks jest potrzebny, jeśli masz powody, żeby robić sekcje krytyczne. Tylko od Ciebie zależy, czy będziesz miał te powody.
>> Nie. Jeśli mam event-based to nie mam powodów aby z powodu bibloteki
>> robić coś ekstra.
> Ciągle nie pokazałeś, dlaczego miałbyś robić coś ekstra.
> I dlaczego to akurat miałoby być z powodu tej biblioteki.

Bibliteka czyta/zapisuje zmienną globalną w implementacji callbacka.

Muszę ją obarierować i używać tej bariery w kodzie który nie ma NIC 
wspólnego z serwerem HTTP. W ten sposób wątki z jakiejś bibliteki 
agresywnie wymuszają na mnie zmiany kodu w miejscach odległych.

> Powtórzę: przykłady 1-5 *nie mają* muteksów. A jakie piękne GUI mają.

Helloworldy zazwyczaj nie mają żadnych problemów, chyba głównie dlatego 
że połowa biblitek na necie nie ma innych zastosowań niż własne helloworldy.

Innymi słowy trudno o to aby kilka przykładów było dowodem w innym 
zastosowaniu.

>>>> Mały muteksiak to duży kłopot w kilku przypadkach.
>>> Ale zapomniałeś je opisać.
>> Na przykład tam gdzie masz do czynienia z RT.
> No i? Jest cała szkoła modelowania systemów RT z obiektami chronionymi (patrz np. Ada i związane z nią papiery akademickie), gdzie muteksy w niczym nie przeszkadzają. Jaki masz problem z tymi muteksami?

Zajmują czas, wymagają grubego schedulera preemptive ze skomplikowaną 
logią "Wait". Co prawda taki scheduler jest w zasięgu przeciętnego 
programisty, ale to już nie jest za darmo.

>> Powiedzmy... piszesz soft do drukarki 3D sterujący wprost mechaniką.
> Łał. Myślałem, że drukarki 3D to był szpan dwa lata temu. :-p
> Teraz młodzież steruje dronami.

Nie, ten przykład to takie RT w domu, czyli w sam raz target Twojej 
bibliteki. Hobbystyczny soft z hobbystycznymi biblitekami.

>> Wystawiasz w nim serwer www do sterowania.
> Masz na myśli, że serwer www lata na RaspberryPi

Obecnie sterowniki mają zaszyte jakeiś ARMy po 100MHz. Mimo że to RT to 
w zasadzie procesor ma sporo wolnego w tzw "międzyczasie". Dlaczego nie 
miałby generować jakiegoś www?

> Czy może masz na myśli to, że jakiś masochista uparł się, że serwer www z niesterowalnym stosem TCP musi koniecznie być na jedynym mikrokontrolerze?

Trudno to nazwać masochizmem że ktoś stara się wykorzystać CPU bez 
dodatkowego point-of-failure jakim jest extra Pi robiące za serwer www.

>> Mutexy są mało sensowne
> Ale dalej nie pokazałeś, po co te muteksy. Masz jakieś fiksacje. :-)

Masz wątki to i masz mutexy. W zasadzie czasem tylko memory barrier z 
tych mutextów, ale mimo to dalej masz *coś*. Gdyby było to tylko w 
adapterze do tej bibliteki to spoko. Ale wątki złośliwie zarażają resztę 
kodu pojęciem zasobu krytycznego.

>> Prawie kazdy widział wątek. Promil wie jak działa pod maską.
> [...]
>> Fakt, w http cięzko takie zagadnienia znaleźć ...
> O, to, to. Fajnie, że dostrzegasz bezcelowość swojego trollowania. :-)

Trudno powiedzieć czy to trolowanie. W zasadzie nie wiem. Może to 
dlatego że niedawno trafiłem na równie bezuzyteczny kawałek kodu. Niby 
mógłbym użyć, ale ... detale ... jak ten while (1){} w stackless TCLu. 
Prawie dobrze tylko całkiem do dupy. Taka karma :/

[toc] | [prev] | [next] | [standalone]

#34007

> > Ciągle nie pokazałeś, dlaczego miałbyś robić coś ekstra.
> > I dlaczego to akurat miałoby być z powodu tej biblioteki.
> 
> Bibliteka czyta/zapisuje zmienną globalną w implementacji callbacka.
> 
> Muszę ją obarierować

Dlaczego musisz? Jeśli callbacki są szeregowane[*], to nie musisz.

[*] Ale nie są.

> i używać tej bariery w kodzie który nie ma NIC 
> wspólnego z serwerem HTTP.

Eee... To po co używasz biblioteki HTTP?

> W ten sposób wątki z jakiejś bibliteki 
> agresywnie wymuszają na mnie zmiany kodu w miejscach odległych.

Używasz zmiennej globalnej z odległych miejsc? Kiepsko.
Dlaczego obwiniasz jakąś bibliotekę o problemy spowodowane złą architekturą Twojego programu?

> >> Wystawiasz w nim serwer www do sterowania.
> > Masz na myśli, że serwer www lata na RaspberryPi
> 
> Obecnie sterowniki mają zaszyte jakeiś ARMy po 100MHz. Mimo że to RT to 
> w zasadzie procesor ma sporo wolnego w tzw "międzyczasie". Dlaczego nie 
> miałby generować jakiegoś www?

No więc skoro ma sporo wolnego, to jaki masz problem?
I jakie proporcje w tym problemie? Na takich sprzętach ludzie wsadzają pełny RTOS, pełny stos TCP, chcą jeszcze serwer www i w tym wszystkim jest jakiś wyimaginowany problem z muteksem? Pomyliłeś proporcje. Zwłaszcza, że w takiej składance muteksów jest już nadziabanych jakieś kilkadziesiąt.

> > Czy może masz na myśli to, że jakiś masochista uparł się, że serwer www z niesterowalnym stosem TCP musi koniecznie być na jedynym mikrokontrolerze?
> 
> Trudno to nazwać masochizmem że ktoś stara się wykorzystać CPU bez 
> dodatkowego point-of-failure jakim jest extra Pi robiące za serwer www.

I dlatego wsadza serwer www do krytycznego kontrolera? Żeby nie mieć dodatkowego point-of-failure?
Ja na taką logikę nic nie poradzę i nikomu nie obiecuję swojego udziału.

> Masz wątki to i masz mutexy.

Dalej nie pokazałeś, dlaczego.
Ani też dlaczego to miałby być problem.

> Trudno powiedzieć czy to trolowanie. W zasadzie nie wiem. Może to 
> dlatego że niedawno trafiłem na równie bezuzyteczny kawałek kodu.

To straszne.
Najstraszniejsze jest jednak to, że się tak bardzo tym przejmujesz.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#34010

On 6/10/2020 8:57 PM, Maciej Sobczak wrote:
>> Bibliteka czyta/zapisuje zmienną globalną w implementacji callbacka.
>> Muszę ją obarierować
> Dlaczego musisz? Jeśli callbacki są szeregowane[*], to nie musisz.
> [*] Ale nie są.

Dlatego muszę.

>> i używać tej bariery w kodzie który nie ma NIC
>> wspólnego z serwerem HTTP.
> Eee... To po co używasz biblioteki HTTP?

Kod od manipulowania, powiedzmy, silnikami nic o jakims http nie wie. 
Ale razem pracuja na jednym cpu i moga mieć dostęp do tych samych 
zasobów jak np. zmienne okreslające położenie czy stan.

>> W ten sposób wątki z jakiejś bibliteki
>> agresywnie wymuszają na mnie zmiany kodu w miejscach odległych.
> Używasz zmiennej globalnej z odległych miejsc? Kiepsko.

W niektórych sytuacjah, jak opisywany sterwanik druku 3D, takim stanem 
jest bardzo duzo róznych małych detali. Gdzie jest glowica, jaka jest 
prędkośc itd itp.

> Dlaczego obwiniasz jakąś bibliotekę o problemy spowodowane złą architekturą Twojego programu?

Ona w tym zastosowaniu NIE jest zła. Jest wręcz jedyna sensowna przy 
200kB flasha.

>> Obecnie sterowniki mają zaszyte jakeiś ARMy po 100MHz. Mimo że to RT to
>> w zasadzie procesor ma sporo wolnego w tzw "międzyczasie". Dlaczego nie
>> miałby generować jakiegoś www?
> No więc skoro ma sporo wolnego, to jaki masz problem?

Poniewaz nie rozumiesz dlaczego można się wiekszośc czasu nudzić i 
jednoczesnie mieć problem z wyrobieniem się w zastosowaniach RT. Otórz 
twój preemptive multitasking powoduje że *akurat* w tym złosliwym 
przykładzie może to powodować konkretne skutki w postacji utraty jakości 
wydruku. Tylko dlatego że trzeba przełaczyc konteks kiedy glowica 
właśnie wjechala w materiał.

> I jakie proporcje w tym problemie?

Jakie sobie tylko wymyslisz.

> Na takich sprzętach ludzie wsadzają pełny RTOS

Na ARM7, powiedzmy, ma to już resztkę sensu.

>, pełny stos TCP

Nie jest potrzebny. Wystarczy kawalek.

>, chcą jeszcze serwer www i w tym wszystkim jest jakiś wyimaginowany problem z muteksem? Pomyliłeś proporcje.

Raczej "mam to na codzień".

> Zwłaszcza, że w takiej składance muteksów jest już nadziabanych jakieś kilkadziesiąt.

Zero.

>> Trudno to nazwać masochizmem że ktoś stara się wykorzystać CPU bez
>> dodatkowego point-of-failure jakim jest extra Pi robiące za serwer www.
> I dlatego wsadza serwer www do krytycznego kontrolera? Żeby nie mieć dodatkowego point-of-failure?

Tak. Albo dla wygody. Albo bo to modne. Rózne można miec powody.

> Ja na taką logikę nic nie poradzę i nikomu nie obiecuję swojego udziału.

I nikt nie obiecuje że uzyje w tym zastosowaniu. Dzień jak co dzień w 
OpenSource.

>> Masz wątki to i masz mutexy.
> Dalej nie pokazałeś, dlaczego.

Niezupełnie. Po prostu odrzucasz częśc rzewczywostości nie pasującej do 
zastosowania aktualnego. Wolno Ci.

> Ani też dlaczego to miałby być problem.

To też już zostało wyjasnione.

> To straszne.
> Najstraszniejsze jest jednak to, że się tak bardzo tym przejmujesz.

Czyli miałem rację. Nie chciałeś zapytać o porady co do kodu. Po prostu 
musisz sobie podsykutować z rosnącym poziomem adrenaliny.

Ale nuda. EOT.

[toc] | [prev] | [next] | [standalone]

#34004

W dniu 09-06-2020 o 22:47, heby pisze:
> On 09/06/2020 22:23, Maciej Sobczak wrote:
>> [*] OK, osobne połączenia klienckie to fizycznie różne wątki. Ale da 
>> się o tym nie myśleć, mogę specjalnie dla Ciebie dodać serializację 
>> callbacków.
> 
> Zaczynasz emulować model event-based. Za chwile pojawi się lock-free 
> kolejka i już będziemy w domu.
> 
>> Muteks jest potrzebny, jeśli masz powody, żeby robić sekcje krytyczne. 
>> Tylko od Ciebie zależy, czy będziesz miał te powody.
> 
> Nie. Jeśli mam event-based to nie mam powodów aby z powodu bibloteki 
> robić coś ekstra.
> 
>>> Mały muteksiak to duży kłopot w kilku przypadkach.
>> Ale zapomniałeś je opisać.
> 
> Na przykład tam gdzie masz do czynienia z RT.
> 
> Powiedzmy... piszesz soft do drukarki 3D sterujący wprost mechaniką. 
> Wystawiasz w nim serwer www do sterowania. Mutexy są mało sensowne bo 
> pracujesz nie dośc że w środowisku RT to jeszcze z masą przerwań o 
> priorytetach wyższych niż switch kontekstu.

zaraz, zaraz... chcesz napisać, że na platformach wielocorowych nie 
korzystasz z wątków?

Przecież to marnowanie wydajności.

-- 
http://kaczus.ppa.pl

[toc] | [prev] | [next] | [standalone]

#34005

On 10/06/2020 07:50, Tomasz Kaczanowski wrote:
>> Powiedzmy... piszesz soft do drukarki 3D sterujący wprost mechaniką. 
>> Wystawiasz w nim serwer www do sterowania. Mutexy są mało sensowne bo 
>> pracujesz nie dośc że w środowisku RT to jeszcze z masą przerwań o 
>> priorytetach wyższych niż switch kontekstu.
> zaraz, zaraz... chcesz napisać, że na platformach wielocorowych nie 
> korzystasz z wątków?

Dlaczego wielocorowych? Przecięny ARM sterownika drukarki 3D, w wersji 
mikrokontrolerowej, ma 1 rdzeń.

> Przecież to marnowanie wydajności.

Gdybym w systemie RT miał do wyboru czy drugi rdzeń poświęcę na 
zagadnienia sterowania silnikami czy może na obsługę serwera www to 
zgadnij co wybiorę ...

[toc] | [prev] | [next] | [standalone]

#33979

2020-06-07 o 23:21 +0200, heby napisał:
> Jeśli nie zaimplementujesz jakiegoś ficzera to ludzie potrzebujący
> go, nie wezmą tej bibliteki. Ponieważ nie napiszą Ci że coś jest
> potrzebne będziesz miał fałszywe przeswiadczenie że nikomu to nie
> jest potrzebne.

A jednak ja co rusz dostaję jakieś prośby o dodatkowe funkcje i sugestie
dot. moich programów... Twoja teoria się nie sprawdza :)
Oczywiście może być tak jak piszesz, ale tylko w sytuacji, kiedy
istnieje szeroki wybór alternatyw i jest coś, co pasuje idealnie do
potrzeby użytkownika. Ale w takim wypadku niech faktycznie bierze to
coś innego co mu pasuje idealnie i nie zawraca dupy.

Mateusz

[toc] | [prev] | [next] | [standalone]

#33969

On Friday, June 5, 2020 at 10:57:51 PM UTC+2, Maciej Sobczak wrote:
> Z przyjemnością informuję o narodzinach wersji 1.0 nowego pakietu:
> 
> http://www.inspirel.com/httpserver/
> 
> Jest to bardzo prosta biblioteka w C++11, dla systemów Linux, Mac OS X oraz Windows, pozwalająca progamowi w C++ wyświetlić swoje GUI na przeglądarce webowej.
> 
> Idea jest również opisana tutaj:
> 
> https://en.wikipedia.org/wiki/Embedded_HTTP_server
> 
> i wbrew nazwie nie ma bezpośredniego związku z systemami wbudowanymi (chociaż na RaspberryPi i podobnych można by było z satysfakcją domknąć tą definicję).
> 
> Wszelkie komentarze mile widziane.

Po pierwsze, to aż się prosi, żeby ten serwer był zwykłą klasą. Czemu ktoś nie miałby sobie stworzyć 5 serwisów WWW działających na różnych portach?

Po drugie, nie ma sposobu na zamknięcie serwera, poza zabiciem procesu. Chyba, że ja czegoś nie widzę.

Mówiąc o API: 6 wariantów register_{generic,html,text}_{post,get}_action można by sprowadzić do 2. register_action(const char* name, {post_action_type, get_action_type} callback, const char* mime_type). Zresztą, może lepiej byłoby przyjmować jako argument mapę akcji - czyli to co masz teraz w get_actions/post_actions. Niech user sobie przygotuje takie mapy w sposób, jaki mu pasuje, a ty pozbędziesz się potrzeby blokowania tych struktur.

Czasem funkcje przyjmują const char*, czase std::string& co jest niespójne.

W ogóle nie walidujesz, czy wskaźniki są niepuste. Tak samo z std::function.

Zero testów. Serio? :)

w.

[toc] | [prev] | [next] | [standalone]

#33972

> Po pierwsze, to aż się prosi, żeby ten serwer był zwykłą klasą. Czemu ktoś nie miałby sobie stworzyć 5 serwisów WWW działających na różnych portach?

No właśnie. I tu poruszamy ważną kwestię. Bo piszesz, że aż się prosi, ale potem okazuje się, że nikt nie prosi, tylko czemu ktoś by miał nie prosić.

A mi chodziło o to, żeby pakiet 1.0 przekroczył próg używalności a nie o to, żeby rozwiązać problemy typu "czemy ktoś nie miałby".

Natomiast, nic nie stoi na przeszkodzie, żeby sobie zawołać funkcję server_start() 5 razy z różnymi portami, z 5 różnych wątków, bo ta funkcja i tak nie ma stanu globalnego. Nie trzeba mieć do tego klasy.

> Po drugie, nie ma sposobu na zamknięcie serwera, poza zabiciem procesu. Chyba, że ja czegoś nie widzę.

Tak. Funkcja server_stop() już istniała, ale ją usunąłem. To nie jest oczywiste, jak zamknąć serwer, który ma callbacki, niektóre zapewne w trakcie pracy.
Wszystkie problemy da się rozwiązać, ale nie o to chodziło w wersji 1.0.

> Mówiąc o API: 6 wariantów register_{generic,html,text}_{post,get}_action można by sprowadzić do 2. register_action(const char* name, {post_action_type, get_action_type} callback, const char* mime_type).

Nie, bo po pierwsze generic i html różnią się obsługą a po drugie nie chciałem przeciążać funkcji register, bo bardziej naturalne wydaje mi się przeciążenie funkcji akcji dla get i post:

void my_action(to-co-trzeba-dla-get) { ... }
void my_action(to-co-trzeba-dla-post) { ... }

I wtedy nie dałoby rady:

register(my_action);

> Zresztą, może lepiej byłoby przyjmować jako argument mapę akcji - czyli to co masz teraz w get_actions/post_actions. Niech user sobie przygotuje takie mapy w sposób, jaki mu pasuje, a ty pozbędziesz się potrzeby blokowania tych struktur.

Ale teraz obsługa jest prostsza, właśnie dlatego, że user nie musi robić takich map.
Można by było pomyśleć o akcji catch-all. Tam user dostawałby wszystko (co nie było obsłużone) i mógłby sobie tam zrobić takie mapy, jakie zechce.

> Czasem funkcje przyjmują const char*, czase std::string& co jest niespójne.

Bo chodziło o przewidywane użycie. Tam gdzie przewidywałem literał, jest const char*.

> W ogóle nie walidujesz, czy wskaźniki są niepuste. Tak samo z std::function.

A po co? Bez przesady z tą walidacją. Walidować należy input z zewnątrz (i nawet opisałem to w przykładzie 3, z parametrami) a nie własne literały.

> Zero testów. Serio? :)

Są testy. W katalogu, który dla zmylenia przeciwnika nazywa się examples. :-)

A jakieś inne testy byś chciał?

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#33982

On Saturday, June 6, 2020 at 9:00:07 PM UTC+2, Maciej Sobczak wrote:
> > Po pierwsze, to aż się prosi, żeby ten serwer był zwykłą klasą. Czemu ktoś nie miałby sobie stworzyć 5 serwisów WWW działających na różnych portach?
> 
> No właśnie. I tu poruszamy ważną kwestię. Bo piszesz, że aż się prosi, ale potem okazuje się, że nikt nie prosi, tylko czemu ktoś by miał nie prosić.

Czyli ograniczasz użytkowników do jednego przypadku i to w sytuacji, gdy dodanie jednego stopnia swobody nie kosztuje ani użytkownika, ani Ciebie nic.

> A mi chodziło o to, żeby pakiet 1.0 przekroczył próg używalności a nie o to, żeby rozwiązać problemy typu "czemy ktoś nie miałby".

Żeby Twojego rozwiązania użyć w jakimś normalnym programie, trzeba stworzyć wątek. Wygodne użycie, to byłoby coś takiego:

int main() {
   auto server = std::make_unique<http::Server>(8008, ".");
   
   // tu sobie programista coś inicjalizuje
   
   server->start();
   
   // tu się dzieje magia, która programista uprawia
   // a gdy się kończy scope, to server się sam zamyka
}

> Natomiast, nic nie stoi na przeszkodzie, żeby sobie zawołać funkcję server_start() 5 razy z różnymi portami, z 5 różnych wątków, bo ta funkcja i tak nie ma stanu globalnego. Nie trzeba mieć do tego klasy.

Stoi, bo masz współdzieloną mapę routingu. A, że masz ją współdzieloną, to też masz radosnego mutexa w głównej pętli.

> > Po drugie, nie ma sposobu na zamknięcie serwera, poza zabiciem procesu. Chyba, że ja czegoś nie widzę.
> 
> Tak. Funkcja server_stop() już istniała, ale ją usunąłem. To nie jest oczywiste, jak zamknąć serwer, który ma callbacki, niektóre zapewne w trakcie pracy.
> Wszystkie problemy da się rozwiązać, ale nie o to chodziło w wersji 1.0.

No i to jest defekt. Ja chcę, żeby mój program się zamykał w cywilizowany sposób.
Callbacki są wołane w wątkach, robisz sobie na nie barierę (czyli np. latch) po zakończeniu głównej pętli i po kłopocie.

> > Mówiąc o API: 6 wariantów register_{generic,html,text}_{post,get}_action można by sprowadzić do 2. register_action(const char* name, {post_action_type, get_action_type} callback, const char* mime_type).
> 
> Nie, bo po pierwsze generic i html różnią się obsługą a po drugie nie chciałem przeciążać funkcji register, bo bardziej naturalne wydaje mi się przeciążenie funkcji akcji dla get i post:
> 
> void my_action(to-co-trzeba-dla-get) { ... }
> void my_action(to-co-trzeba-dla-post) { ... }
> 
> I wtedy nie dałoby rady:
> 
> register(my_action);

To jest koślawe, sorry. W HTTP masz nie tylko akcje GET i POST, ale i chyba ze 20 innych. Poza tym założenie, że ktoś będzie argumenty POST przesyłał w URL-u jest zdziebko przestarzałe, o wiele wygodniej jest słać parametry w JSONie.

> > Zresztą, może lepiej byłoby przyjmować jako argument mapę akcji - czyli to co masz teraz w get_actions/post_actions. Niech user sobie przygotuje takie mapy w sposób, jaki mu pasuje, a ty pozbędziesz się potrzeby blokowania tych struktur.
> 
> Ale teraz obsługa jest prostsza, właśnie dlatego, że user nie musi robić takich map.

Pamiętanie o kilku wariantach funkcji nie jest prostsze. Już lepiej byłoby mieć jedną przeciążoną metodę register i kilka pomocniczych funkcji w stylu "make_get_action".

> Można by było pomyśleć o akcji catch-all. Tam user dostawałby wszystko (co nie było obsłużone) i mógłby sobie tam zrobić takie mapy, jakie zechce.
> 
> > Czasem funkcje przyjmują const char*, czase std::string& co jest niespójne.
> 
> Bo chodziło o przewidywane użycie. Tam gdzie przewidywałem literał, jest const char*.

const char* to nie tylko literały, tego założenia nie da się odczytać z API.
 
> > W ogóle nie walidujesz, czy wskaźniki są niepuste. Tak samo z std::function.
> 
> A po co? Bez przesady z tą walidacją. Walidować należy input z zewnątrz (i nawet opisałem to w przykładzie 3, z parametrami) a nie własne literały.

Bo programista się czasem myli, więc powinien się koncentrować na błędach w kodzie, który pisze, a nie którego używa.

> > Zero testów. Serio? :)
> 
> Są testy. W katalogu, który dla zmylenia przeciwnika nazywa się examples. :-)
> 
> A jakieś inne testy byś chciał?

Np. testy jednostkowe parserów, których jest co najmniej ze 2. Jak widzę
5-krotnie zagnieżdżony kod, to nie wiem, czego się spodziewać.

w.

[toc] | [prev] | [next] | [standalone]

#33984

> Żeby Twojego rozwiązania użyć w jakimś normalnym programie, trzeba stworzyć wątek.

Cała jedna linijka kodu. Której w prostych programach nawet nie trzeba (patrz przykłady).

> Wygodne użycie, to byłoby coś takiego:
> 
> int main() {
>    auto server = std::make_unique<http::Server>(8008, ".");
>    
>    server->start();

Czyli też jedna dodatkowa linijka kodu, w dodatku zawsze, nawet w najprostszym programie.
Więc na czym polega postęp?

>    // tu się dzieje magia, która programista uprawia
>    // a gdy się kończy scope, to server się sam zamyka
> }

Się tak łatwo nie zamyka, jeśli ma callbacki.

> > Natomiast, nic nie stoi na przeszkodzie, żeby sobie zawołać funkcję server_start() 5 razy z różnymi portami, z 5 różnych wątków, bo ta funkcja i tak nie ma stanu globalnego. Nie trzeba mieć do tego klasy.
> 
> Stoi, bo masz współdzieloną mapę routingu.

Przyłapałeś mnie. Skupiłem się na portach - faktycznie mapa jest wspólna.
Czyli twierdzisz, że ktoś będzie koniecznie chciał zrobić w jednym programie 5 serwerów na różnych portach, ale tak, żeby takie same linki robiły w nich różne rzeczy?
To brzmi jak ostra perwersja. Tylko dlaczego ja mam w tym uczestniczyć?

Jeśli moja biblioteka miałaby swoją ułomnością powstrzymać kogoś przed tą perwersją, to nawet uznałbym to za moralny sukces. :-)

> A, że masz ją współdzieloną, to też masz radosnego mutexa w głównej pętli.

I w czym ten mutex przeszkadza, skoro go nawet nie widać?

> No i to jest defekt. Ja chcę, żeby mój program się zamykał w cywilizowany sposób.
> Callbacki są wołane w wątkach, robisz sobie na nie barierę (czyli np. latch) po zakończeniu głównej pętli i po kłopocie.

O ile wszystkie wrócą. Zobacz przykład 6. Można go przepisać tak, że to funkcja get_updates() będzie robić to, co activity(). Czyli nigdy nie wróci.

Ale owszem, jest to możliwe rozwiązanie, tylko wymaga zmiany koncepcji komunikacji. Teraz, w prostej implementacji, jest to komunikacja blokująca. Wątek obsługujący połączenie nie wróci, jeśli utknął na odczycie z gniazda (a w tym stanie spędza większość czasu), dopóki *klient* tego połączenia nie zamknie. Nie wystarczy sobie ustawić flagę.
Można to rozwiązać wprowadzając dodatkowe mechanizmy typu select() albo poll(), ale zrobienie tego dobrze to złożoność porównywalna z całą resztą kodu i to są właśnie problemy, których nie chciałem rozwiązywać w wersji 1.0.

Ten problem jest rozwiązany w bibliotece YAMI4, ale to zupełnie inna liga.

> To jest koślawe, sorry. W HTTP masz nie tylko akcje GET i POST, ale i chyba ze 20 innych.

Ale ja nie obiecuję obsługi tych 20 innych.

> Poza tym założenie, że ktoś będzie argumenty POST przesyłał w URL-u jest zdziebko przestarzałe, o wiele wygodniej jest słać parametry w JSONie.

Przecież właśnie tak jest. Dlatego funkcje dla POST mają dodatkowy argument istream - tam są te dane, które normalni ludzie przekazują.

I właśnie dlatego funkcje dla GET i POST *różnią się* sygnaturami.

> Pamiętanie o kilku wariantach funkcji nie jest prostsze. Już lepiej byłoby mieć jedną przeciążoną metodę register i kilka pomocniczych funkcji w stylu "make_get_action".

Czyli że:

register(make_get_action(my_action));

jest lepsze od:

register_get_action(my_action);

Sorry - ani trochę.

> > A po co? Bez przesady z tą walidacją. Walidować należy input z zewnątrz (i nawet opisałem to w przykładzie 3, z parametrami) a nie własne literały.
> 
> Bo programista się czasem myli, więc powinien się koncentrować na błędach w kodzie, który pisze, a nie którego używa.

Ale dlaczego ma się koncentrować na błędach w kodzie, którego używa, skoro takich nie znalazł a za to ma błędy w swoim? :-)

I czym się różni pomyłka polegająca na użyciu pustego wskaźnika od pomyłki polegającej na użyciu wskaźnika do niewłaściwej funkcji?
Otóż niczym się nie różni - a kompleksowe rozwiązanie tego zagadnienia (czyli zapewnienie, że programista sięgnął po właściwą funkcję) nie leży po stronie użytej biblioteki. To jest jedno z częstych nieporozumień w temacie weryfikacji albo defensywnego kodowania.

Na tej podstawie zakładam, że programista poda wskaźnik do właściwej funkcji. To założenie jest częścią kontraktu tej biblioteki.

> > A jakieś inne testy byś chciał?
> 
> Np. testy jednostkowe parserów, których jest co najmniej ze 2. Jak widzę
> 5-krotnie zagnieżdżony kod, to nie wiem, czego się spodziewać.

Uwaga, szpan: pokrycie strukturalne zapewniłem testami systemowymi.

Bez przesady z tymi testami.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#33985

On 08/06/2020 21:20, Maciej Sobczak wrote:
> I czym się różni pomyłka polegająca na użyciu pustego wskaźnika od pomyłki polegającej na użyciu wskaźnika do niewłaściwej funkcji?

Na tym że pierwsa jest wykrywana przez trywialny assert. Nie użycie go 
świadczy o bardzo kiepskiej jakości kodzie ponieważ bibiloteka nawet 
*takiej* oczywistości nie weryfikuje, a powinna weryfikować jak nawięcej 
(w debugu).

> Otóż niczym się nie różni

Z praktyki wynika że nullowe pointery są znacznie wiekszym problemem niż 
niewłaściwe pointery, bo te drugie często załatwia się kontrolą typów. 
Szczególnie kiedy biblitekę używasz po raz pierwszy i spodziewasz się 
choć odrobiny wsparcia po jej stronie.

> Bez przesady z tymi testami.

Nie wykluczam że w projaktach hobbystycznych jest jakiś margines 
projektów gdzie faktycznie psu na budę te testy. Skoro taki masz target...

[toc] | [prev] | [next] | [standalone]

#33988

> > I czym się różni pomyłka polegająca na użyciu pustego wskaźnika od pomyłki polegającej na użyciu wskaźnika do niewłaściwej funkcji?
> 
> Na tym że pierwsa jest wykrywana przez trywialny assert.

Który nie wykrywa niczego innego. To, że jesteś na lądzie, nie znaczy, że pod właściwym adresem (pun intended).

> Nie użycie go 
> świadczy o bardzo kiepskiej jakości kodzie

Według jakich kryteriów?

> ponieważ bibiloteka nawet 
> *takiej* oczywistości nie weryfikuje

Od kiedy to biblioteki HTTP służą do weryfikacji programów?

> a powinna weryfikować jak nawięcej

Według jakiego procesu produkcji oprogramowania?

> Z praktyki wynika że nullowe pointery są znacznie wiekszym problemem niż 
> niewłaściwe pointery, bo te drugie często załatwia się kontrolą typów.

Nie, bo wszystkie akcje GET mają ten sam typ.

register_get_html("action1", action1);
register_get_html("action2", action2);
register_get_html("action3", action2);

Jest bug. Co więcej, zdecydowanie łatwiej jest go zrobić, niż napisać NULL.

> Szczególnie kiedy biblitekę używasz po raz pierwszy i spodziewasz się 
> choć odrobiny wsparcia po jej stronie.

Wsparcie jest w tym, że API jest minimalne i nie narzuca się z niepotrzebnymi abstrakcjami.

> Nie wykluczam że w projaktach hobbystycznych jest jakiś margines 
> projektów gdzie faktycznie psu na budę te testy. Skoro taki masz target...

Targetem są świadomi inżynierowie, którzy nie oczekują od biblioteki HTTP, że im zrobi weryfikację poprawności programu...

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#33992

On 08/06/2020 23:44, Maciej Sobczak wrote:
>> Na tym że pierwsa jest wykrywana przez trywialny assert.
> Który nie wykrywa niczego innego.

Ale to co wykrywa jest przydatne.

>> Nie użycie go
>> świadczy o bardzo kiepskiej jakości kodzie
> Według jakich kryteriów?

Programowania defensywnego na inpucie.

>> ponieważ bibiloteka nawet
>> *takiej* oczywistości nie weryfikuje
> Od kiedy to biblioteki HTTP służą do weryfikacji programów?

W każdym inpucie powinna być weryfikacja, ponieważ *ułatwia* to 
debugowanie klientowi.

W każdym innym miejscu powinna być weryfikacja, bo ułatwia to 
refaktoring *autorowi*.

>> a powinna weryfikować jak nawięcej
> Według jakiego procesu produkcji oprogramowania?

Dojrzałego.

>> Z praktyki wynika że nullowe pointery są znacznie wiekszym problemem niż
>> niewłaściwe pointery, bo te drugie często załatwia się kontrolą typów.
> Nie, bo wszystkie akcje GET mają ten sam typ.

No w tym wypadku nie. W sytuacji ogólnej tak.

> register_get_html("action1", action1);
> register_get_html("action2", action2);
> register_get_html("action3", action2);
> Jest bug. Co więcej, zdecydowanie łatwiej jest go zrobić, niż napisać NULL.

To dlatego że masz ascii-art programming. I rozumiem że nie da się tego 
zrobić łatwo i bezpiecznie. Dość specyficzny przypadek gdzie kontrola 
typów nie zadziała. Nie da się mieć wszystkiego, ale to nie znaczy że 
nie można mieć choć troche.

>> Szczególnie kiedy biblitekę używasz po raz pierwszy i spodziewasz się
>> choć odrobiny wsparcia po jej stronie.
> Wsparcie jest w tym, że API jest minimalne i nie narzuca się z niepotrzebnymi abstrakcjami.

Assert to nie abstrakcja. To ... nic.

>> Nie wykluczam że w projaktach hobbystycznych jest jakiś margines
>> projektów gdzie faktycznie psu na budę te testy. Skoro taki masz target...
> Targetem są świadomi inżynierowie, którzy nie oczekują od biblioteki HTTP, że im zrobi weryfikację poprawności programu...

Chyba takich jest relatywnie mało. Sądzepo ilości assertów w poważnych 
biblitekach.

[toc] | [prev] | [next] | [standalone]

#33997

> >> Nie użycie go
> >> świadczy o bardzo kiepskiej jakości kodzie
> > Według jakich kryteriów?
> 
> Programowania defensywnego na inpucie.

Rzucam tezą, że ktoś z dobrą intencją ulepił koncept a cała masa ludzi ten koncept powiela, już bez zastanowienia o co autorowi chodziło.

Weź sobie funkcję std::sort. Ma trzy argumenty, trzeci to właśnie callback komparatora (zwany w kręgach zbliżonych do akademickich "predykatem"). Otwórz sobie header "algorithm" ze swojego kompilatora i poszukaj tam co robi funkcja std::sort ze swoim trzecim argumentem (czyli "inputem", jak to nazywasz).

Sprawdza, czy programista nie podał pustego wskaźnika/funktora/itp.?

Tak więc biblioteka HTTP jest właśnie w takim towarzystwie (przynajmniej w tej konkretnej kwestii...).

> > Od kiedy to biblioteki HTTP służą do weryfikacji programów?
> 
> W każdym inpucie powinna być weryfikacja,

To nie jest input, tylko część programu. Inputem jest URL z przeglądarki albo dane z formatki w POST. I *to* należy walidować.

> ponieważ *ułatwia* to 
> debugowanie klientowi.

Debugowanie ułatwia fakt, że gdybyś faktycznie spróbował zrobić taki błąd w tej bibliotece, zamiast trollować na rympał, to byś zobaczył, że std::function rzuca wtedy wyjątek, który biblioteka uczciwie wypisuje na podanym strumieniu do logowania błędów.
Spróbuj.

To programowanie defensywne, podobnie jak paranoja wokół unit testów, to niestety efekt braku refleksji nad własnym warsztatem.

> > Targetem są świadomi inżynierowie, którzy nie oczekują od biblioteki HTTP, że im zrobi weryfikację poprawności programu...
> 
> Chyba takich jest relatywnie mało. Sądzepo ilości assertów w poważnych 
> biblitekach.

No to ile assertów znalazłeś w std::sort na trzecim argumencie?
Ja sprawdziłem w bibliotekach standardowych z trzech różnych kompilatorów.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#34001

On 09/06/2020 22:43, Maciej Sobczak wrote:
>> Programowania defensywnego na inpucie.
> Rzucam tezą, że ktoś z dobrą intencją ulepił koncept a cała masa ludzi ten koncept powiela, już bez zastanowienia o co autorowi chodziło.
> Weź sobie funkcję std::sort. Ma trzy argumenty, trzeci to właśnie callback komparatora (zwany w kręgach zbliżonych do akademickich "predykatem"). Otwórz sobie header "algorithm" ze swojego kompilatora i poszukaj tam co robi funkcja std::sort ze swoim trzecim argumentem (czyli "inputem", jak to nazywasz).
> Sprawdza, czy programista nie podał pustego wskaźnika/funktora/itp.?

Teraz weź dowolny nagłówek z Qt i poszukaj sobie Q_ASSERT. Niezłe 
głupki, nie? Kto by traciła na to czas, Paaaanie...

> Tak więc biblioteka HTTP jest właśnie w takim towarzystwie (przynajmniej w tej konkretnej kwestii...).

No ale to kiepskie towarzystwo. Co by o std:: nie mówić, jakościowo to 
jest takie sobie, że nie wspomnę już że ma co najmniej kilka implementacji.

>>> Od kiedy to biblioteki HTTP służą do weryfikacji programów?
>> W każdym inpucie powinna być weryfikacja,
> To nie jest input, tylko część programu. Inputem jest URL z przeglądarki albo dane z formatki w POST. I *to* należy walidować.

Więc mamy różne pojęcie o inpucie. Jako klient bibliteki widzę to 
inaczej, nic nie poradzę.

>> ponieważ *ułatwia* to
>> debugowanie klientowi.
> Debugowanie ułatwia fakt, że gdybyś faktycznie spróbował zrobić taki błąd w tej bibliotece, zamiast trollować na rympał, to byś zobaczył, że std::function rzuca wtedy wyjątek, który biblioteka uczciwie wypisuje na podanym strumieniu do logowania błędów.

Exceptions to nie asercje. Nie służa do tego samego. Narzekanie jest na 
asercje a raczej ich brak. Asercje to rodzaj dokumentacji dla klienta. 
Przydają się w debugu. Nic nie kosztują w runtime. Gdzie są wady które 
powodują że nie warto?

> To programowanie defensywne, podobnie jak paranoja wokół unit testów, to niestety efekt braku refleksji nad własnym warsztatem.

Paranoja wokół unit testów oznacza po drugiej stronie luzacki kod bez 
śladu testowania. Rozsądek nakazuje być gdzieś w środku, specyfikacja 
nakazuje czasem mieć prawie 100% pokrycia. Trudno tu doszukiwac się 
refleksji, choć często muszę stopować młodych gniewnych którym wszystko 
zawsze wychodzi dobrze od razu, tylko troche nie działa. Jednak pisanie 
unit testów czasem się przydaje. Jak coś zapraszam do mnie, sam zobaczysz.

>>> Targetem są świadomi inżynierowie, którzy nie oczekują od biblioteki HTTP, że im zrobi weryfikację poprawności programu...
>> Chyba takich jest relatywnie mało. Sądzepo ilości assertów w poważnych
>> biblitekach.
> No to ile assertów znalazłeś w std::sort na trzecim argumencie?

Trudno nazwać std:: poważną bibliteką pod kątem jakości. Obserwowałem 
kiedyś rozwój stlport i muszę przyznać że podejście z gatunku "chyba 
dobrze, komituj na produkcję" dało mi dużo do myślenia i zmianę własnego 
warsztatu ze zwrotem przeciwnym.

> Ja sprawdziłem w bibliotekach standardowych z trzech różnych kompilatorów.

To sprawdź jeszcze resztę świata. Zacznij od Qt. Spodoba Ci się, tam 
pracują sami nadprzyrodzeni hackerzy którzy mają reglamentowane asserty. 
Ale i tak można ich tam troszkę znaleźć. Widocznie ktoś stwierdził że 
czasem warto pilnować czy coś nie jest nullem, nawet jeśli klient tej 
biblioteki jest nadprzyrodzonym superkoderem z kontraktem i +10 do 
szczęścia.

[toc] | [prev] | [next] | [standalone]

#34008

> > Weź sobie funkcję std::sort.

> Teraz weź dowolny nagłówek z Qt

Nie używam.

> Niezłe 
> głupki, nie?

Nie. To ich wybór. Ja wybrałem tak jak autorzy std::sort.

> No ale to kiepskie towarzystwo. Co by o std:: nie mówić, jakościowo to 
> jest takie sobie,

Tak, teraz musisz się koniecznie wytrollować z tej retorycznej dziury, do której się sam wtrollowałeś.

> że nie wspomnę już że ma co najmniej kilka implementacji.

Podobnie jak standard POSIX. Też ma kilka implementacji.

Skoro jest wiele implementacji biblioteki standardowej i wszystkie mają podobne zdanie na ten sam temat (pomimo naturalnej konkurencji pomiędzy nimi), to można to zdanie nazwać jakimś konsensusem w danym temacie.
W przypadku jednej biblioteki (np. Qt) można to nazwać opinią.

> Asercje to rodzaj dokumentacji dla klienta. 

Nie. Dla klienta jest header. Jak się autor postara, to dokumentacja też tam jest. Ale przede wszystkim dla klienta jest header.

Asercje jako kontrakt są do bani właśnie przez to, że nie ma ich w headerze.

> Przydają się w debugu. Nic nie kosztują w runtime. Gdzie są wady które 
> powodują że nie warto?

Nie rozwiązują problemu, jakim jest niewłaściwa użyta funkcja i dają fałszywe poczucie bezpieczeństwa. O, fajnie, asserty przeszły, jest OK. A tu klops.

Uwaga: asserty są fajne *na końcu* funkcji - jako sanity-check, czy funkcja zrobiła to co miała zrobić.
Własnie dlatego, że są w implementacji, a nie w headerze.

> Trudno nazwać std:: poważną bibliteką pod kątem jakości.

Rozumiem.

> > Ja sprawdziłem w bibliotekach standardowych z trzech różnych kompilatorów.
> 
> To sprawdź jeszcze resztę świata.

A co będzie, jak znowu trafię na bibliotekę, która nie sprawdza?

> Zacznij od Qt.

Zacząłem od trzech różnych implementacji std.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#34011

On 6/10/2020 9:13 PM, Maciej Sobczak wrote:
>> To sprawdź jeszcze resztę świata.
> A co będzie, jak znowu trafię na bibliotekę, która nie sprawdza?

To będziesz miał powód watpić czy Twoje rozwiązanie, i kolegow z std::, 
jest prawidłowe. Skoro reszta świata w jakimś procencie uzywa. 
Oczywiście to wszystko moga byc idioci, wiadomo.

[toc] | [prev] | [next] | [standalone]

#34009

> > Ja sprawdziłem w bibliotekach standardowych z trzech różnych kompilatorów.
> 
> To sprawdź jeszcze resztę świata. Zacznij od Qt.

A co mi tam. Sprawdziłem. Zacząłem od Qt.

https://github.com/qt/qtbase/blob/dev/src/corelib/tools/qalgorithms.h

Konkretnie, funkcja qSort z callbackiem komparatora jest tutaj:

https://github.com/qt/qtbase/blob/dev/src/corelib/tools/qalgorithms.h#L181

i bez walidowania swoich argumentów woła qSortHelper, który jest tutaj:

https://github.com/qt/qtbase/blob/dev/src/corelib/tools/qalgorithms.h#L340

i który bez walidowania swoich argumentów wywołuje callback tutaj:

https://github.com/qt/qtbase/blob/dev/src/corelib/tools/qalgorithms.h#L351

> Spodoba Ci się

Bez szału. Tzn. walidację callbacków robią poprawnie - w sensie że nie robią. O, to w sumie podobnie jak w bibliotece standardowej. Konsensus w tej sprawie się przez to poszerzył o kolejną zgodną opinię.

Natomiast ogólne wrażenie - jak na bibliotekę, która miała rzekomo inspirować jakością, nie urywa.
Przykładowo, w jednym miejscu (w qSortHelper, 343) jest tak:

    int span = int(end - start);

a w innym (w qStableSortHelper, 452) tak:

    const int span = end - begin;

Dziwne, nie? I niekonsekwencja w nazwach iteratorów albo w użyciu const w dokładnie takim samym idiomie, to akurat najmniejszy pikuś.
Ćwiczenie: czy wartość (end - start) zawsze mieści się w int?

Co się stanie, jeśli się nie zmieści? Jak to wpłynie na następne dwie linijki:

    if (span < 2)
        return;

?

Dalej: oszczędzanie na nawiasach klamrowych, niekonsekwentne ich stosowanie, albo raz się namespace kończy komentarzem, innym razem bez komentarza. To tak na szybko.

Nie twierdze, że bardzo źle. W kategorii open-source na pewno powyżej średniej.

Ale nie o to chodzi. Chodzi o to, że strasznie jestem ciekaw, jaki argument teraz wymyślisz.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#34012

On 6/10/2020 10:35 PM, Maciej Sobczak wrote:
> Ale nie o to chodzi. Chodzi o to, że strasznie jestem ciekaw, jaki argument teraz wymyślisz.

Żaden. Z płaskoziemcami tez mi się cieżko rozmawia i w sumie to mało 
konstruktywne. Ponadto EOT to EOT. Ziew.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | pl.comp.programming

csiph-web