Ты же транк собираешь?

Ага, сейчас вот пробовал

Ага, сейчас вот пробовал

что падает? llvm, clang, что-то ещё?

что падает? llvm, clang, что-то ещё?

clang, но похоже это я кривой, там же по отдельности надо обновлять каждую репу, получается, да?) чертов svn..

clang, но похоже это я кривой, там же по отдельности надо обновлять каждую репу, получается, да?) чертов svn..

да, конечно

clang, но похоже это я кривой, там же по отдельности надо обновлять каждую репу, получается, да?) чертов svn..

с GIt тоже самое

Отдельно: llvm, clang, compiler-rt, libc++, openmp, tests, ещё что-то

у гита я хоть синтаксис и команды помню)

GUI one love

осталось помнить по каким подпапкам раскиданы подпроекты llvm/tools/clang llvm/projects/compiler-rt llvm/projects/openmp llvm/projects/libcxx llvm/projects/libcxxabi ...

Отдельно: llvm, clang, compiler-rt, libc++, openmp, tests, ещё что-то

а могли бы самбодулями подключить, и все было бы проще

а могли бы самбодулями подключить, и все было бы проще

могли бы....

осталось помнить по каким подпапкам раскиданы подпроекты llvm/tools/clang llvm/projects/compiler-rt llvm/projects/openmp llvm/projects/libcxx llvm/projects/libcxxabi ...

ну там на странице getting started всё написано

просто заходишь и смотришь. а не хочешь запоминать - просто скрипт накидал и ок

Всем привет. Мб вопрос для sup скорее. Почему многие ругают MSVC? Из-за чего msvc тормозит с вводом фич из свежих стандартов?

(это из своего опыта, на моём ноуте хромиум ~5 часов собирался, но у меня нет SSD, только 12ГБ оперативы)

у меня как-то всю ночь собирался

Всем привет. Мб вопрос для sup скорее. Почему многие ругают MSVC? Из-за чего msvc тормозит с вводом фич из свежих стандартов?

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

Это по поводу фич. А не любят из-за того, что там не настоящий цпп.

Всем привет. Мб вопрос для sup скорее. Почему многие ругают MSVC? Из-за чего msvc тормозит с вводом фич из свежих стандартов?

старые версии компилятора - це просто ужас был. сейчас всё стало намного лучше

по колву фичей сейчач msvc довольно неплох, хочу так сказать. но вот код он оптмизирует плоховато

могли бы....

Я помню у меня всё вообще без проблем взлетело...

Я помню у меня всё вообще без проблем взлетело...

ну у меня тоже ?

Всем привет. Мб вопрос для sup скорее. Почему многие ругают MSVC? Из-за чего msvc тормозит с вводом фич из свежих стандартов?

Потому что они не могут просто взять и выбросить обратную совместимость)

Всем привет. Мб вопрос для sup скорее. Почему многие ругают MSVC? Из-за чего msvc тормозит с вводом фич из свежих стандартов?

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

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

Здравствуйте. А существует ли стандартный способ упаковки структур в современных версиях стандарта C++? Большую часть времени программировал только под Windows. И для упаковки использовал конструкции вида: #pragma pack(push, 1) struct Foo { }; #pragma pack(pop) Знаю, что в gcc для этой цели используется аттрибут: attribute((packed)) Но вот до сих пор не нашел информации о единой стандартной конструкции для записи упакованных структур. Может есть Proposal'ы на эту тему?

Здравствуйте. А существует ли стандартный способ упаковки структур в современных версиях стандарта C++? Большую часть времени программировал только под Windows. И для упаковки использовал конструкции вида: #pragma pack(push, 1) struct Foo { }; #pragma pack(pop) Знаю, что в gcc для этой цели используется аттрибут: attribute((packed)) Но вот до сих пор не нашел информации о единой стандартной конструкции для записи упакованных структур. Может есть Proposal'ы на эту тему?

pragma вроде вполне себе решение а так есть ещё union, правда не уверен, что с ним будут гарантии

А pragma pack push/pop поддерживается в компиляторах gcc и clang? Если да, то они имеют такое же поведение, как в msvc?

Т.е. поля структуры с типами разных размеров будут упакованы заподряд друг за другом без вставки лишних байт компилятором - при pragma pack(push, 1)?

Т.е. поля структуры с типами разных размеров будут упакованы заподряд друг за другом без вставки лишних байт компилятором - при pragma pack(push, 1)?

Alingas ключевое слово с 11 стандарта

Alingas ключевое слово с 11 стандарта

хм, это разве поможет?

А, не, похоже я наврал, он к самому алайну объекта в,не к внутренностям

хм, это разве поможет?

Похоже нет)

А pragma pack push/pop поддерживается в компиляторах gcc и clang? Если да, то они имеют такое же поведение, как в msvc?

Да ето так

Почитал про alignas, да это что-то другое. Как я понял, это ключевое слово не говорит компилятору порядок расположения в памяти, а просто сделать их выровненными по заданной границе. И в примере на cppreference - alignas(1) от структуры с другим выравниванием приведет к ошибке, если я правильно понял

Да ето так

Спасибо

Сообщите, когда в си введут классы и two phase name lookup

Всё равно не понимаю, почему ODR это проблема именно в контексте intrusive_ptr. Точно так же можно например операторы перегружать для incomplete типов. С intrusive_ptr_add_ref/release скорее всего даже меньше проблем, т.к. перегрузок не будет, в иерархии наследования подсчёт ссылок только на одном уровне (скорее всего most base).

Всем привет. Мб вопрос для sup скорее. Почему многие ругают MSVC? Из-за чего msvc тормозит с вводом фич из свежих стандартов?

Потомучто они си++11 запилили в 2017

Здравствуйте. А существует ли стандартный способ упаковки структур в современных версиях стандарта C++? Большую часть времени программировал только под Windows. И для упаковки использовал конструкции вида: #pragma pack(push, 1) struct Foo { }; #pragma pack(pop) Знаю, что в gcc для этой цели используется аттрибут: attribute((packed)) Но вот до сих пор не нашел информации о единой стандартной конструкции для записи упакованных структур. Может есть Proposal'ы на эту тему?

Нет

Здравствуйте. А существует ли стандартный способ упаковки структур в современных версиях стандарта C++? Большую часть времени программировал только под Windows. И для упаковки использовал конструкции вида: #pragma pack(push, 1) struct Foo { }; #pragma pack(pop) Знаю, что в gcc для этой цели используется аттрибут: attribute((packed)) Но вот до сих пор не нашел информации о единой стандартной конструкции для записи упакованных структур. Может есть Proposal'ы на эту тему?

Более того, в большинстве случаев пакинг используется для уб, так что....

Более того, в большинстве случаев пакинг используется для уб, так что....

А что такое уб? Undefined Behaviour? А можно поподробнее?

Есть самописный сервер на сокетах использующий openssl. Иногда вылетает исключение failed accept connection, и заполняет экран сверху до низу. В этот момент сервер становится недоступен, помогает только прерывание. Вопрос: как сбросить соединение с клиентом чтобы он ддосил? while (1){ sin_len = size_of(sin); if((netfd = accept (listen_fd), (struct sockaddr*)&sin, sin_len))<0){ fprint(stderr, "failed accept connection"); continue; } }

Всем привет. Мб вопрос для sup скорее. Почему многие ругают MSVC? Из-за чего msvc тормозит с вводом фич из свежих стандартов?

Где-то на reddit разработчик microsoft объяснял, что они в первую очередь делают нововведения для удовлетворения потребностей их собственных разработок и очень сильно парятся по поводу совместимости (типа, у них до сих пор якобы очень много кода тридцатилетней давности). Поэтому всего самого свежего от них ждать никогда не стоит.

У них просто даже 1% пользователей — это супермного, поэтому и потеют

Alingas ключевое слово с 11 стандарта

Каждый раз делаю эту ошибку: пытаюсь найти, а не появилось ли в стандарте аналога этих прагм, вижу alignas, радуюсь, потом читаю про него и расстраиваюсь :(

таким образом, линия разграничения проводится по особенностям Deleter и (не)поддержке weak_ptr

Можно

Всё равно не понимаю, почему ODR это проблема именно в контексте intrusive_ptr. Точно так же можно например операторы перегружать для incomplete типов. С intrusive_ptr_add_ref/release скорее всего даже меньше проблем, т.к. перегрузок не будет, в иерархии наследования подсчёт ссылок только на одном уровне (скорее всего most base).

Я бы не рекомендовал перегружать операторы по incomplete типам

Я бы не рекомендовал перегружать операторы по incomplete типам

Не перегрузка же, просто декларация.

Где-то на reddit разработчик microsoft объяснял, что они в первую очередь делают нововведения для удовлетворения потребностей их собственных разработок и очень сильно парятся по поводу совместимости (типа, у них до сих пор якобы очень много кода тридцатилетней давности). Поэтому всего самого свежего от них ждать никогда не стоит.

То есть если хочется свежих стандартовв VS надо мучиться с подключением clang?

Не перегрузка же, просто декларация.

Forward декларации для того и нужны чтобы определить сигнатуру функций. А уж потом дело линковщика связать их с реализацией и убедиться в ее единственности.

Мб я ошибаюсь, но там же из коробки старая версия

Forward декларации для того и нужны чтобы определить сигнатуру функций. А уж потом дело линковщика связать их с реализацией и убедиться в ее единственности.

Вот только когда трейты на инкомплит тайпы вешаются, такие чудеса могут начаться

они его не будут обновлять

Вот только когда трейты на инкомплит тайпы вешаются, такие чудеса могут начаться

какие чудеса, например?

какие чудеса, например?

учитывая, что если трейт по комплит и инкомплит пойдет в разные стороны, то gg или сверху хоть в одном месте is_detected повиснет - любые

вот это один из моих любимых примеров, правда, немного про другое

https://godbolt.org/g/FifQ9Q

ну тут же перегрузка функции, а не треиты

(Rant) Лямбды и вывод типов в С++ ужасны. Не позволяют делать нормальное ФП без приседаний. Хочется сделать DO-нотацию по мотивам этого: https://github.com/evgeny-panasyuk/monad_do/blob/master/proof_of_concept.cpp Но она ломается на моей монаде либо о невозможность правильно вывести возвращаемый тип , либо о невозможность каста лямбды к std::function по причинам, которые мне кажутся просто недоработкой в языке.

А можно нескромный вопрос, а зачем делать монады на c++, когда он и так последовательно вычислимый сам по себе?

Монады и do-нотаций в том же Хаскелле нужны, чтобы примешивать поведение через трансформеры и чтобы иметь что-то вроде привычных переменных.

Но в плюсах это и так уже есть. Зачем еще раз дополнительно тащить механизм из языка с другой парадигмой?

учитывая, что если трейт по комплит и инкомплит пойдет в разные стороны, то gg или сверху хоть в одном месте is_detected повиснет - любые

Ну может именно поэтому intrusive ptr не через traits а через ADL сделаны. В ветке наследования ref counting только в одном месте, т.е. по типу должно разрешаться однозначно. Достаточно реализовать его в базе и будет работать для всех наследников, а с traits всё сложнее.

Ну может именно поэтому intrusive ptr не через traits а через ADL сделаны. В ветке наследования ref counting только в одном месте, т.е. по типу должно разрешаться однозначно. Достаточно реализовать его в базе и будет работать для всех наследников, а с traits всё сложнее.

Вы не думаете что ваши собеседники могут не быть идиотами? ADL в любом случае будет, без него вообще внешние методы дергать нельзя.

Вы не думаете что ваши собеседники могут не быть идиотами? ADL в любом случае будет, без него вообще внешние методы дергать нельзя.

Но traits != ADL.

Но traits != ADL.

В том смысле что intrusive_ptr мог бы дергать что-то типа intrusive_traits<T>::addref.

И кстати, слабая связанность подсчёта ссылок с самим intrusive ptr позволяет забирать у него владение и например дружить с семейством intrusive контейнеров. Вроде intrusive_list<Foo, opt:: intrusive_counted>.

Но traits != ADL.

Ну то есть вы собриаетесь работать со всем этим без любой возможной проверки концептов

А можно нескромный вопрос, а зачем делать монады на c++, когда он и так последовательно вычислимый сам по себе?

Для того, чтобы обобщать всякие извращения, которых до сих пор нет в стандарте — всякие там co_await и иже с ними.

В них стандартного «последовательного выполнения» уже не хватает!

Монады и do-нотаций в том же Хаскелле нужны, чтобы примешивать поведение через трансформеры и чтобы иметь что-то вроде привычных переменных.

Это не главная мотивация монад сегодня. Позвольте пояснить. Изначально в Хаскеле был странный и неудобный способ делать эффекты. Все из-за него страдали, и он ощущался как костыль. Потом пришел Вадлер и товарищи, и они придумали, что тут очень подходит концепция монад из некоей математической теории. Попробовали применить, - пришлось переосмыслить, что есть чистое и нечистое в Haskell. Придумали "RealWorld" как некое немутабельное состояние, над которым эта монада (IO) бы работала. Потом придумали do-нотацию, чтобы сократить запись. А потом началось. Люди поняли, что монады - гораздо более полезный инструмент, чем просто обслуживать цепочку вычислений с эффектами ввода-вывода. Оказалось, что они эффективно выражают различные концепции, такие как состояние, а do-нотация еще и делает код кристально чистым. И монады стали ценны не потому, что они закрывают какую-то там дыру в дизайне Haskell, а потому, что являются мощной абстракцией, паттерном если хотите, который упрощает код в разы. Так, с их помощью можно избавиться от callback hell, можно сделать асинхронные вычисления не хуже, чем с async / await, которые в других языках являются частью синтаксиса. Можно хэндлить ошибки в цепочке операций (Either; в C++ это std::expected), можно явно выражать отсутствующее значение (Maybe; в С++ это std::optional), и тоже связывать операции-возможно-без-значения в цепочку, не перегружая код. А в последствии еще увидели, что с помощью монад можно делать полный аналог Dependency Injection. И нет, иметь переменные - это не мотивация для монад в Haskell. Зачем это в С++? По тем же причинам. С помощью монад упрощается код, который ранее мы бы писали очень развесисто. Посмотрите, например, на Go-шников с их вездесущей проверкой результата на err. И хотя в С++ есть исключения, возврат ошибок все же используется, и вот такой код может быть значительно упрощен для чтения и понимания с помощью монады. С помощью монад можно писать более надежный и предсказуемый код. Там, где обычный набор инструкций позволяет допустить ошибку по невнимательности, например, программист не обработал результат функции, монадический код это не позволит. Просто потому, что проверка результата функции будет вшита в конкретную монаду (std::optional, std::expected), и потому "пройти мимо" уже будет нельзя. Или взять std::future. С помощью монадического связывания очень легко пишется такой код, где таски будут вычисляться либо одна за одной, либо параллельно: программист, оперируя монадическими функциями, выбирает, что ему нужно. При этом ему не нужно специально писать, какую фьючу когда надо дождаться, где синхронизоваться и куда передать дальше. Он просто пишет монадический код, а соответствующая монада возьмет эти манипуляции на себя и сделает их "в бэкграунде". Это очень удобно, так как по сути, программист лишь работает со своей вычислительной моделью, которая не "загрязнена" деталями от std::future. На дворе 2018 год. Без монад уже нельзя, потому что более мощной и полезной абстракции еще не рождалось за последнее двадцать лет.

Монады и do-нотаций в том же Хаскелле нужны, чтобы примешивать поведение через трансформеры и чтобы иметь что-то вроде привычных переменных.

Помимо этого, похоже, что ты под монадами имеешь в виду только IO и ST, а есть и другие варианты их применения (допускаю, впрочем, что они менее интересны в контексте C++).

Это не главная мотивация монад сегодня. Позвольте пояснить. Изначально в Хаскеле был странный и неудобный способ делать эффекты. Все из-за него страдали, и он ощущался как костыль. Потом пришел Вадлер и товарищи, и они придумали, что тут очень подходит концепция монад из некоей математической теории. Попробовали применить, - пришлось переосмыслить, что есть чистое и нечистое в Haskell. Придумали "RealWorld" как некое немутабельное состояние, над которым эта монада (IO) бы работала. Потом придумали do-нотацию, чтобы сократить запись. А потом началось. Люди поняли, что монады - гораздо более полезный инструмент, чем просто обслуживать цепочку вычислений с эффектами ввода-вывода. Оказалось, что они эффективно выражают различные концепции, такие как состояние, а do-нотация еще и делает код кристально чистым. И монады стали ценны не потому, что они закрывают какую-то там дыру в дизайне Haskell, а потому, что являются мощной абстракцией, паттерном если хотите, который упрощает код в разы. Так, с их помощью можно избавиться от callback hell, можно сделать асинхронные вычисления не хуже, чем с async / await, которые в других языках являются частью синтаксиса. Можно хэндлить ошибки в цепочке операций (Either; в C++ это std::expected), можно явно выражать отсутствующее значение (Maybe; в С++ это std::optional), и тоже связывать операции-возможно-без-значения в цепочку, не перегружая код. А в последствии еще увидели, что с помощью монад можно делать полный аналог Dependency Injection. И нет, иметь переменные - это не мотивация для монад в Haskell. Зачем это в С++? По тем же причинам. С помощью монад упрощается код, который ранее мы бы писали очень развесисто. Посмотрите, например, на Go-шников с их вездесущей проверкой результата на err. И хотя в С++ есть исключения, возврат ошибок все же используется, и вот такой код может быть значительно упрощен для чтения и понимания с помощью монады. С помощью монад можно писать более надежный и предсказуемый код. Там, где обычный набор инструкций позволяет допустить ошибку по невнимательности, например, программист не обработал результат функции, монадический код это не позволит. Просто потому, что проверка результата функции будет вшита в конкретную монаду (std::optional, std::expected), и потому "пройти мимо" уже будет нельзя. Или взять std::future. С помощью монадического связывания очень легко пишется такой код, где таски будут вычисляться либо одна за одной, либо параллельно: программист, оперируя монадическими функциями, выбирает, что ему нужно. При этом ему не нужно специально писать, какую фьючу когда надо дождаться, где синхронизоваться и куда передать дальше. Он просто пишет монадический код, а соответствующая монада возьмет эти манипуляции на себя и сделает их "в бэкграунде". Это очень удобно, так как по сути, программист лишь работает со своей вычислительной моделью, которая не "загрязнена" деталями от std::future. На дворе 2018 год. Без монад уже нельзя, потому что более мощной и полезной абстракции еще не рождалось за последнее двадцать лет.

↑ tldr: он расписал то же самое, что я и, но подробнее и с примерами :)

Помимо этого, похоже, что ты под монадами имеешь в виду только IO и ST, а есть и другие варианты их применения (допускаю, впрочем, что они менее интересны в контексте C++).

Ну да, а что еще собственно? Монады записи в лог, монады для асинхронщины

Ну да, а что еще собственно? Монады записи в лог, монады для асинхронщины

Э, всякие там State, Reader/Writer, да List, в конце концов.

Это чисто Хаскеллевские.

Фига ты прям отрезал

Потому что иначе не сделать.

Полностью согласен с предыдущим оратором по полезности чисто функциональных концепций на уровне связывания со вспомогательными модулями

Ну серьёзно плюсы уже язык со стейтом. Зачем мне может понадобиться монада со стейтом?

У меня не получается продолжить диалог, не скатываясь в оффтоп :(

Я понимаю мотивацию про связывание вычислений.

Честно.