The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Реализация FastCGI на современном C++"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Реализация FastCGI на современном C++"  +/
Сообщение от opennews (??), 17-Май-19, 12:58 
Доступна (https://github.com/dmitigr/fcgi) новая реализация протокола FastCGI (https://en.wikipedia.org/wiki/FastCGI), написанная на современном C++17. Библиотека примечательна  простотой в использовании и высокой производительностью. Возможно использование как статически и динамически  связанной библиотеки, так и  встраиванием в приложение в форме заголовочного файла. Кроме Unix-подобных систем обеспечена поддержка использования в Windows. Код поставляется под свободной лицензией zlib.

URL: https://github.com/dmitigr/fcgi
Новость: https://www.opennet.ru/opennews/art.shtml?num=50699

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 17-Май-19, 12:58   +3 +/
а чо, текущая реализация непростая и медленная?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #5, #15, #36

2. Сообщение от Аноннн (?), 17-Май-19, 12:58   –15 +/
fastcgi в 2к19 легаси

даже бусты уже в http умеют

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #7, #9, #37, #41, #53

3. Сообщение от A.Stahl (ok), 17-Май-19, 13:00   +13 +/
В тексте новости нет сравнения сложности и производительности, есть лишь утверждение что библиотека проста и производительна, поэтому твой вопрос не логичен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #38

4. Сообщение от Аноним (4), 17-Май-19, 13:03   +2 +/
ну и пользуйте комбайны. а кому-то юникс-вей по душе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #128

5. Сообщение от Аноним (5), 17-Май-19, 13:07   –1 +/
Зато эта для тех, кто крутит спинеры, деньги хранит в биткоинах, курит вейп, каждую неделю посещает барбершоп, пьёт исключительно смузи и по улице передвигается только на гироскутере. Короче не может жить без всего нового и бесполезного.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #6

6. Сообщение от Попугай Кеша (?), 17-Май-19, 13:13   +5 +/
Гироскутеры уже не в моде! Моноколеса!
Смузи в прошлом, сейчас вегги-детокс-шейки!
Биткоин не в моде - даешь БузКоин!
Спиннеры не в моде - сейчас просто с бородой ходят аки дедушки!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #21

7. Сообщение от kai3341 (ok), 17-Май-19, 13:20   +7 +/
> fastcgi в 2к19 легаси
> даже бусты уже в http умеют

Как закончишь делать уроки, разберись в этой статье: https://ru.wikipedia.org/wiki/FastCGI
И впредь не торопись хоронить nginx unit

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #129

8. Сообщение от Аноним (8), 17-Май-19, 13:22   +/
> через встраивание в приложение в форме заголовочного файла

Некорректная формулировка.

Ответить | Правка | Наверх | Cообщить модератору

9. Сообщение от Аноним (9), 17-Май-19, 13:23   –7 +/
Видимо кому-то все еще нужно поддерживать древнее барахло, а начав установку, оно потянуло в зависимостях еще более древнее барахло. Вот и написал сервер на скорую руку без каких-либо зависимостей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #141

10. Сообщение от Аноним (10), 17-Май-19, 13:23   +3 +/
Мдя, 2019 год, свежий стандарт плюсов, а поделка уровня студента: зависимость от какой-то левой библиотеки, простыня инструкций по сборке,  кода helloworld на целый экран (про MT вообще молчу, руками потоки надо делать)...

Для сравнения, код 4-х летней давности на ржавчине (не для сравнения языков!! на плюсах можно сделать не хуже), просто удобство, краткость, лаконичность:
https://docs.rs/fastcgi/1.0.0/fastcgi/

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13, #120

11. Сообщение от X4asd (ok), 17-Май-19, 13:30   +3 +/
не могу понять -- а где тут выход из цикла?


      while (true) {
        const auto conn = server->accept();
        conn->out() << "Content-Type: text/plain" << crlfcrlf;
        conn->out() << "Hello from dmitigr::fcgi!" << crlf;
        conn->close(); // Optional.
      }

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #17, #18, #61

13. Сообщение от Rustanalz (?), 17-Май-19, 13:38   +8 +/
Уродский синтаксис у раста...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

14. Сообщение от Аноним (14), 17-Май-19, 13:47   +7 +/
Что-то я не понимаю. Почему какая-то поделка ноунейма выкладывается на opennet? Проплачено или что?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #20, #56, #116

15. Сообщение от Andrey Mitrofanov (?), 17-Май-19, 13:51   +/
> а чо, текущая реализация непростая и медленная?

Конечно.  Модулем ядра и на ассемблере - всяко быстрее.

И руками смержить с дырвером сетевой.

Точно быстрее.  Без шуток.  Было в Новостях Опеннета.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #97

16. Сообщение от Аноним (16), 17-Май-19, 13:52   –1 +/
Автор, начни с чтения вот этого https://stackoverflow.com/questions/213907/c-stdendl-vs-n что ли (это я мягко так намекаю про "нужность" дефайнов с crlf).
Да и вообще код действительно выглядит как поделка, а использование С++17 в описании - лишь как маркетинговая уловка.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #25, #40, #63, #76

17. Сообщение от СеменСеменыч777 (?), 17-Май-19, 13:52   +/
> а где тут выход из цикла?

выбирайте:
1) выхода нет, эта музыка будет вечной;
2) выход по SIGINT/SIGKILL

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #30

18. Сообщение от Andrey Mitrofanov (?), 17-Май-19, 13:53   +2 +/
> не могу понять -- а где тут выход из цикла?
>code]
>       while (true) {

Та, вот же ОН! --->>>  ^C

Как маленький прям.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #34

19. Сообщение от mumu (ok), 17-Май-19, 13:55   –2 +/
Указатели все разыменовали? За границы буферов не повыходили? Или как обычно?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #26, #78, #110

20. Сообщение от Andrey Mitrofanov (?), 17-Май-19, 13:55   +1 +/
> Что-то я не понимаю. Почему какая-то поделка ноунейма выкладывается на opennet? Проплачено
> или что?

Конечно.

"Оригинальные новостные статьи"(тм)  оплачены щедрыми донорами.

Сбор донатов на опеннете -- видел, да?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #23

21. Сообщение от Аноним (21), 17-Май-19, 14:03   –6 +/
> сейчас просто с бородой ходят аки дедушки!

Аки девушки, ты хотел сказать...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #33

22. Сообщение от тоже Анонимemail (ok), 17-Май-19, 14:07   +3 +/
Я таки ничего не знаю за автора этого кода, но на своем персональном сайте он называет себя исключительно "мы". Несколько настораживает...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #28, #66

23. Сообщение от Аноним (8), 17-Май-19, 14:07   +/
Так вон они, ниже в конце страницы :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #24

24. Сообщение от Andrey Mitrofanov (?), 17-Май-19, 14:12   +1 +/
#>>Сбор донатов на опеннете -- видел, да?
> Так вон они, ниже в конце страницы :)

Эти - не те.  Не видел, значит.  Окэ.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

25. Сообщение от пох (?), 17-Май-19, 14:15   –3 +/
просто обезьяныш не умеет не обмазываться свеженьким, и c++17 в описании означает не какие-то там достоинства кода, а просто то, что ничем кроме пре-альфа-версии gcc99 это не собирается.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

26. Сообщение от Andrey Mitrofanov (?), 17-Май-19, 14:15   +/
> Указатели все разыменовали? За границы буферов не повыходили? Или как обычно?

Надо больше замыканий, монадов, строгой типизации и W^X на опенне ^W Microsoft Github-е!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #200

27. Сообщение от Аноним (27), 17-Май-19, 14:18   –3 +/
С официального сайта: "Нам нравится творить".
Вот такие натворят, а потом другим расхлёбывать приходится. За счёт бизнеса (которая платит дважды или даже трижды).
Ответить | Правка | Наверх | Cообщить модератору

28. Сообщение от Andrey Mitrofanov (?), 17-Май-19, 14:19   +/
> Я таки ничего не знаю за автора этого кода, но на своем
> персональном сайте он называет себя исключительно "мы". Несколько настораживает...

Может, его кот по клавиатуре прогуливался.  Мы B-P ж не знаем.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

29. Сообщение от fgi (?), 17-Май-19, 14:30   +1 +/
неюзабельно
уровня студента
давайте побольше ваших сладких булочек
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #43

30. Сообщение от X4asd (ok), 17-Май-19, 14:34   +/
как тогда понимать --


    for (auto& t : threads)
      t.join();

    server->close(); // Optional.

в какой момент код доходит до "server->close();" ?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #31, #187

31. Сообщение от Andrey Mitrofanov (?), 17-Май-19, 14:47   –1 +/
> как тогда понимать --

Брысь учить C++$((N++)).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

33. Сообщение от омномномним (?), 17-Май-19, 15:10   +6 +/
стрёмные у тебя девушки
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #39

34. Сообщение от Аноним (34), 17-Май-19, 15:12   +1 +/
SIGTERM не остановит эту программу, SIGKILL нужен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #65, #71

35. Сообщение от Ilya Indigo (ok), 17-Май-19, 15:30   –2 +/
Это будет иметь отношение к mod_fcgid для Apache?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #80

36. Сообщение от петькаваська (?), 17-Май-19, 15:31   +4 +/
О какой "текущей реализации" речь? Если об официальной сишной библиотеке, то она уже давно как не поддерживается. Даже сайт fastcgi.com уже давно не доступен. Так что эта либа вполне себе свежак!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

37. Сообщение от петькаваська (?), 17-Май-19, 15:34   –2 +/
Бусты в HTTP. Лол. Вы когда-нибудь пробовали Boost.Beast? Ну и как оно? Всё просто, не правда ли?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #147

38. Сообщение от test_test (?), 17-Май-19, 15:40   +/
Как и сами утверждения в новости, не?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #58

39. Сообщение от Аноним (39), 17-Май-19, 15:47   +1 +/
Зато с медалями.

http://susepaste.org/images/46871963.jpg

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #49

40. Сообщение от петькаваська (?), 17-Май-19, 15:48   +4 +/
> Автор, начни с чтения вот этого https://stackoverflow.com/questions/213907/c-stdendl-vs-n
> что ли (это я мягко так намекаю про "нужность" дефайнов с
> crlf).
> Да и вообще код действительно выглядит как поделка, а использование С++17 в
> описании - лишь как маркетинговая уловка.

Этими дефайнами автор хочет, вероятно, привести код в соответствии протоколу HTTP, в котором перевод строки строго определён как "\r\n". Так что мат. часть, вероятно, надо учить как раз Вам.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #60, #88, #113

41. Сообщение от Аноним (39), 17-Май-19, 15:50   –1 +/
fastcgi в 2190?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #42

42. Сообщение от петькаваська (?), 17-Май-19, 15:53   +1 +/
Почему бы и нет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #50

43. Сообщение от мимопроходил (?), 17-Май-19, 16:05   +/
В каком месте там неюзабельно и в каком месте уровень студента. А то это уже не первый комментарий подобный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

44. Сообщение от НяшМяш (ok), 17-Май-19, 16:07   +4 +/
Вот взъелись вы на дядьку. А он может работу ищет. Сейчас на каждом собеседовании второй вопрос это "есть ли у вас открытые проекты на гитхабе". Поэтому надо выложить хоть что-нибудь, чтобы иметь какой-то вес на собесе.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #47, #81

45. Сообщение от Аноним (39), 17-Май-19, 16:10   +2 +/
> DMITIGR_ASSERT((content_len <= max_content_length) && (padding_len <= max_padding_length));

Определение макроса в предлагаемой библиотеке отсутствует. Находится оно в другом месте. Вот такое:


#define DMITIGR_ASSERT__(a, t) {                                        \
    if (!(a)) {                                                         \
      DMITIGR_DOUT__("assertion (%s) failed\n", #a)                     \
      if constexpr (t)                                                  \
        throw std::logic_error{"assertion (" #a ") failed at " __FILE__ ":" DMITIGR_XSTRINGIZED(__LINE__)}; \
    }                                                                   \
}

Кто-то может объяснить смысл?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #46

46. Сообщение от Аноним (51), 17-Май-19, 16:13   –1 +/
Может быть какая-то либа-зависимость не установлена?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #72

47. Сообщение от Аноним (51), 17-Май-19, 16:19   +/
Это классика. 5 стадий принятия неизбежного: отрицание, гнев, торг, депрессия, принятие. Сейчас где-то фаза 1 или 2. Потом полегчает :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

48. Сообщение от Аноним (48), 17-Май-19, 16:27   +/
FastCGI настолько простой протокол что только ленивый студент не реализовывал его на своем любимом языке
Ответить | Правка | Наверх | Cообщить модератору

49. Сообщение от Аноним (49), 17-Май-19, 16:37   –2 +/
Вот такие https://ru.wikipedia.org/wiki/Кончита_Вурст#/media/File:Conchita_Wurst_-_London_Book_Fair_2015_(17131432956).jpg
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #84

50. Сообщение от Аноним (50), 17-Май-19, 16:38   –1 +/
В 2190 Ом? O.o
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #51, #79, #196

51. Сообщение от Аноним (51), 17-Май-19, 16:39   +/
Ну а чо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #59

52. Сообщение от Аноним (50), 17-Май-19, 16:40   +1 +/
In file included from /home/dmitry/tmp/fcgi/lib/dmitigr/fcgi/basics.hpp:62,
                 from /home/dmitry/tmp/fcgi/lib/dmitigr/fcgi.hpp:26,
                 from /home/dmitry/tmp/fcgi/lib/dmitigr/fcgi.cpp:7:
/home/dmitry/tmp/fcgi/lib/dmitigr/fcgi/basics.cpp:9:10: fatal error: dmitigr/common/debug.hpp: Нет такого файла или каталога
#include <dmitigr/common/debug.hpp>
          ^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

Автор, ну ты понел.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #57

53. Сообщение от Anonymoustus (ok), 17-Май-19, 16:45   +10 +/
> 2к19

Чтоб тебе доктор рецепты и справки на такие даты выписывал, а бухгалтерия — зарплатную ведомость.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

54. Сообщение от Аноним (57), 17-Май-19, 16:50   +11 +/
Список новостей:
- Microsoft открыл код библиотеки векторного поиска, используемой в Bing
- Дима Игришин сделал git push
- Фонд свободного ПО сертифицировал звуковые карты и WiFi-адаптеры ThinkPenguin
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #124

55. Сообщение от Anonymoussemail (?), 17-Май-19, 16:55   +/
Судя по коду это fcgi, а не fastcgi. какой смысл тогда?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #87

56. Сообщение от Аноним (49), 17-Май-19, 17:00   –1 +/
>Почему какая-то поделка ноунейма выкладывается на opennet?

Потому, что open source?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

57. Сообщение от Аноним (57), 17-Май-19, 17:08   +/
пишут что нужно `common` имени дмитрия ингишина иметь:
https://github.com/dmitigr/fcgi/blob/master/README.md#depend...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #62

58. Сообщение от Sw00p aka Jerom (?), 17-Май-19, 17:11   +/
и бенчмарков примитивных не вижу
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

59. Сообщение от Sw00p aka Jerom (?), 17-Май-19, 17:13   +/
grpc не?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

60. Сообщение от Аноним (49), 17-Май-19, 17:14   +1 +/
Что подвигло Тима Бернерса-Ли выбрать для перевода строки \r\n, он же ползовался NIX-like ОС?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #67, #70

61. Сообщение от Sw00p aka Jerom (?), 17-Май-19, 17:18   +/
это же обработка соединения со стороны сервера, без цикла не принял бы другое соединение.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #64

62. Сообщение от Аноним (50), 17-Май-19, 17:27   +1 +/
То есть он даже поиск библиотеки в cmake не осилил? Молодец какой. Дальше смотреть не вижу смысла.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #86

63. Сообщение от Ordu (ok), 17-Май-19, 17:27   +2 +/
> начни с чтения вот этого https://stackoverflow.com/questions/213907/c-stdendl-vs-n

И что он там должен увидеть? Может быть это:

> There's another function call implied in there if you're going to use std::endl
> a) std::cout << "Hello\n";
> b) std::cout << "Hello" << std::endl;
> a) calls operator << once.
> b) calls operator << twice.

?

endl -- это принудительный flush и зависимость перевода строки от платформы под которую собирался код. Зачем это нужно? Сетевые протоколы чётко фиксируют, что используется для терминации строки, и если там написано "\r\n", то тебе даже в unix'е придётся использовать "\r\n".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #68

64. Сообщение от X4asd (ok), 17-Май-19, 17:28   +/
> без цикла не принял бы другое соединение.

без бесконечного цикла который никогда не прерывается? :-)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #75, #83, #85

65. Сообщение от X4asd (ok), 17-Май-19, 17:29   +/
> SIGKILL нужен.

ну а ещё  можно зайти в gdb, зааттачить и оттуда


call close(номер)

очень удобно (sarcasm)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

66. Сообщение от Аноним (50), 17-Май-19, 17:29   +1 +/
Предлагаю скинуться и выслать ему пачку декариса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

67. Сообщение от Ordu (ok), 17-Май-19, 17:30   +1 +/
Я могу предположить. Использование "\r\n" в качестве разделителя строк протокола позволяет в одну строку протокола впихнуть многострочный файл со "\n" в качестве разделителя строк. Но это лишь предположение, реально я не знаю как дело было, просто ты задал вопрос, я задумался над этим, и мне пришёл в голову такой вот возможный ответ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

68. Сообщение от udro (?), 17-Май-19, 17:33   –2 +/
> зависимость перевода строки от платформы

нет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #73

70. Сообщение от Аноним (50), 17-Май-19, 17:34   +2 +/
> Что подвигло Тима Бернерса-Ли выбрать для перевода строки \r\n, он же ползовался NIX-like ОС?

А он и не выбирал. Он просто передрал RFC822.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #77

71. Сообщение от ноунейм (?), 17-Май-19, 17:37   +3 +/
> SIGTERM не остановит эту программу, SIGKILL нужен.

Во-первых, ^C — это SIGINT. Во-вторых почему не остановит? Там где-то обработчики переопределяются?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

72. Сообщение от Аноним (39), 17-Май-19, 17:43   +1 +/
> Может быть какая-то либа-зависимость не установлена?

Если я нашёл определение, значит нашёл и либу (того же автора).

Вопрос по сементике самого макроса.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #82

73. Сообщение от Ordu (ok), 17-Май-19, 17:45   +/
В смысле? Он не выводит "\r\n" в венде? А зачем тогда он нужен такой? Ну вот вообще зачем было заморачиваться добавлять в библиотеку endl, если "\n" нагляднее?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #74

74. Сообщение от udro (?), 17-Май-19, 18:00   –2 +/
В одном клике от твоей ссылки: https://en.cppreference.com/w/cpp/io/manip/endl
> Inserts a newline character into the output sequence os and flushes it as if by calling os.put(os.widen('\n')) followed by os.flush().
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #93

75. Сообщение от Sw00p aka Jerom (?), 17-Май-19, 18:02   –2 +/
> без бесконечного цикла который никогда не прерывается? :-)

А вы заранее знаете сколько соединений вы обработаете? На то и серверное сетевое приложение, которое работает фактически вечно для обслуживания запросов. У вас какая-то другая точка зрения как это реализовать? А выход из цикла - равносилен либо аварийному выходу (try catch), либо по сигналу.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #115

76. Сообщение от dmitigr (ok), 17-Май-19, 18:04   +1 +/
> Автор, начни с чтения вот этого https://stackoverflow.com/questions/213907/c-stdendl-vs-n что ли

Здесь автор. Мне не нужно это читать.

> (это я мягко так намекаю про "нужность" дефайнов с crlf).

Эти дефайны обеспечивают кроссплатформенность кода.

> Да и вообще код действительно выглядит как поделка, а использование С++17 в описании - лишь как маркетинговая уловка.

Это именно поделка, которой я любезно поделился с сообществом. Кому не нравится, тот просто обходит стороной.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #98

77. Сообщение от Аноним (50), 17-Май-19, 18:04   +2 +/
Ну то есть не передрал, а сослался, конечно.
https://tools.ietf.org/html/rfc2068#section-4.1
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

78. Сообщение от dmitigr (ok), 17-Май-19, 18:05   +1 +/
Не стоит беспокоится. Все разыменовали и за границы не повыходили. Будут проблемы - обращайтесь. Как обычно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

79. Сообщение от Аноним (39), 17-Май-19, 18:06   –4 +/
> В 2190 Ом? O.o

Все вопросы к начавшему ветку, 2к19 это 2190.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #188

80. Сообщение от dmitigr (ok), 17-Май-19, 18:07   +/
Нет. Никакого отношения к mod_fcgid обсуждаемая библиотека не имеет. Вы можете использовать mod_proxy_fcgi для проксирования HTTP-запросов приложению на базе dmitigr_fcgi.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

81. Сообщение от dmitigr (ok), 17-Май-19, 18:08   +/
Спасибо за беспокойство! Работу я не ищу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

82. Сообщение от dmitigr (ok), 17-Май-19, 18:09   –1 +/
> Вопрос по сементике самого макроса.

Что конкретно Вам не ясно?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #104

83. Сообщение от Sw00p aka Jerom (?), 17-Май-19, 18:14   –2 +/
с пруфами лучше, вот ссылка на fastcgi в пхп

https://github.com/php/php-src/blob/master/main/fastcgi.c

В строке 1370

int fcgi_accept_request(fcgi_request *req)
{
#ifdef _WIN32
    HANDLE pipe;
    OVERLAPPED ov;
#endif

    while (1) {
        if (req->fd < 0) {
            while (1) {
                if (in_shutdown) {
                    return -1;
}

и видим там кучу условий выхода при не штатных ситуациях, но мы забыли отметить, что это язык Си, а не плюсы в которых данный код обернут в try-cacth, ну и может где-то там есть обработка сигналов.

while (true) {
        const auto conn = server->accept();
        conn->out() << "Content-Type: text/plain" << crlfcrlf;
        conn->out() << "Hello from dmitigr::fcgi!" << crlf;
        conn->close(); // Optional.
      }

При любой нештатной ситуации, цикл отрубится.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

84. Сообщение от asdasd (?), 17-Май-19, 18:16   +1 +/
Так то не девушка, то п*р.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

85. Сообщение от Sw00p aka Jerom (?), 17-Май-19, 18:17   –2 +/
https://github.com/dmitigr/fcgi/blob/master/lib/dmitigr/fcgi...

Строка 153, и смотрим при каких условиях прервется ваш цикл.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

86. Сообщение от dmitigr (ok), 17-Май-19, 18:21   –1 +/
Кто-то не осилил прочитать документацию. Дальше смотреть нет смысла.

В действительности, всё что требуется, это установить библиотеку dmitigr_common. Всё остальное CMake сделает автоматически.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #90

87. Сообщение от dmitigr (ok), 17-Май-19, 18:22   +/
Это реализация FastCGI. FCGI - это сокращение FastCGI.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #99, #105

88. Сообщение от dmitigr (ok), 17-Май-19, 18:26   +1 +/
Совершенно верно. operator<< - это оператор форматированного вывода. Вызов ostream << "\n" записывает в поток "\r\n" в Windows и "\n" в Unix. Протокол HTTP предписывает использование "\r\n" в качестве разделительной последовательности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

90. Сообщение от Аноним (50), 17-Май-19, 19:01   +1 +/
Установить куда? А если я её в нестандартный префикс хочу, чтобы систему не поганить? CMake должен делать автоматически не «всё остальное», но и поиск библиотеки тоже. Если её нет — вывести внятное сообщение об ошибке. А тут конфигурация типа прошла успешно, а оказывается — зависимостей не хватает!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #91

91. Сообщение от dmitigr (ok), 17-Май-19, 19:09   +/
Спасибо за отзыв. CMake ищет библиотеку автоматически. Я только что попробовал сконфигурировать dmitigr_fcgi без установленного dmitigr_common. Вот реакция CMake:

Building of shared library is enabled.
Build type is Debug
Building of tests is enabled
-- Could NOT find dmitigr_common (missing: dmitigr_common_DIR)
-- Could NOT find dmitigr_common (missing: dmitigr_common_DIR)
CMake Warning at cmake/dmitigr_package_finder.cmake:31 (find_package):
  By not providing "Finddmitigr_common.cmake" in CMAKE_MODULE_PATH this
  project has asked CMake to find a package configuration file provided by
  "dmitigr_common", but CMake did not find one.

  Could not find a package configuration file provided by "dmitigr_common"
  with any of the following names:

    dmitigr_commonConfig.cmake
    dmitigr_common-config.cmake

  Add the installation prefix of "dmitigr_common" to CMAKE_PREFIX_PATH or set
  "dmitigr_common_DIR" to a directory containing one of the above files.  If
  "dmitigr_common" provides a separate development package or SDK, be sure it
  has been installed.
Call Stack (most recent call first):
  cmake/FindCommon.cmake:21 (include)
  CMakeLists.txt:189 (find_package)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #96

92. Сообщение от eRIC (ok), 17-Май-19, 19:09   +3 +/
Многие тут комментаторы от Бога так и не понимают в чем изюминка этой реализации FastCGI, дело в " написанная на современном C++17" - "The FastCGI implementation on modern C++".

Делая выводы можно сказать что она как алтернативная реализация по спецификации FastCGI придаст прирост в производительности, легкости и т.д., что позволяет дать современные последние версии компиляторы c поддержкой C++17 (ведь язык программирования C++ тоже не стоит на месте и совершенствуется)

P.S: кстати, если кто-то будет искать закрытый сайт FastCGI, можете посмотреть в архиве: https://fastcgi-archives.github.io/

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #94, #100, #101, #114, #190

93. Сообщение от Ordu (ok), 17-Май-19, 19:14   +/
> В одном клике от твоей ссылки: https://en.cppreference.com/w/cpp/io/manip/endl
>> Inserts a newline character into the output sequence os and flushes it as if by calling os.put(os.widen('\n')) followed by os.flush().

Что такое os.widen? Что он там расширяет? Не расширяет ли он заодно '\n' до \r\n, когда нужно?

Но даже если ты прав, то это не ответ на вопрос: зачем было вообще добавлять в C++ endl? Какой смысл им пользоваться, если он не даёт ровным счётом ничего? Ради flush? Не проще ли как в C всунуть flush в поток, чтобы он триггерился выводом перевода строки? Или добавить манипулятор потока, который выводит ничего, но выполняет flush -- таким образом не придётся отдельно вызывать метод, что может делать код менее функциональным (в смысле functional programming). О чём думали дизайнеры iostream когда запиливали endl в библиотеку?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #143

94. Сообщение от Ordu (ok), 17-Май-19, 19:20   +/
> Многие тут комментаторы от Бога так и не понимают в чем изюминка

Многие комментаторы здесь делают сознательные усилия, чтобы не понимать. Всё комментирование здесь сводится к специальной олимпиаде на тему, кто самым возмутительным образом не поймёт, что написано.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #95

95. Сообщение от eRIC (ok), 17-Май-19, 19:21   +1 +/
> Многие комментаторы здесь делают сознательные усилия, чтобы не понимать. Всё комментирование
> здесь сводится к специальной олимпиаде на тему, кто самым возмутительным образом
> не поймёт, что написано.

особенно (A|O)нонимы :)


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

96. Сообщение от Аноним (50), 17-Май-19, 19:23   +2 +/
Действительно, сообщение есть, я его не заметил. Но это всего лишь warning, статус завершения 0, Makefile создался, в конце:

Using  library
-- Configuring done
-- Generating done
-- Build files have been written to: /home/anon/fcgi/build

Потому выше по логу и не смотрел. Должно быть завершение с ошибкой, если зависимость обязательная.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #118

97. Сообщение от Аноним (97), 17-Май-19, 19:24   +3 +/
А если на FPGA реализовать всю логику сайта + http + tcp/ip?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

98. Сообщение от Sw00p aka Jerom (?), 17-Май-19, 19:35   +/
О круть, сам автор тут)

Хотелось бы одно замечание сделать

"namespace dmitigr"

простите, но что за "неймдроппинг" такой? как то не серьезно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #107

99. Сообщение от eRIC (ok), 17-Май-19, 19:36   +2 +/
dmitigr, бенчмарки вашей реализации есть для сравнения?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #109

100. Сообщение от Sw00p aka Jerom (?), 17-Май-19, 19:40   –1 +/
> как алтернативная реализация спецификации FastCGI

Кхммм, спецификации? вы серьезно? Альтернативная реализация ---> по <--- спецификации FastCGI!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #102

101. Сообщение от Аноним (50), 17-Май-19, 19:44   +/
> Делая выводы можно сказать что она как алтернативная реализация спецификации FastCGI придаст прирост в производительности, легкости и т.д.

Из чего и каким образом можно сделать такие выводы?

> усоверешенствовыется

Ты б свой русский посвершенствовывал, что ли.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #103, #112

102. Сообщение от eRIC (ok), 17-Май-19, 19:45   +1 +/
> Кхммм, спецификации? вы серьезно? Альтернативная реализация ---> по <--- спецификации
> FastCGI!

да, верно, имелось что это не новая спецификация FastCGI, а имплементация его

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100

103. Сообщение от eRIC (ok), 17-Май-19, 19:50   +2 +/
>> усоверешенствовыется
> Ты б свой русский посвершенствовывал, что ли.

после чтения толкового словаря по русскому языку, исправлено. старую информацию смотрите, нажмите F5 :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

104. Сообщение от Аноним (39), 17-Май-19, 19:57   +2 +/
>> Вопрос по сементике самого макроса.
> Что конкретно Вам не ясно?

Не ясно, зачем ассерт бросает исключение, которое:
а) из названия не очевидно;
б) может быть по недоразумению проигнорировано.

Плюс к тому, существует вариант NOTHROW, не приводящий к прерыванию выполнения:


#define DMITIGR_DOUT_ALWAYS(...)         DMITIGR_DOUT__(__VA_ARGS__)
#define DMITIGR_ASSERT_ALWAYS(a)         DMITIGR_ASSERT__(a, true)
#define DMITIGR_ASSERT_NOTHROW_ALWAYS(a) DMITIGR_ASSERT__(a, false)

#define DMITIGR_IF_DEBUG__(code) if constexpr (dmitigr::is_debug_enabled) { code }

#define DMITIGR_DOUT(...)         { DMITIGR_IF_DEBUG__(DMITIGR_DOUT_ALWAYS(__VA_ARGS__)) }
#define DMITIGR_ASSERT(a)         { DMITIGR_IF_DEBUG__(DMITIGR_ASSERT_ALWAYS(a)) }
#define DMITIGR_ASSERT_NOTHROW(a) { DMITIGR_IF_DEBUG__(DMITIGR_ASSERT_NOTHROW_ALWAYS(a)) }


То есть: либо автор не стал менять название, постепенно модернизируя давно написанное, либо есть скрытый от малознакомых с новыми веяниями С++ (т.е. от меня) смысл.

Ну и было интересно, кто что скажет из знатоков, коих тут в избытке.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #108

105. Сообщение от Anonymoussemail (?), 17-Май-19, 20:13   –1 +/
Заявление ничем не подкрепленное?
Ну ок.

https://www.apachelounge.com/viewtopic.php?t=4385

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #106

106. Сообщение от dmitigr (ok), 17-Май-19, 20:34   +/
Библиотека dmitigr_fcgi реализована в соответствии со спецификацией FastCGI. См. http://www.mit.edu/afs.new/sipb/user/yandros/doc/specs/fcgi-...

FCGI - это сокращённое название FastCGI. Apache mod_fcgi или mod_fastcgi не имеют никакого отношения к моей библиотеке.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

107. Сообщение от dmitigr (ok), 17-Май-19, 20:42   +2 +/
Спасибо за комментарий. Странные у Вас вопросы. Резервирование пространства имён для проектов одного автора или компании - обычная практика. Я зарезервировал пространство имён dmitigr для своих проектов. А, например, Niels Lohmann, выбрал пространство имён nlohmann для своих проектов, например namespace nlohmann::json.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98

108. Сообщение от dmitigr (ok), 17-Май-19, 20:51   –2 +/
Здесь автор.

> Не ясно, зачем ассерт бросает исключение

Я используют DMITIGR_ASSERT() вместо стандартного assert() почти везде из-за того, что обычный assert() слишком груб и по умолчанию приводит к завершению программы. DMITIGR_ASSERT() же просто генерирует исключение std::logic_error если утверждение ложно. (Мне очевидно, что надо это задокументировать.)

> а) из названия не очевидно;

Спасибо за замечание. Я задокументирую этот момент!

> б) может быть по недоразумению проигнорировано.

По недоразумению может быть всё, что угодно. std::logic_error игнорировать не стоит. Это признак бага в программе или в библиотеках, от которых она зависит.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #119, #138

109. Сообщение от dmitigr (ok), 17-Май-19, 20:56   +/
Бенчмарков нет. Я сравнивал с libfcgi. dmitigr_fcgi быстрее где-то на 15-20%. Я знаю ещё несколько мест в своей реализации для оптимизации и прироста производительности. В скором времени улучшу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #111

110. Сообщение от Аноним (110), 17-Май-19, 21:20   +1 +/
Используем стд:стринг, автоуказатели и горя не знаем.
А ты как перебиваешься, мир небось замирает, как в матрице у Нео. У него тоже ГЦ неоптимизированный был
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

111. Сообщение от eRIC (ok), 17-Май-19, 21:40   +2 +/
> Бенчмарков нет. Я сравнивал с libfcgi. dmitigr_fcgi быстрее где-то на 15-20%. Я
> знаю ещё несколько мест в своей реализации для оптимизации и прироста
> производительности. В скором времени улучшу.

интересно. с активным по сей день с библиотекой https://github.com/eddic/fastcgipp (C++14) попробуйте произвести бенчмарки, будет очень интересно. в будущем надеюсь в проекте бенчмарк отчеты появятся.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

112. Сообщение от Sw00p aka Jerom (?), 17-Май-19, 21:45   +2 +/
Бывает, когда в мыслях проговариваешь, а в комментарии думаешь что написал, да, да, нажимаем сразу отправить потом только видим ошибку :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

113. Сообщение от Аноним (16), 17-Май-19, 21:52   +4 +/
> автор хочет, вероятно, привести код в соответствии протоколу HTTP, в котором перевод строки строго определён как "\r\n". Так что мат. часть, вероятно, надо учить как раз Вам.

Матчасть учить нужно тому, кто не знает про существование std::ios_base::openmode binary, когда ему нужно выводить данные в поток без преобразования символов под конкретную ОС.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

114. Сообщение от Аноним (16), 17-Май-19, 22:04   –1 +/
> on modern C++

Писать по-английски – это вообще-то не слова по словарю с вашего языка переводить.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

115. Сообщение от Ordu (ok), 17-Май-19, 22:10   +3 +/
>  На то и серверное сетевое приложение, которое работает фактически вечно для обслуживания запросов.

Нет. Реальное серверное приложение имеет документированные возможности, позволяющие остановить его. Возможно ещё перезапустить/перезагрузить конфиги. Серверное приложение _фактически_ не работает вечно, оно регулярно перезапускается после изменения конфигурации или наложения патчей безопасности.

> У вас какая-то другая точка зрения как это реализовать?

Я могу предложить штуки три альтернативы. while(accept()), server.map_connections(|conn| { ... }) и итератор поверх открываемых соединений. Но вопрос не в том как реализовать, а в мотивации для отказа от той реализации, которая есть. Здесь штатная ситуация (а фейл accept'а -- это, во многих случаях, штатная ситуация) обрабатывается при помощи throw, который используется как нелокальный goto. Такой подход скрывает логику работы, понимание которой существенно для понимания того, как работает этот цикл и что он делает. Это скрытый control flow, относящийся к обработке штатных ситуаций.

В результате мы получаем, что сервер написанный с использованием fcgi будет выполнять штатное завершение через нелокальный выход при помощи throw. Это будет работать, но так делать не надо.

Делать надо через Either/Result[1]. Это, по-моему, _напрашивающийся_ подход: когда я фанател C'ями, я пытался такую штуку сделать в C, по-сути изобретя её самостоятельно. Я писал какой-то парсер, который возвращал токены и подвыражения, но при этом любая функция могла завершиться с ошибкой. Из-за отсутствия параметризованных типов пришёл к выводу, что всё это конечно круто, но для каждой функции описывать структуру с возвращаемым типом -- это всё же бред. Сейчас я думаю, что может быть можно как-то на кривой козе макросами объехать ограничения языка, но мне просто C более не интересен, поэтому плевать.

В Haskell'е же, OCaml'е это совершенно нормальный и естественный ход. И в C++ это должно быть естественным ходом -- для обработки ошибок таким образом не нужен никакие замороки с размоткой стека исключениями, обработка происходит явно и довольно удобно (без этого бесконечного засирания кода if'ами и без необходимости для каждого типа предусматривать значение, которое будет аналогом NULL для указателя), она проверяется статически через систему типов, и блин, всё это настолько естественно, даже непонятно сегодня, почему это было не запилить в C в 70-х годах. Пускай даже для этого потребовался бы специально выточенный костыль из-за отсутствия параметризованных типов.

Я не очень понимаю, насколько эти вещи стандартизованы в C++, судя по тексту статьи складывается ощущение, что не стандартизованы, и каждый дpoчит как хочет, а интероперабельность разных API приходится выпиливать лобзиком в каждом конкретном случае. Но там есть ссылки на std::expected и boost::expected, то есть всё не так плохо.

[1] https://hackernoon.com/error-handling-in-c-or-why-you-should...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #122

116. Сообщение от segesg (?), 17-Май-19, 22:42   +/
аффтар сам и выкладывает, пиарится
точнее - позорится
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

118. Сообщение от dmitigr (ok), 17-Май-19, 23:06   +1 +/
Спасибо, исправил! Эта регрессия появилась из-за относительно давнего рефакторинга. Я её и не замечал.

PS. Ведь можно же как-то проще сообщать о недочётах. А то чуть что, так сразу "автор неосилил". Не этично.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #152, #198, #186

119. Сообщение от RibiKukan (ok), 17-Май-19, 23:13   +1 +/
>Я используют DMITIGR_ASSERT() вместо стандартного assert()

Кто тебе мешает использовать нормальные имена?

>слишком груб и по умолчанию приводит к завершению программы.

Это семантика асерта.

>DMITIGR_ASSERT() же просто генерирует исключение std::logic_error если утверждение ложно.

https://github.com/dmitigr/common/blob/b582b4daf674eed5df1d1...

Что это за нелепое говно? Ты вообще понимаешь почему assert макрос? Только для LINE и т.п. Если ты что-то там вещаешь про "модный С++" и пытаешься(нелепо) использовать увиденные где-то трюки(constexpr/constexpr if), то на них логика и должна быть построена. Эта же клоунада - просто клоунада нелепая. Зачем ты превратил макрос в переменную, что-бы потом использовать нахрен ненужный так constexpr if?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #135

120. Сообщение от RibiKukan (ok), 17-Май-19, 23:15   –2 +/
Поделка действительно уровня студента и никакого "свежего стандарта" там нет и близко. Но ты ссылаешься на такую студ-поделку.

>https://docs.rs/fastcgi/1.0.0/fastcgi/

Что конкретно тут лаконично? Кроме отсутствия убогих потоков. Хотя нет, макрос говна хуже убогих потоков.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #125

121. Сообщение от Аноним (121), 17-Май-19, 23:55   +/
cppcms же есть
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #132

122. Сообщение от Sw00p aka Jerom (?), 18-Май-19, 00:02   –2 +/
> Реальное серверное приложение имеет документированные возможности, позволяющие остановить его.

while (true) - всегда можно остановить!

> Серверное приложение _фактически_ не работает вечно

while (true) - это "вечный цикл", и если такой код есть в серверном приложении, то значить он работает вечно, а выход из него - по требованию, в том числе и при непредвиденных обстоятельствах.

> Я могу предложить штуки три альтернативы. while(accept()), server.map_connections(|conn| { ... }) и итератор поверх открываемых соединений.

while(accept()) - тоже самое (с проверкой EAGAIN), что и while (true) { accept() }

man ACCEPT(2)

Один вызов accept() - обработать одно соединение. Думаю догадаетесь как обработать N соединений.


>Но вопрос не в том как реализовать, а в мотивации для отказа от той реализации, которая есть.

Человек говорил, что while (true) { accept() } - не правильно применять. Вопрос именно в этом, то есть как обработать N соединений, если accept() обрабатывает одно за вызов.


> Здесь штатная ситуация (а фейл accept'а -- это, во многих случаях, штатная ситуация) обрабатывается при помощи throw, который используется как нелокальный goto.

ну извините, выше я привел пример как реализовано в пхп, и как написал автор, с той лишь разницей, что автор писал на плюсах. И что не устроила автора комента 1.11, X4asd, который скорее всего плохо знаком с Ц++ и ООП. Он заявил, что там нет условий выхода из вечного цикла, потому-что нет всяких условных конструкций как это обычно делается на СИ.

> Такой подход скрывает логику работы, понимание которой существенно для понимания того, как работает этот цикл и что он делает. Это скрытый control flow, относящийся к обработке штатных ситуаций.

рассмешили вы меня тут)))) а как же парадигма ООП, прячь все поглубже? ))) вот вам и результат Ц++, а не лапшекод из условных операторов на Си, примеры на Си из пхп выше.

>В результате мы получаем, что сервер написанный с использованием fcgi будет выполнять штатное завершение через нелокальный выход при помощи throw. Это будет работать, но так делать не надо.

с чего вы взяли, что выход из "вечного цикла" возможен только лишь при нештатных ситуациях? Вы код автора открывали? Выше указал даже номера строк.

>но для каждой функции описывать структуру с возвращаемым типом -- это всё же бред

О да, это прям как - всё есть класс )

>Я не очень понимаю

Ну и я не понимаю, зачем нужны вообще всякие ЯП, когда есть КОП процессора :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115 Ответы: #130

124. Сообщение от Аноним (124), 18-Май-19, 00:19   +2 +/
Ну и норм
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

125. Сообщение от Ananimususus (?), 18-Май-19, 00:36   +/
А есть чего нормального на плюсах для FastCGI?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #126

126. Сообщение от RibiKukan (ok), 18-Май-19, 01:14   +/
> А есть чего нормального на плюсах для FastCGI?

Может и есть, но я таким убожеством не пользуюсь - не знаю. Я ни разу не работал с подобным(FastCGI) бесполезным легаси-говном.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #127

127. Сообщение от Ananisimus (?), 18-Май-19, 02:29   +/
А с чем работаешь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #131, #133

128. Сообщение от anonnn (?), 18-Май-19, 02:45   –3 +/
какой-то ненужный у вас юниксвей
хттп сейчас более востребован
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

129. Сообщение от anonnn (?), 18-Май-19, 02:48   –2 +/
1. к чему эта статья тут?
2. причем тут nginx unit?
мне не ясно как вы связали nginx unit (работающий по хттп) и fastcgi
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

130. Сообщение от Ordu (ok), 18-Май-19, 02:57   +1 +/
> man ACCEPT(2)

При чём здесь man accept? Мне казалось очевидно, что речь идёт о том самом server->accept(), но может быть с несколько иным прототипом, чтобы каким-нибудь образом позволить использовать его в качестве условия для while.

> Один вызов accept() - обработать одно соединение. Думаю догадаетесь как обработать N
> соединений.

При написании кода, вопрос не как обработать N соединений, а как написать код так, чтобы понять его через полгода. Чтобы этот код был бы понятен даже тому, кто думает как надо обработать N соединений. Один и тот же алгоритм можно написать тысячью способов, и когда ты будешь читать один из этих способов в коде, тебе надо будет понять, что именно это за способ. Не просто придумать как обработать N соединений, а понять что там напридумывал автор кода.

Вопрос в том, как написать код, в котором можно искать баги. Как написать код, о котором можно рассуждать и, в процессе поиска багов, или поиска пути как внести желаемые изменения, доказывать в голове, что "в этой функции не может возникать сегфолт, потому что...", или "этот кусок памяти не может утекать, потому что...". Те возможности, которые язык предоставляет для такого -- это одно из самых важных свойств языка. Всё остальное преходяще.

>>Но вопрос не в том как реализовать, а в мотивации для отказа от той реализации, которая есть.
> Вопрос именно в этом, то есть как обработать N соединений, если accept() обрабатывает одно за вызов.

Как угодно, лишь бы результат отражал бы в коде всё, что нужно про него знать читая этот код. control flow -- это важная вещь, которая должна быть отражена. Структурное программирование не зря придумывали, и никаких longjmp'ов там не было. Некоторые даже с goto боролись до того, что этот самый goto начали выкидывать из языков, местами предлагая взамен совершенно уродские языки. Некоторые даже return выкидывали. С return'ом это пожалуй перебор, но вот longjmp не нужен точно. Если ты конечно не пытаешься на нём реализовать библиотечку coroutine'ов, или ещё какую юзерспейс многозадачность, и используешь longjmp для переключения контекстов.

>> Такой подход скрывает логику работы, понимание которой существенно для понимания того, как работает этот цикл и что он делает. Это скрытый control flow, относящийся к обработке штатных ситуаций.
> рассмешили вы меня тут)))) а как же парадигма ООП, прячь все поглубже?
> ))) вот вам и результат Ц++, а не лапшекод из условных
> операторов на Си, примеры на Си из пхп выше.

Ну да, возможно это ситуация "заставь дурака богу молиться". Если довести идею инкапсуляции до абсурда, то мы получим чёрную дыру, которая ничего не выпускает наружу и сжирает всё, что оказывается достаточно близко. Идеальный инкапсулятор. Совершенно бесполезный. Но в том-то и дело, что инкапсуляцию, как и любой другой инструмент, следует использовать с умом. Вне зависимости от того, пишем ли мы в ООП парадигме или в какой-то другой.

>>В результате мы получаем, что сервер написанный с использованием fcgi будет выполнять штатное завершение через нелокальный выход при помощи throw. Это будет работать, но так делать не надо.
> с чего вы взяли, что выход из "вечного цикла" возможен только лишь
> при нештатных ситуациях? Вы код автора открывали? Выше указал даже номера
> строк.

С чего вы взяли, что мы взяли, что выход из вечного цикла возможен лишь при нештатных ситуациях? Мы говорили о том, что штатная ситуация обрабатывается как нештатная. Штатная ситуация обрабатывается нештатным нелокальным goto.

>>но для каждой функции описывать структуру с возвращаемым типом -- это всё же бред
> О да, это прям как - всё есть класс )

Нет, не всё есть класс. Это совершенно перпендикулярные понятия. Есть значения, которые позволяет передавать информацию. Скажем значение вида

struct MaybeToken {
   bool ok;
   union {
       Token tok;
       Error err;
   }
};

позволяет вернуть из функции токен, если он найден, или ошибку, если он не найден. Ошибка при этом может быть содержательной и обрабатывая её мы можем вывести приятное сообщение об ошибке. Или мы можем выполнить какой-нибудь recovery для каких-то из возможных ошибок. Или мы можем преобразовать ошибку к другому типу ошибки, который будет более осмысленным выше, и вернуть её. В C принято выкручиваться всякими разными способами, типа кодировать ошибку отрицательными значениями целочисленной переменной, для которой осмысленны только положительные значения. Или возвращать NULL вместо указателя (таким образом сообщая о факте ошибки, но если причин ошибки может быть несколько и вызывающий код хочет их различать, то это не работает). Или возвращая значение из функции складывая его по переданному указателю, а возвращаемым значением функции выдавать код ошибки. Но это же всё костыли, и естественно возникает желание придумать общий способ для всех. Страуструп придумал исключения, но причёсанняй longjmp как способ обработки ошибок -- это гумно, и опыт C++ показал, что гумно это не только по каким-то замудрёным теоретическим причинам, типа потому что нарушение принципов структурного программирования, но и по вполне практическим.

> Ну и я не понимаю, зачем нужны вообще всякие ЯП, когда есть
> КОП процессора :)

КОП какого процессора?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #154

131. Сообщение от _ (??), 18-Май-19, 03:46   +5 +/
Он членами деревянными на базаре торгует! (С) :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127 Ответы: #142

132. Сообщение от Аноним (132), 18-Май-19, 04:34   +/
Зачем есть же libevent с HTTP поддержкой
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #197

133. Сообщение от RibiKukan (ok), 18-Май-19, 04:48   +/
В каком плане? Насколько я понимаю fcgi это такой плебейский ipc. Мало практикую подобное. Так же вроде оно сетевое. Сетевых библиотек множество. На этом уровне работаю в с двумя вещами. uWebSockets - для плебейской коммуникации(оно может в хттп(почти не используется)/ws(используется всегда)). Для внутренней коммуникации - самопал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127 Ответы: #134, #189

134. Сообщение от Anaranizimuzus (?), 18-Май-19, 04:54   +/
>Насколько я понимаю fcgi это такой плебейский ipc.

Ага.

>uWebSockets
>оно может в хттп(почти не используется)/ws(используется всегда)

То что нужно, спасибо.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133

135. Сообщение от Аноним (39), 18-Май-19, 07:22   +/
>>Я используют DMITIGR_ASSERT() вместо стандартного assert()
> Кто тебе мешает использовать нормальные имена?

По-простому это называется "глаз замылился". Автору и без имён понятно, что делает макрос. Код выложил, что бы посмотреть на него со стороны.

>>слишком груб и по умолчанию приводит к завершению программы.
> Это семантика асерта.

Да. К счастью, макрос порвал мне шаблон при беглом просмотре исходников, а не при открытии некоего сайта.

>>DMITIGR_ASSERT() же просто генерирует исключение std::logic_error если утверждение ложно.
> https://github.com/dmitigr/common/blob/b582b4daf674eed5df1d1...
> Что это за нелепое говно? Ты вообще понимаешь почему assert макрос? Только
> для LINE и т.п. Если ты что-то там вещаешь про "модный
> С++" и пытаешься(нелепо) использовать увиденные где-то трюки(constexpr/constexpr if),
> то на них логика и должна быть построена. Эта же клоунада
> - просто клоунада нелепая. Зачем ты превратил макрос в переменную, что-бы
> потом использовать нахрен ненужный так constexpr if?

constexpr if нужен, что бы свести к минимуму использование препроцессора, отказавшись от #ifdef. IDE синтаксическом разборе исходного текста выкидывают одну из веток препроцессора в зависимости от NDEBUG, что не всегда удобно при разборе кода.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #136

136. Сообщение от RibiKukan (ok), 18-Май-19, 07:40   +/
>constexpr if нужен, что бы свести к минимуму использование препроцессора, отказавшись от #ifdef.

Полный бред. Я там объяснял почему.

>IDE синтаксическом разборе исходного текста выкидывают одну из веток препроцессора в зависимости от NDEBUG, что не всегда удобно при разборе кода.

Причин гениальней это я не слышал. Т.е. constexpr if только для того, чтобы захакать ide? Да, сильно. К тому же, чем это неудобно я так и не понял.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #139

138. Сообщение от Аноним (39), 18-Май-19, 08:07   +/
> Здесь автор.
>> Не ясно, зачем ассерт бросает исключение
> Я используют DMITIGR_ASSERT() вместо стандартного assert() почти везде из-за того, что
> обычный assert() слишком груб и по умолчанию приводит к завершению программы.

А зачем продолжать её исполнение?

> DMITIGR_ASSERT() же просто генерирует исключение std::logic_error если утверждение ложно.
> (Мне очевидно, что надо это задокументировать.)

Виноват, но я принципиально не смотрел документацию, где сказано про зависимости. При этом (в отличии он некоторых читавших) нашёл макрос, поднявшись на уровень выше в репозитории, где увидел common и debug. Если бы имя макроса содержало в себе что-то вроде COMMON или LIB, было бы сразу очевидно, что искать его следует в другой библиотеке.

>> а) из названия не очевидно;
> Спасибо за замечание. Я задокументирую этот момент!

Имеете ввиду, где-то отдельно уточнить? Если есть вариант с NOTHROW, почему нет с THROW?

>> б) может быть по недоразумению проигнорировано.
> По недоразумению может быть всё, что угодно. std::logic_error игнорировать не стоит. Это
> признак бага в программе или в библиотеках, от которых она зависит.

The class logic_error defines the type of objects thrown as exceptions to report errors presumably detectable before the program executes, such as violations of logical preconditions or class invariants.

Тут пишут, что не просто бага, а тех, что могут быть исключены до выполнения программы. То есть ошибки входных данных. Если же срабатывают ассерты, то запускать программу немножко рано -- она даже собрана на для релиза.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #140

139. Сообщение от Аноним (39), 18-Май-19, 08:26   +/
>>constexpr if нужен, что бы свести к минимуму использование препроцессора, отказавшись от #ifdef.
> Полный бред. Я там объяснял почему.

Да, там похоже на это самое. Мы ведь понимаем, что "бред" не технический аргумент.

>>IDE синтаксическом разборе исходного текста выкидывают одну из веток препроцессора в зависимости от NDEBUG, что не всегда удобно при разборе кода.
> Причин гениальней это я не слышал. Т.е. constexpr if только для того,
> чтобы захакать ide? Да, сильно. К тому же, чем это неудобно
> я так и не понял.

Есть многое в природе, друг Горацио, что и не снилось нашим мудрецам (с) https://www.sourceinsight.com/wp-content/uploads/2016/03/app...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #157

140. Сообщение от dmitigr (ok), 18-Май-19, 10:31   +/
> А зачем продолжать её исполнение?

Здесь больше интересен вопрос: как по-мягче завершить её выполнение? Меня не устраивает заверешние через std::abort(), поэтому DMITIGR_ASSERT() генерирует std::logic_error, что предоставляет возможность самому приложению решать как именно закругляться (или не закругляться).

> Если бы имя макроса содержало в себе что-то вроде COMMON или LIB, было бы сразу очевидно, что искать его следует в другой библиотеке.

Так и было. Раньше он назывался DMITIGR_INTERNAL_ASSERT(). Но я не вижу в этом больше смысла.

> Имеете ввиду, где-то отдельно уточнить? Если есть вариант с NOTHROW, почему нет с THROW?

Вариант с "THROW" - это и есть DMITIGR_ASSERT().

> Тут пишут, что не просто бага, а тех, что могут быть исключены до выполнения программы.

Это и есть баг. И всякий баг - это логическая ошибка. Можно ввести класс Bug, унаследованный от std::logic_error, но в этом смысл околонулевой - о классе std::logic_error знают все, кто пишет на C++.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #144, #151

141. Сообщение от Anonim (??), 18-Май-19, 11:13   +1 +/
>Видимо кому-то все еще нужно поддерживать древнее барахло,
>написанная на современном C++17

???

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

142. Сообщение от Anonim (??), 18-Май-19, 11:16   +/
Деревянные -суровое легаси! Им резиновые пришли на смену, ещё в прошлом веке!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131

143. Сообщение от udro (?), 18-Май-19, 11:24   +/
> Что такое os.widen? Что он там расширяет? Не расширяет ли он заодно '\n' до \r\n, когда нужно?

Он — нет. Он только кодировки преобразует, если надо (в UTF-16LE, например, мало ли). А возврат каретки и без него добавляется в ostream. Я хз, чё они курили, но просто вывести \n на винде ещё постараться надо.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

144. Сообщение от Аноним (39), 18-Май-19, 11:32   +/
>> А зачем продолжать её исполнение?
> Здесь больше интересен вопрос: как по-мягче завершить её выполнение? Меня не устраивает
> заверешние через std::abort(), поэтому DMITIGR_ASSERT() генерирует std::logic_error,
> что предоставляет возможность самому приложению решать как именно закругляться (или не
> закругляться).

Наверное, прежде всего для этого необходимо обеспечить 100% гарантии вызова обработчика исключений, ведь в ситуации ассерта он (в общем случае) может оказаться неконсистентном состоянии.

>> Если бы имя макроса содержало в себе что-то вроде COMMON или LIB, было бы сразу очевидно, что искать его следует в другой библиотеке.
> Так и было. Раньше он назывался DMITIGR_INTERNAL_ASSERT(). Но я не вижу в
> этом больше смысла.
>> Имеете ввиду, где-то отдельно уточнить? Если есть вариант с NOTHROW, почему нет с THROW?
> Вариант с "THROW" - это и есть DMITIGR_ASSERT().

При этом называется он не DMITIGR_ASSERT_THROW. В последнем варианте наименования все аргументы вида "семантика ассерта отличается" теряют смысл. :)

>> Тут пишут, что не просто бага, а тех, что могут быть исключены до выполнения программы.
> Это и есть баг. И всякий баг - это логическая ошибка. Можно
> ввести класс Bug, унаследованный от std::logic_error, но в этом смысл околонулевой
> - о классе std::logic_error знают все, кто пишет на C++.

__builtin_trap() - ошибка физическая (на x86 транслируется в UD2). SIGILL логическая. Тоже генерируют исключение, которое можно попробовать поймать, но перепутать его с подмножеством ошибок std::logic_error -- надо постараться.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #145

145. Сообщение от dmitigr (ok), 18-Май-19, 11:46   +/
> Наверное, прежде всего для этого необходимо обеспечить 100% гарантии вызова обработчика исключений, ведь в ситуации ассерта он (в общем случае) может оказаться неконсистентном состоянии.

Обработчики исключений, которые пересекают границы библиотек, определяются в приложениях.

> ведь в ситуации ассерта он (в общем случае) может оказаться неконсистентном состоянии.

О каком неконсистентном состоятии речь?

> При этом называется он не DMITIGR_ASSERT_THROW. В последнем варианте наименования все аргументы вида "семантика ассерта отличается" теряют смысл. :)

Он называется DMITIGR_ASSERT(), а не ASSERT() или Assert(). Поэтому судить о семантике следует либо из документации, либо из определения.

>  __builtin_trap() - ошибка физическая (на x86 транслируется в UD2). SIGILL логическая. Тоже генерируют исключение, которое можно попробовать поймать, но перепутать его с подмножеством ошибок std::logic_error -- надо постараться.

Не совсем понял к чему это, но исключения std::logic_error ловятся стандартным образом.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144 Ответы: #149

146. Сообщение от Аноним (146), 18-Май-19, 12:20   +8 +/
Непонятно откуда столько негатива в коментах. Люди, вы если с чем-то несогласны, пишите аргументировано. Давайте уже перестанем сеять среди нашего общества негатив.

Советую к прочтению:
en: http://paulgraham.com/disagree.html
ru: https://web.archive.org/web/20120505004501/http://translated.../

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #164, #199

147. Сообщение от Аноним (147), 18-Май-19, 13:43   +4 +/
«Всё просто» — это в любом случае не про кресты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

149. Сообщение от Аноним (39), 18-Май-19, 15:24   +/
>> При этом называется он не DMITIGR_ASSERT_THROW. В последнем варианте наименования все аргументы вида "семантика ассерта отличается" теряют смысл. :)
> Он называется DMITIGR_ASSERT(), а не ASSERT() или Assert(). Поэтому судить о семантике
> следует либо из документации, либо из определения.

Следует? Автору виднее. Автор может поступать, как считает нужным. Сам.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #155

150. Сообщение от Филимон Печальный (?), 18-Май-19, 16:28   +6 +/
Народ, вы чего ? Человек написал библиотеку, выложил бесплатно, никого использовать её не заставляет... Где здесь повод исходить говном ?
Это массовый психоз какой-то :-(
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #163, #170, #178

151. Сообщение от Anonymoustus (ok), 18-Май-19, 16:29   +/
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_
> DMITIGR_

Аффтару нимб не жмёт?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

152. Сообщение от Anonymoustus (ok), 18-Май-19, 16:31   +/
> PS. Ведь можно же как-то проще сообщать о недочётах. А то чуть
> что, так сразу "автор неосилил". Не этично.

Это опенсорс! Никто никому ничего не должен™.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118 Ответы: #153

153. Сообщение от dmitigr (ok), 18-Май-19, 16:50   –1 +/
> Это опенсорс! Никто никому ничего не должен™.

Хм. А какое Вы имеете отношение к open source? Разве Вы что-то сотворили?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152

154. Сообщение от Sw00p aka Jerom (?), 18-Май-19, 16:58   +/
>При чём здесь man accept? Мне казалось очевидно, что речь идёт о том самом server->accept(), но может быть с несколько иным прототипом, чтобы каким-нибудь образом позволить использовать его в качестве условия для while.

А притом, что это системный вызов, и без разницы какие тами уровни абстракции поверх.

>При написании кода, вопрос не как обработать N соединений, а как написать код так, чтобы понять его через полгода.

И через пол года, мы осознаем, что написали дичь какую-то.


>Вопрос в том, как написать код, в котором можно искать баги.

)) нужно писать код, в котором баги искать не нужно.


>Один и тот же алгоритм можно написать тысячью способов, и когда ты будешь читать один из этих способов в коде, тебе надо будет понять, что именно это за способ.

И ЯП современные занимаются именно тем как научить 100500 способами простреллить себе ногу, а не один и правильный способ. Про всякие неопределенные поведения я промолчу. Любая формальная система - неполна! (К. Гедель)


> что "в этой функции не может возникать сегфолт, потому что...",

потому-что, что? А я скажу иначе, сегфолт будет иметь место всегда, когда на одной машине Тьюринга с одной лентой, вы исполняете два алгоритма. Если есть граница (искусственная), то её всегда можно нарушить, как умышленно, так и непредумышленно. А вот границы установленные тем же Богом, нарушить нельзя - почему?

>Те возможности, которые язык предоставляет для такого -- это одно из самых важных свойств языка. Всё остальное преходяще.

)) язык этого не должен предоставлять, вот естественный язык позволяет выражаться матом, но вы как человек культурный, не принимаете мат, для вас существует граница. Что в итоге, вы из естественного языка предлагаете выпиливать мат? проблема в том, что - где гарантии, что весь язык завтра для вас не будет матершиным? Вы перестанете на нем разговаривать и слышать его?

>control flow -- это важная вещь, которая должна быть отражена. Структурное программирование не зря придумывали, и никаких longjmp'ов там не было.

control flow - детерминированность, пошаговость (https://ru.wikipedia.org/wiki/%D0%94%D0%...), если есть возможность сделать один шаг, почему не должно быть возможности сделать N шагов за раз, то есть прыжок?

>Некоторые даже с goto боролись до того, что этот самый goto начали выкидывать из языков

опять забыли про машину Тьюринга, разница между шагом и прыжко - никакая! Борьба с goto - "донкихотство".

>Некоторые даже return выкидывали. С return'ом это пожалуй перебор, но вот longjmp не нужен точно.

Из ваших рассуждений следует, что найдется по крайней мере один человек, который выкинет весь язык! Что мы наблюдаем на самом деле.

>Но в том-то и дело, что инкапсуляцию, как и любой другой инструмент, следует использовать с умом.

Вот эту же мысль, попробуйте применить для goto, а не рубить с плеча.

>Вне зависимости от того, пишем ли мы в ООП парадигме или в какой-то другой.

Если нет никакой зависимости, то с чего мне менять машину Тьюринга на Си?

>С чего вы взяли, что мы взяли, что выход из вечного цикла возможен лишь при нештатных ситуациях?

В следствии ваших же рассуждений.

>Мы говорили о том, что штатная ситуация обрабатывается как нештатная.

кхммм тут лучше с пример кода пожалуйста, а то мне кажется что мы говорит о разном.

>Штатная ситуация обрабатывается нештатным нелокальным goto.

что есть нелокальным? Лента в машине Тьюринга - локальна?

>Страуструп придумал исключения, но причёсанняй longjmp как способ обработки ошибок -- это гумно, и опыт C++ показал, что гумно это не только по каким-то замудрёным теоретическим причинам, типа потому что нарушение принципов структурного программирования, но и по вполне практическим.

мне было бы очень интересно послушать, что придумали бы вы на месте Страуструпа (серьезно). Как можно разрешить данную проблему?

>КОП какого процессора?

Того, который собираетесь использовать. Машина Тьюринга одна (ну есть еще машина Поста и т.д.), архитектура того же процессора - одна (Фон Неймановская).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #175

155. Сообщение от dmitigr (ok), 18-Май-19, 17:01   +/
Следует. С чего вдруг некий DMITIGR_ASSERT() должен повторять семантику стандартного assert()? Наличие слова "ASSERT" в названии к этому не обязывает.

Мне не понятно, зачем вообще Вам этот макрос? Это деталь реализации. Пользователям библиотеки она совершенно не нужна. Если Вы собираетесь поучаствовать в разработке, то Вы уже знаете что это за макрос, благо его определение занимает 5 строчек. Спасибо за дискуссию!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #159

157. Сообщение от RibiKukan (ok), 18-Май-19, 18:01   +/
>Да, там похоже на это самое. Мы ведь понимаем, что "бред" не технический аргумент.

Технический. Твоя обязанность обосновать. Ты не обосновал, а поиграл в клоуна. Именно это является бредом.

>Есть многое в природе, друг Горацио, что и не снилось нашим мудрецам (с) https://www.sourceinsight.com/wp-content/uploads/2016/03/app...

И, что ты этим показал? Ну кроме того, что ты привык жрать птушное говно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #161

159. Сообщение от Аноним (39), 18-Май-19, 18:18   +/
> Следует. С чего вдруг некий DMITIGR_ASSERT() должен повторять семантику стандартного assert()?

"Должен" не то слово. Есть ожидания пользователя, читателя кода. Если они расходится положением дел, возможны варианты (принять/не принять).

> Мне не понятно, зачем вообще Вам этот макрос?

Интерес представляет в первую очередь ход мыслей автора. Если глаз цепляется, значит такое наверняка повстречается где-то ещё. Чем больше задаю таких глупых вопросов, тем проще потом сориентироваться в новом коде. Документация не всегда в наличии, как и исходники. Благодарю за разъяснения.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155

161. Сообщение от Аноним (39), 18-Май-19, 18:32   +/
>>Да, там похоже на это самое. Мы ведь понимаем, что "бред" не технический аргумент.
> Технический. Твоя обязанность обосновать. Ты не обосновал, а поиграл в клоуна. Именно
> это является бредом.

Бред, по определению, девиация мышления на фоне деменции. И есть, Петька, один нюанс. Оппонент твой  сменился. Ты пишешь про обязанности не автору. Могу ещё сыграть в того самого клоуна. Ты только как следует попроси.

>>Есть многое в природе, друг Горацио, что и не снилось нашим мудрецам (с) https://www.sourceinsight.com/wp-content/uploads/2016/03/app...
> И, что ты этим показал? Ну кроме того, что ты привык жрать
> птушное говно.

Это была Чорная Магия. Заклинание 1го уровня "зеркало". Всего лишь.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157 Ответы: #169

163. Сообщение от Аноним (39), 18-Май-19, 18:52   +1 +/
Да какой массовый? Парочка типичных персонажей изображают толпу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150

164. Сообщение от eRIC (ok), 18-Май-19, 19:14   +1 +/
+1
наследие СССР :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146 Ответы: #182

169. Сообщение от RibiKukan (ok), 18-Май-19, 20:36   –1 +/
>Бред, по определению, девиация мышления на фоне деменции. И есть, Петька, один нюанс. Оппонент твой  сменился. Ты пишешь про обязанности не автору. Могу ещё сыграть в того самого клоуна. Ты только как следует попроси.

Клоун, мне без разницы на то кто ты. Ты для меня не отличаешься от любого другого клоуна в интернете. Ты пыль. Твоя задача - либо смешить меня жалкими потугами что-то мне ответить, либо обделаться. Ты выбрал второе, и я даже жалких потуг не увидел.

>Это была Чорная Магия. Заклинание 1го уровня "зеркало". Всего лишь.

Опять нырнул в дерьмо.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161 Ответы: #180

170. Сообщение от Anonymoustus (ok), 18-Май-19, 20:41   +/
Утешься прекрасным:

https://www.govnokod.ru/25608

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150

175. Сообщение от Ordu (ok), 18-Май-19, 23:03   +1 +/
>>При чём здесь man accept? Мне казалось очевидно, что речь идёт о том самом server->accept(), но может быть с несколько иным прототипом, чтобы каким-нибудь образом позволить использовать его в качестве условия для while.
> А притом, что это системный вызов, и без разницы какие тами уровни
> абстракции поверх.

Нет, не без разницы. server->accept, вероятно, проводит не только accept на сокете, но ещё и "обмен приветствиями" с клиентом, что можно порождать новые классы ошибок.

>>При написании кода, вопрос не как обработать N соединений, а как написать код так, чтобы понять его через полгода.
> И через пол года, мы осознаем, что написали дичь какую-то.

Я рад, что этот опыт тебе знаком, это значит, что тебе должно быть проще понять о чём я говорю.

>>Вопрос в том, как написать код, в котором можно искать баги.
> )) нужно писать код, в котором баги искать не нужно.

То есть код, который удаляется сразу после написания? :D

Все как правило так и делают, то есть пишут код, в котором багов искать не нужно. Я недавно читал исследование, посвящённое исследованию поиску и сравнению факторов, влияющих на частоту появления багов. Из него как раз и вытекает, что при исходном написании кода, как правило багов не так много привносится, но вот при дальнейших модификациях его, особенно если эти модификации выполняются не исходным автором кода, багов привносится гораздо-гораздо больше.

Проблема в том, что менять код приходится. И разработчики меняются. Некоторые умудряются обходить этот момент, но вообще это дорогое удовольствие, держать разработчика ответственным за код десятилетиями. Люди меняют место работы, или в случае FOSS теряют интерес к коду или возможность им заниматься. Приходят другие, и вот им хочешь не хочешь приходится разбираться в том, что там было написано, и вносить изменения в существующий код, наполняя его заодно багами.

>>Один и тот же алгоритм можно написать тысячью способов, и когда ты будешь читать один из этих способов в коде, тебе надо будет понять, что именно это за способ.
> И ЯП современные занимаются именно тем как научить 100500 способами простреллить себе
> ногу, а не один и правильный способ. Про всякие неопределенные поведения
> я промолчу. Любая формальная система - неполна! (К. Гедель)

Знаешь, чем дольше я наблюдаю за людьми цитирующими Гёделя, тем больше я прихожу к выводу, что все эти цитаты исключительно от необразованности. Чтобы цитировать Гёделя, необходимо не понимать Гёделя.

>> что "в этой функции не может возникать сегфолт, потому что...",
> потому-что, что? А я скажу иначе, сегфолт будет иметь место всегда, когда
> на одной машине Тьюринга с одной лентой, вы исполняете два алгоритма.
> Если есть граница (искусственная), то её всегда можно нарушить, как умышленно,
> так и непредумышленно. А вот границы установленные тем же Богом, нарушить
> нельзя - почему?

О, Бога ты тоже не зря упомянул. Вижу догматизм в тебе я, и всуе Бога упоминание к лицу тебе.

>>Те возможности, которые язык предоставляет для такого -- это одно из самых важных свойств языка. Всё остальное преходяще.
> )) язык этого не должен предоставлять, вот естественный язык позволяет выражаться матом,
> но вы как человек культурный, не принимаете мат, для вас существует
> граница. Что в итоге, вы из естественного языка предлагаете выпиливать мат?
> проблема в том, что - где гарантии, что весь язык завтра
> для вас не будет матершиным? Вы перестанете на нем разговаривать и
> слышать его?

Тут ты самым позорным образом путаешь тёплое с мягким. Русский язык предоставляет возможность выражаться красиво и точно. То что он при этом предоставляет философское матерное подмножество, позволяющее выражаться грязно и неточно -- это другой вопрос.

>>control flow -- это важная вещь, которая должна быть отражена. Структурное программирование не зря придумывали, и никаких longjmp'ов там не было.
> control flow - детерминированность, пошаговость (https://ru.wikipedia.org/wiki/%D0%94%D0%...),
> если есть возможность сделать один шаг, почему не должно быть возможности
> сделать N шагов за раз, то есть прыжок?

Control flow -- это "течение управления", это то как исполнитель программы движется по коду. Если твои словари не объясняют тебе этого, то это много говорит нам о никудышнем качестве твоих словарей, и ничего не сообщает о control flow, потому что мы знаем больше тебя.

>>Некоторые даже с goto боролись до того, что этот самый goto начали выкидывать из языков
> опять забыли про машину Тьюринга, разница между шагом и прыжко - никакая!
> Борьба с goto - "донкихотство".

Вот это проявление того самого догматизма.

>>Некоторые даже return выкидывали. С return'ом это пожалуй перебор, но вот longjmp не нужен точно.
> Из ваших рассуждений следует, что найдется по крайней мере один человек, который
> выкинет весь язык! Что мы наблюдаем на самом деле.

Да, я наблюдаю вас, действительно.

>>Но в том-то и дело, что инкапсуляцию, как и любой другой инструмент, следует использовать с умом.
> Вот эту же мысль, попробуйте применить для goto, а не рубить с
> плеча.

Дитятко, если я упоминаю людей, агитирующих за удаление goto из языка, это не значит, что я сам поддерживаю удаление goto из языка. Так что не надо мне тут нотаций читать, они совершенно не к месту.

>>Вне зависимости от того, пишем ли мы в ООП парадигме или в какой-то другой.
> Если нет никакой зависимости, то с чего мне менять машину Тьюринга на
> Си?

Кто тебе сказал, что нет зависимости? Это ещё один пример "смотрю в книгу вижу фигу".

>>С чего вы взяли, что мы взяли, что выход из вечного цикла возможен лишь при нештатных ситуациях?
> В следствии ваших же рассуждений.

One more.

>>Мы говорили о том, что штатная ситуация обрабатывается как нештатная.
> кхммм тут лучше с пример кода пожалуйста, а то мне кажется что
> мы говорит о разном.

Код выше. Цикл, из которого штатный выход выполняется через throw/catch.

>>Штатная ситуация обрабатывается нештатным нелокальным goto.
> что есть нелокальным? Лента в машине Тьюринга - локальна?

Если тебе хочется провести аналогию между C++ и лентой в машине Тьюринга, и посмотреть во что превратиться локальность, то тебе надо говорить о локальности символов на ленте. Но я тебе рекомендовал бы, не привлекать аналогии без нужды. Они могут путаться между ногами и мешать процессу мышления.

>>Страуструп придумал исключения, но причёсанняй longjmp как способ обработки ошибок -- это гумно, и опыт C++ показал, что гумно это не только по каким-то замудрёным теоретическим причинам, типа потому что нарушение принципов структурного программирования, но и по вполне практическим.
> мне было бы очень интересно послушать, что придумали бы вы на месте
> Страуструпа (серьезно). Как можно разрешить данную проблему?

Я давал выше ссылку на статью обсуждающую throw/catch и предлагающую альтернативы. В той статье есть аж три ссылки с возможными реализациями Either. Пока я искал ту статью я нашёл ещё две реализации Result на C++, которые по-сути то же самое, только с другим названием. Гугли.

>>КОП какого процессора?
> Того, который собираетесь использовать. Машина Тьюринга одна (ну есть еще машина Поста
> и т.д.), архитектура того же процессора - одна (Фон Неймановская).

Машина Тьюринга не существует, глупыш. Машина Тьюринга -- целиком и полностью выдумка. Это миф. Сказка. Тьюринг никогда не создавал свою машину в железе, я не уверен что кто-нибудь когда-нибудь создавал её. Машина Тьюринга настолько непрактична, что никто никогда не пытался построить на ней какую-то полезную систему. И уж я совершенно точно не буду писать под машину Тьюринга. Я уж лучше на WebAssembly напишу, который позволяет довольно быструю интерпретацию на любой машине. Но вообще я не люблю интерпретацию, мне бы поближе к железу.

И про "собрался использовать" -- это как-то излишне оптимистично. Я использую вперемешку arm64 и amd64. Мне надо чтобы работало и там, и здесь. Иногда я ещё использую avr, которая кладёт болт на фон-Неймана и вся из себя на гарвадской архитектуре, и мне бы хотелось чтобы мои программы работали бы и там тоже. Мало ли мне вдруг приспичит его на avr'ке погонять.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154 Ответы: #176

176. Сообщение от Sw00p aka Jerom (?), 19-Май-19, 02:40   +/
> Нет, не без разницы. server->accept, вероятно, проводит не только accept на сокете,
> но ещё и "обмен приветствиями" с клиентом, что можно порождать новые
> классы ошибок.

все порождаемые accept "классы" ошибок - описаны, не определенных ошибок нет!


> То есть код, который удаляется сразу после написания? :D

Лучше сразу пулю в висок.

> Знаешь, чем дольше я наблюдаю за людьми цитирующими Гёделя, тем больше я
> прихожу к выводу, что все эти цитаты исключительно от необразованности. Чтобы
> цитировать Гёделя, необходимо не понимать Гёделя.

ок, не образован.


> О, Бога ты тоже не зря упомянул. Вижу догматизм в тебе я,
> и всуе Бога упоминание к лицу тебе.

Догма - аксиома, вспоминаем значение слова.

> Тут ты самым позорным образом путаешь тёплое с мягким. Русский язык предоставляет
> возможность выражаться красиво и точно. То что он при этом предоставляет
> философское матерное подмножество, позволяющее выражаться грязно и неточно -- это другой
> вопрос.

В смысле "философское матерное" подмножество? И дайте определение "грязно" и "неточно". Тот же goto это ПНХ.


> Control flow -- это "течение управления", это то как исполнитель программы движется
> по коду. Если твои словари не объясняют тебе этого, то это
> много говорит нам о никудышнем качестве твоих словарей, и ничего не
> сообщает о control flow, потому что мы знаем больше тебя.

"движется" - движение есть последовательность шагов, и как указал прежде - детерминированность.

> Вот это проявление того самого догматизма.

читаем выше про догму.

> Дитятко, если я упоминаю людей, агитирующих за удаление goto из языка, это
> не значит, что я сам поддерживаю удаление goto из языка. Так
> что не надо мне тут нотаций читать, они совершенно не к
> месту.

а к какому месту упоминание тех самых людей? и тем более которых не поддерживаете. Определитесь уже, я же говорил мне ваши мысли интересней, а не чужие с которыми вы не согласны.

> Кто тебе сказал, что нет зависимости? Это ещё один пример "смотрю в
> книгу вижу фигу".

ну приведите пример зависимости.


> Код выше. Цикл, из которого штатный выход выполняется через throw/catch.

try/catch - не штатный выход.

> Если тебе хочется провести аналогию между C++ и лентой в машине Тьюринга,
> и посмотреть во что превратиться локальность, то тебе надо говорить о
> локальности символов на ленте.

каждый символ на ленте ограничен своей ячейкой, о какой локальности идёт речь?

> Я давал выше ссылку на статью обсуждающую throw/catch и предлагающую альтернативы. В
> той статье есть аж три ссылки с возможными реализациями Either. Пока
> я искал ту статью я нашёл ещё две реализации Result на
> C++, которые по-сути то же самое, только с другим названием. Гугли.

повторюсь "мне было бы очень интересно послушать, что придумали бы ВЫ на месте Страуструпа (серьезно)."

> Машина Тьюринга не существует, глупыш. Машина Тьюринга -- целиком и полностью выдумка.
> Это миф. Сказка.

дальше можно не читать!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175 Ответы: #177

177. Сообщение от Ordu (ok), 19-Май-19, 03:58   +/
> try/catch - не штатный выход.

ДА ЛАДНО! НЕ МОЖЕТ БЫТЬ!

> каждый символ на ленте ограничен своей ячейкой, о какой локальности идёт речь?

Знаешь, мне надоело объяснять. Думай сам. Если тебе хочется, чтобы я за тебя думал, то мы можем обсудить расценки.

> повторюсь "мне было бы очень интересно послушать, что придумали бы ВЫ на
> месте Страуструпа (серьезно)."

В смысле? Ты хочешь чтобы я всё написанное записал бы в виде аудио, чтобы ты мог послушать? (Серьёзно?)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176

178. Сообщение от souryogurt (ok), 19-Май-19, 05:22   +1 +/
Лично мне просто непонятно почему это в новостях на опеннет. Разве это какая-то значимая для open source новость? Можно было бы на форуме ее разместить, если хочется найти своих пользователей или разработчиков, или просто пропиарится для чего-то еще.
Ну и глядя на то, как оформлена репа и личный блог автора, так и тянет тролить. Везде МЫ во всех названиях присутутсвует dmitrygr, и т.д. Доходит до абсурда. Вы только прочитайте в слух первую строчку документации:
"Client programs that use Dmitigr Fcgi must include header file dmitigr/fcgi.hpp. and must link with dmitigr_fcgi (or the debug build - dmitigr_fcgid) if Dmitigr Fcgi is used as a regular library."
Другими словами, неймспейс неоч :)

Бог создал землю за шесть дней. Дмитрий Ингришин создал FastCGI за пять.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150

180. Сообщение от Аноним (39), 19-Май-19, 08:57   +/
>>Бред, по определению, девиация мышления на фоне деменции. И есть, Петька, один нюанс. Оппонент твой  сменился. Ты пишешь про обязанности не автору. Могу ещё сыграть в того самого клоуна. Ты только как следует попроси.
> Клоун, мне без разницы на то кто ты.

Знаю. Ты ошибся адресатом, что лишает персонализированные обращения смысла, но для тебя это ничего не меняет. Плоды фантазии безусловно верны для бредящего.

> Опять нырнул в дерьмо.

Смотри, не задохнись. Зачем ты вообще это делаешь?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169

182. Сообщение от Аноним (4), 19-Май-19, 12:43   +2 +/
чушь. при СССР технари к технарям оч.хорошо относились. почитайте сообщения на форумах/эхах 90х годов (это как раз поколение выросшее в СССР) - все оч вежливо, никакой ругани, ехиндичиства и т.д.

те, о ком вы говорите совсем другое поколение.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #183

183. Сообщение от eRIC (ok), 19-Май-19, 16:42   +2 +/
> те, о ком вы говорите совсем другое поколение.

ну я как раз имел в виду не технарей, которые в годы СССР работали, а последствия распада СССР, приходом демократии, и приходом диванных критиков :)


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182 Ответы: #191

186. Сообщение от Аноним (186), 19-Май-19, 18:06   –1 +/
>>>> Зачем ты, клоун, пытаешься защищать свою жопу
>>> Веришь ли, но в природе это норма. Пока мы жили на деревьях,
>>> для таковой защиты имелся даже специальный орган -- хвост. Потом появились
>>> разум, этикет, одежда.
>> И когда же вы жили на деревьях?
> До момента пока не изрёк Господь Бог "сотворим человека по образу Нашему
> и по подобию Нашему".

Креационизм ничем не хуже утверждений, что хвост предки человеков потеряли из-за появления разума, этикета и одежды.
Кстати, уже давно считается, что у человеков и бибизьян был общий предок. Так же известно, что далеко не все бибизьяны живут на деревьях.
Строение человеческой стопы и отсутсвие хвоста, как бы, намекают немного сведующим в биологии, где именно жили предки человеков.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118

187. Сообщение от KonstantinB (ok), 19-Май-19, 19:00   +/
В тот момент, в какой вы этот код напишете.

Подставьте вместо true свое условие, соответствующее архитектуре вашего сервера. Это, блин, миниальный пример использования из readme, а не production ready решение.

Production ready решение - это, знаете ли, такая штука, которая пишется самостоятельно, а не копипастится с README.md и StackOverflow.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

188. Сообщение от runoverheads (ok), 20-Май-19, 00:03   +1 +/
200019
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79

189. Сообщение от Аноним (189), 20-Май-19, 01:03   +2 +/
>В каком плане? Насколько я понимаю fcgi это такой плебейский ipc

Понимание уровня "не читал, но осуждаю"

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #192

190. Сообщение от Аноним (189), 20-Май-19, 01:13   +/
>Делая выводы можно сказать что она как алтернативная реализация по спецификации FastCGI придаст прирост в производительности, легкости и т.д., что позволяет дать современные последние версии компиляторы c поддержкой C++17 (ведь язык программирования C++ тоже не стоит на месте и совершенствуется)

Трудно представить, какой приницпиальный выигрыш в производительности может быть у реализации FastCGI на С++ по сравнению с С, не говоря у же о С++17 по сравнению со старым С++. Там же простой бинарный протокол, который парсится обычными сишными структурами

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

191. Сообщение от Аноним (189), 20-Май-19, 01:16   +2 +/
Поколение Пепси
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #183 Ответы: #195, #202

192. Сообщение от RibiKukan (ok), 20-Май-19, 04:15   +/
С чего вдруг, клоун? Я тут не обсуждаю fcgi, а обсуждаю говнокод. Что там автор пытался реализовать - меня волновать не должно. К тому же, для того, что-бы критиковать какое-то говно - мне нужно значить ничего о нём. fcgi по умолчанию является говном. Есть базовая классификация. Если что-то попадает в класс говна, то абсолютно неважно какое это говно. Зелёное, синие и как оно воняет. Факт остаётся фактом.

В классификации я не ошибся. Ты можешь попытаться со мною поспорить, но обделаешься тут же.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #189 Ответы: #193, #194

193. Сообщение от superkullhacker1997 (?), 20-Май-19, 09:59   +/
и как тебе не надоело.... напрасно ты тратить свое время... многие годы   ты пытаешься чтото там донести до публики разных форумов, изображая из себя эксперта но тщетно... никто тебя не слышит и всем твои комментарии побоку... посмеялись и забыли... астанавись..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #192

194. Сообщение от Аноним (194), 20-Май-19, 11:56   +/
>  обсуждаю говнокод.
> что-бы критиковать какое-то говно
> fcgi по умолчанию является говном.
> Если что-то попадает в класс говна, то абсолютно неважно какое
> это говно. Зелёное, синие и как оно воняет. Факт остаётся фактом.  
> обделаешься тут же.

О! Неужели Царь-Батюшка вернулся и опять несет фекалии в массы?


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #192

195. Сообщение от eRIC (ok), 20-Май-19, 13:35   +1 +/
> Поколение Пепси

точно +1

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191

196. Сообщение от Георг (?), 20-Май-19, 18:52   +1 +/
Ближайший будет красный-коричневый-серый-коричневый-зелёный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

197. Сообщение от Аноним (121), 20-Май-19, 20:07   +/
Во-первых, топик про FastCGI. Во-вторых, где libevent, а где cppcms.. В последней есть всё для создания полноценного web-бэкенда (транспорт, маршрутизация запросов на исполняющий код, пулы рабочих потоков, сессии и сопутствующие шифрование и hmac-и, json, журналирование и проч.), и оно уже на плюсах и используется в проде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132

198. Сообщение от Аноним (198), 22-Май-19, 06:40   +/
You must be new here.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118

199. Сообщение от Michael Shigorinemail (ok), 22-Май-19, 12:43   +/
> Советую к прочтению:
> en: http://paulgraham.com/disagree.html
> ru: https://web.archive.org/web/20120505004501/http://translated...

Спасибо за статью Полу, а Вам -- за ссылку!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

200. Сообщение от Аноним (49), 23-Май-19, 11:16   +/
Замыканий лучше коротких.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #201

201. Сообщение от Andrey Mitrofanov (?), 23-Май-19, 11:24   +/
> Замыканий лучше коротких.

Вот про размер не надо.

Разыменовыватели буферов и разграничители указаетелей обидятся же.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #200

202. Сообщение от Аноним (49), 23-Май-19, 11:55   +/
А сейчас смузи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191

204. Сообщение от greenwar (ok), 13-Май-20, 10:15   +/
забота о пользователе зашкаливает...
>> CMake Error at CMakeLists.txt:5 (cmake_minimum_required):
>>  CMake 3.17 or higher is required.  You are running version 3.13.4
>> sudo apt install cmake
>> Уже установлен пакет cmake самой новой версии (3.13.4-1).

(debian buster)

Ответить | Правка | Наверх | Cообщить модератору

205. Сообщение от greenwar (ok), 13-Май-20, 10:22   +/
3.17 это самая последняя версия cmake на офф.сайте (3.17.2)
её только вручную ставить
чё без cmake никак чтоли не поставить это чудо инженерной мысли?
Ответить | Правка | Наверх | Cообщить модератору

206. Сообщение от greenwar (ok), 13-Май-20, 11:34   +/
а это чё:
>> /usr/bin/ld: /tmp/ccf5Ifs9.o: in function `main':
>> fcgi-hello.cpp:(.text+0x52): undefined reference to `dmitigr::fcgi::Listener_options::make(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, int, int)'
>> /usr/bin/ld: fcgi-hello.cpp:(.text+0x11d): undefined reference to `dmitigr::fcgi::crlfcrlf(std::ostream&)'
>> collect2: error: ld returned 1 exit status

при попытке скомпилировать dmitigr/fcgi/test/fcgi/fcgi-hello.cpp

Ответить | Правка | Наверх | Cообщить модератору


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру