надо просто указать эти две папки компилятору при сборке

в мейкфайле?

в мейкфайле?

Угу

щас попробую

а можно сюда скинуть makefile?

а то я чет не нахожу там

(

Да кидай

Допиши нужные пути в переменные окружения LDFLAGS и CXXFLAGS Там в мейкфайле даже намёки есть: LDFLAGS can be specified on the make command line

make CXXFLAGS=-I/usr/local/include/boost_1-37 LDFLAGS=-L/usr/local/lib/boost-что-то-там

спасибо, щас попробую

Всем привет! Подскажите, пжл, здесь можно постить вакансии?

Привет.

Есть отдельный канал.

Есть отдельный канал.

покажите, плиз

Вот https://t.me/ProCxxJobs

Для публикации туда обращайтесь к @AlexFails

спасибо!

интересно, тут больше hr'ов или программистов?

hrограмистов.

Хареографистов.

Архитектурный вопрос который слегка касается и C++: есть ли у event loop'а преимущество перед green thread'ами (такими как в Golang / Erlang etc.) единственное мне известное преимущество event loop'а это отсутствие конкуррентного программирования, т.е. ручной синхронизации а ещё есть?

В golang и тем более в erlang тоже можно без ручной синхронизации. А внутри все равно event loop или что-то похожее.

Блокирование event loop-а лечится через work stealing. В golang горутины точно так же друг друга могут блокировать

интересно, тут больше hr'ов или программистов?

думаю что прогеров

Тут меня попросили выложить опрос. Думаю, что будет интересно всем. Вот дословная цитата (орфографию поправил): "Месяц назад мы в Digital Banana задались вопросом: откуда берутся программисты, и какой у них бэкграунд? В поисках ответа мы начали разработку социологического исследования по этой теме. Выпустив предварительную версию и получив конструктивную критику от коллег по индустрии, мы представляем итоговую версию опроса. На прохождение опроса нужно потратить 10-15 минут. Ссылка на опрос: https://goo.gl/9Xr9bJ Задачи опроса: - понять, когда люди начали изучать программирование; - как относятся к разным видам образовательных инициатив; - как оценивают роль высшего образования; - как относятся (и владеют) математикой в программировании; - зависит ли мнение по этим вопросам от разницы поколений и статуса разработчика (начинающий, средний, старший)". Если у вас есть какие-то замечания или предложения по улучшению теста – пишите мне, @AlexFails, и я передам авторам. #survey

/msglink

Тут меня попросили выложить опрос. Думаю, что будет интересно всем. Вот дословная цитата (орфографию поправил): "Месяц назад мы в Digital Banana задались вопросом: откуда берутся программисты, и какой у них бэкграунд? В поисках ответа мы начали разработку социологического исследования по этой теме. Выпустив предварительную версию и получив конструктивную критику от коллег по индустрии, мы представляем итоговую версию опроса. На прохождение опроса нужно потратить 10-15 минут. Ссылка на опрос: https://goo.gl/9Xr9bJ Задачи опроса: - понять, когда люди начали изучать программирование; - как относятся к разным видам образовательных инициатив; - как оценивают роль высшего образования; - как относятся (и владеют) математикой в программировании; - зависит ли мнение по этим вопросам от разницы поколений и статуса разработчика (начинающий, средний, старший)". Если у вас есть какие-то замечания или предложения по улучшению теста – пишите мне, @AlexFails, и я передам авторам. #survey

Message N° 103337

**Наши чаты** @supapro - чат для новичков; @ProCxxNews - новости и мероприятия; @ProCxxChannel - небольшие заметки и ссылки; @ProCxxJobs - канал с вакансиями; @fludpac - флудилка. Текущая инфа: Опрос - https://telegram.me/ProCxx/103337

/msglink

о, ответил, спасибо :)

Кому не влом, поковыряйте Beast и напишите ревью своё на эту либу

этим вы неплохо поможете Винни

https://github.com/vinniefalco/Beast

Кому не влом, поковыряйте Beast и напишите ревью своё на эту либу

давно хочу) руки пока не доходят)

Кому не влом, поковыряйте Beast и напишите ревью своё на эту либу

код ревью?

код ревью?

да

как раз сейчас идёт: 1-10 июля

А http/2 там планируется?

Кому не влом, поковыряйте Beast и напишите ревью своё на эту либу

куда писать-то?

А http/2 там планируется?

да

куда писать-то?

делаешь ревью, пишешь красивое письмо в boost mailing list

с ревью несложно, с почтой я дружу от слова никак

С темой примерно такой: [boost][beast] Review

ебнутая технология из 1970-х

с ревью несложно, с почтой я дружу от слова никак

можешь оформить в .odt какой-нибудь, сам зашлю от твоего имени

окей

какого рода письмо нужно, типа вот тут тут и тут хорошо, а вот тут спорно написано и лучше переделать?

а есть пример грамотно оформленного ревью?

сейчас скину

This is my review of the Beast library. I. DESIGN —------- The design of the library is very good and appears mature. The concepts are well specified, well documented, well thought out. The use of concept checks is a nice touch and a mark of professionalism. I think that basing the library on ASIO (resp. the Networking TS) is a fine decision. This does mean that if one finds an ASIO/NetTS concept less than ideal, one has to live with it, but that's an acceptable tradeoff. Severing the ties with ASIO based on the yet-hypothetical "structured blobs in, structured blobs out" model may sound good in theory, but in practice, a supermajority of the potential users of Beast need to produce a working HTTP or Websocket server, and the library as it stands addresses this need. The design is not perfect; at times the library makes it much too easy for asymptomatic mistakes to be introduced by the omission of a required member function call. For example, if one forgets to set the Content-Length, everything will still appear to work; or if one forgets to initialize the .result of the response, it remains uninitialized. (Note that these, and subsequent, observations appertain to the library as submitted for review; they may no longer be relevant since the author is very quick with the fixes.) There is, at times, unnecessary verbosity, even in the two storefront examples in http://vinniefalco.github.io/stage/beast/review/beast/quick_start.html that are supposed to show the library in the best possible light. For instance, // Set up an HTTP GET request message http::request<http::string_body> req; req.method(http::verb::get); req.target("/"); req.version = 11; Every request will need a method and a target, so having to call members to set them feels unnecessary. A constructor ought to have been provided. Similarly, in the next example, // WebSocket says that to close a connection you have // to keep reading messages until you receive a close frame. // Beast delivers the close frame as an error from read. // beast::drain_buffer drain; // Throws everything away efficiently for(;;) { // Keep reading messages... ws.read(drain, ec); // ...until we get the special error code if(ec == websocket::error::closed) break; // Some other error occurred, report it and exit. if(ec) return fail("close", ec); } the drain loop is basically a requirement for every correct program, so it should have been encapsulated into a helper function. (Even though the example as written does illustrate the use of a drain_buffer.) I'm not particularly fond of the design decision to declare parts that in practice every user of the library will need as "out of scope". People should not be made to reinvent these wheels. I understand the aim of producing a standard library proposal, and that some of these wheels would not be suitable for standardization, but there's nothing easier than just including the suitable wheels in the formal proposal and omitting the unsuitable ones. In practice, these necessary parts end up as examples, so one has to #include "../example/wheel.hpp" instead of "beast/wheel.hpp". It would be better, in my opinion, if one includes, say, "beast/ext/wheel.hpp", with it being known that ext/ is where "out of scope" things go. The ASIO coupling did leave me with one question, whether it would be possible for the library to accommodate OS-specific file to socket transfers such as the one provided by TransmitFile: https://msdn.microsoft.com/en-us/library/windows/desktop/ms740565(v=vs.85).aspx The idea here is that the OS kernel can dump the file to the socket without involving user mode, which has the potential of much increased performance. For the median user, this would not make much of a difference, but it's an interesting design question, and perhaps an argument that the example file_body class ought to be part of the library proper. ("Is in scope", to use the preferred terminology.) II. IMPLEMENTATION —----------------

I did not pay close attention to the implementation. A random sampling reveals that it's professionally written, and it appears to work, which is good enough for me. The tests run when b2 is invoked in test, have good coverage, and pass with MSVC 14.0 and 14.1. Travis/Appveyor are put to good use. The library provides a doc/Jamfile, which is a plus, but this Jamfile fails, which is a minus. The file reference.qbk has its own separate build script, and this would need to be fixed one way or another when the library is integrated into the Boost documentation build. III. DOCUMENTATION —---------------- The documentation is good. The non-reference parts are very good, the examples are informative. The reference is very good at times, and not so much at others. This is caused by the fact that to get to the good parts one needs to drill down a level or two. For instance, looking at http://vinniefalco.github.io/stage/beast/review/beast/quickref.html I noticed the "async_teardown" function in the WebSocket section, so I clicked on it to see if I need to call that to tear down a WebSocket connection. This lead me to http://vinniefalco.github.io/stage/beast/review/beast/ref/beast__websocket__async_teardown.html which only says "Start tearing down a boost::asio::ssl::stream/connection/boost::asio::ip::tcp::socket." Googling told me that I'm not the only one left not entirely satisfied with these descriptions: https://github.com/vinniefalco/Beast/issues/274 The confusion here stems from the fact that would I, and the issue submitter, have clicked on one of the async_teardowns in that page, we would have reached f.ex. http://vinniefalco.github.io/stage/beast/review/beast/ref/beast__websocket__async_teardown/overload1.html which is indeed fine, and mentions that the implementation calls this function, not the user. This is a general pattern with the reference. The leaves are perfectly fine, but the upper levels are often uninformative. IV. PRACTICAL USE —--------------- As part of conducting this review, I ported two existing servers of mine to Beast, one HTTP, one WebSocket. The HTTP server can be seen at https://github.com/pdimov/beast_tpc_server and the WebSocket one is at https://github.com/pdimov/beast_ws_async_server The experience was pleasant and things went more or less as expected, with virtually no nasty surprises. The author was very helpful. The library proper worked exactly as advertised, and the servers were both easier to write than the originals, and became more robust. I only wish that more out of scope things (target parser, basic authorization handling) become in-scope, because their absence is being felt. V. VERDICT —------— Beast should be ACCEPTED. It's useful, it works, it serves a legitimate need, and I see no design or implementation problems that would preclude acceptance.

Вот неплохое review от Peter Dimov

> asymptomatic mistakes whaa

Вот неплохое review от Peter Dimov

я могу просто +1 его ревью, все очень четко изложено

я могу просто +1 его ревью, все очень четко изложено

не всё

It's useful, it works, слишком обстрактно для чего useful и в каких случаях works

я могу просто +1 его ревью, все очень четко изложено

Если что-то находите и есть, что дополнить, то просто в его треде отправьте письмо с поправками

It's useful, it works, слишком обстрактно для чего useful и в каких случаях works

ну очевидно, в тех самых случаях в которых Петр его применил

это его личное ревью

Может глупость спрошу, но почему не используются какие-то иструменты для review? Даже жуткий gerrit наверное был бы удобнее чем ревью через почту? Не сочтите за хипстерство, просто интересно.

It's useful, it works, слишком обстрактно для чего useful и в каких случаях works

как только ты найдешь случай в котором для тебя не сработает - напиши

Может глупость спрошу, но почему не используются какие-то иструменты для review? Даже жуткий gerrit наверное был бы удобнее чем ревью через почту? Не сочтите за хипстерство, просто интересно.

это не ревью кода по строчкам

ERROR: S client not available

общие впечатления от библиотеки писать в такой уродский тул как геррит чо то мнэ

это не ревью кода по строчкам

Ревью архитектуры и концепции? Но ведь кусочки кода там присутствуют

Может глупость спрошу, но почему не используются какие-то иструменты для review? Даже жуткий gerrit наверное был бы удобнее чем ревью через почту? Не сочтите за хипстерство, просто интересно.

иструменты для review это зашквар если у тебя ревью не каждый день как часть работы

как только ты найдешь случай в котором для тебя не сработает - напиши

хорошо, йа б напеййсал

иструменты для review это зашквар если у тебя ревью не каждый день как часть работы

передергиваешь небось

общие впечатления от библиотеки писать в такой уродский тул как геррит чо то мнэ

какой бесплатный тул лучше чем геррит?

какой бесплатный тул лучше чем геррит?

да тот же гитхаб

да тот же гитхаб

ну а если внутри конторы

проприетарщина

какой бесплатный тул лучше чем геррит?

Phabricator

фабрикатор норм, гитхаб энтерпрайз норм

спс почитаю

фабрикатор не только для код ревью хорош

там полный стек тулов

Может глупость спрошу, но почему не используются какие-то иструменты для review? Даже жуткий gerrit наверное был бы удобнее чем ревью через почту? Не сочтите за хипстерство, просто интересно.

следует различать ревью самого кода и ревью либы в целом

следует различать ревью самого кода и ревью либы в целом

Это понятно. А ревью кода как в boost происходит?

Это понятно. А ревью кода как в boost происходит?

ну мы в Boost.Algorithm используем гитхабовские штуки

в бусте же нет thread safe коллекций?

в бусте же нет thread safe коллекций?

Concurrent что ли?

есть lock_free даже

ага

http://www.boost.org/doc/libs/1_64_0/doc/html/lockfree.html

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

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

сделай сам из очереди

да не, я заюзал https://msdn.microsoft.com/en-us/library/hh750089.aspx

ооооох, сколько там возможностей выстрелить себе в ногу из ракетницы...

ооооох, сколько там возможностей выстрелить себе в ногу из ракетницы...

в ногу, не в голову)

The concurrent_queue provides iterators that are not concurrency-safe.

The concurrent_queue provides iterators that are not concurrency-safe.

ахахаахахх, просто генитально ?

Operations that modify the value of existing elements are not concurrency-safe.