На основании?

Ребята, давайте я его просто забаню Мне кажется толку будет больше, в том числе и для него...

не было нарушений правил

Объясните

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

Как ставить гткмм под федору?

Тебе сюда: @russianfedora

Все работает, когда в отдельном проекте их использую

комманд лайн тулз же ставил?

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

энивэй, <linux/unistd.h> всё равно доджен быть доступен. Это странно, что его нет. Я бы сначала разобрался с этим.

На основании?

Бессмысленност дальнейших разговоров

Бессмысленност дальнейших разговоров

Вы судите о бессмысленности в качестве кого?)

комманд лайн тулз же ставил?

xcode-select --install есличо

xcode-select --install есличо

Спасибо, попробую!

Вы судите о бессмысленности в качестве кого?)

Прошу прекратить флуд не по теме чата. Если есть вопросы к кому-то из админов, напиши им в ЛС.

Прошу прекратить флуд не по теме чата. Если есть вопросы к кому-то из админов, напиши им в ЛС.

Хорошо, спасибо

Причем когда я подключаю sys/socket.h - он не ругается ) Типа, сокет открыл, а читать, писать и закрывать (в не)его не нужно)

Работа с сокетами? Используй #include<linux/net.h> #include<linux/socket.h> #include<linux/in.h> и их sock_sendmsg . Вообще, тянуть юзерспейсные хедеры в ядро — моветон.

Работа с сокетами? Используй #include<linux/net.h> #include<linux/socket.h> #include<linux/in.h> и их sock_sendmsg . Вообще, тянуть юзерспейсные хедеры в ядро — моветон.

Спасибо за ответ!

Работа с сокетами? Используй #include<linux/net.h> #include<linux/socket.h> #include<linux/in.h> и их sock_sendmsg . Вообще, тянуть юзерспейсные хедеры в ядро — моветон.

man close -> #include <unistd.h> Или ф-ия close еще в каком-то файле определена?

man close -> #include <unistd.h> Или ф-ия close еще в каком-то файле определена?

sys_close

sys_close

Спасибо!

isnullxbh (0) увеличил репутацию Max (1)

https://habr.com/post/419579/ Что думаете на счет использования подобных вещей в реальных проектах?

https://habr.com/post/419579/ Что думаете на счет использования подобных вещей в реальных проектах?

Это не стандартный сахар - отношусь против

https://habr.com/post/419579/ Что думаете на счет использования подобных вещей в реальных проектах?

Умилили эти размышления: Хотелось бы также сказать о некоторых особенностях данного решения. Visual Studio инстанцирует шаблонны в месте использования, что означает что сама функция перегрузки должна быть объявлена до места использования оператора, но может быть объявлена после декларации класса OP_IN_LVAL. GCC в свою очередь инстанцирует шаблон в месте объявления (когда встречает использование само собой), что означает, что перегруженный оператор должен быть объявлен до того как декларируется класс OP_IN_LVAL. Если не совсем понятно о чём речь, то вот пример. cpp.sh/5jxcq В этом коде я всего лишь перенёс перегрузку оператора in ниже декларации класса OP_IN_LVAL и он перестал компилироваться в GCC (если только не компилировать с флагом -fpermissive), но успешно компилируется в Visual Studio.

Это не стандартный сахар - отношусь против

Я был бы за, но нахера ж мне мап каждый раз создавать?

Умилили эти размышления: Хотелось бы также сказать о некоторых особенностях данного решения. Visual Studio инстанцирует шаблонны в месте использования, что означает что сама функция перегрузки должна быть объявлена до места использования оператора, но может быть объявлена после декларации класса OP_IN_LVAL. GCC в свою очередь инстанцирует шаблон в месте объявления (когда встречает использование само собой), что означает, что перегруженный оператор должен быть объявлен до того как декларируется класс OP_IN_LVAL. Если не совсем понятно о чём речь, то вот пример. cpp.sh/5jxcq В этом коде я всего лишь перенёс перегрузку оператора in ниже декларации класса OP_IN_LVAL и он перестал компилироваться в GCC (если только не компилировать с флагом -fpermissive), но успешно компилируется в Visual Studio.

А чем умилили? Ну, оно так и есть, студия тут не следует стандарту.

У них там всё грустно с этой точки зрения, но вроде какие-то подвижки были

А чем умилили? Ну, оно так и есть, студия тут не следует стандарту.

А что , стандарт у нас говорит, КОГДА Надо инстанциировать шабон?

А что , стандарт у нас говорит, КОГДА Надо инстанциировать шабон?

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

А чем умилили? Ну, оно так и есть, студия тут не следует стандарту.

Также уверен, что автор путает объявление и определение.

И, насколько я помню, gcc в этом случае действует по стандарту, а VS из-за особенностей реализации (которые автор передал правильно) некоторые ошибки пропускает.

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

ошибка != инстанциация.

А, окей, тут он неправильно написал.

Хабр он такой хабр...

Услуги по бану. Недорого.

Цитата из K&R, приложение A.6.3 про преобразование целых чисел в вещественные Если результат преобразования выходит за границы диапазона допустимых значений, то результат неопределен У float потолок - 3.4е38, у uint64 - 9.2е18, у uint128 - 1.7e38 Я что-то упускаю, или это "задел на будущее" просто такой?

K&R наверняка устарели, надо смотреть актуальный стандарт.

А где твой создатель?

Вопрос. Компилю под линукс (допустим, pure C), получаю в зависимостях libc версии GLIBC_X.Y. Копирую приложение на другую машину со старой системой - получаю ошибку запуска (очевидно, почему). Вопрос: как решают подобные проблемы? 1) Статическая линковка libc кажется стрёмной, да и не получилось с cmake договориться. 2) Снизить требуемую версию glibc - как? 3) Таскать с собой зависимости

Вопрос. Компилю под линукс (допустим, pure C), получаю в зависимостях libc версии GLIBC_X.Y. Копирую приложение на другую машину со старой системой - получаю ошибку запуска (очевидно, почему). Вопрос: как решают подобные проблемы? 1) Статическая линковка libc кажется стрёмной, да и не получилось с cmake договориться. 2) Снизить требуемую версию glibc - как? 3) Таскать с собой зависимости

1) Статическая линковка 2) Проверять, что тебе надо и смотреть в каждые версии, совместимо ли (гемор) 3) Контейнеры всякие

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

я дистр сменил

Вопрос. Компилю под линукс (допустим, pure C), получаю в зависимостях libc версии GLIBC_X.Y. Копирую приложение на другую машину со старой системой - получаю ошибку запуска (очевидно, почему). Вопрос: как решают подобные проблемы? 1) Статическая линковка libc кажется стрёмной, да и не получилось с cmake договориться. 2) Снизить требуемую версию glibc - как? 3) Таскать с собой зависимости

у тебя на старой версии другая мажорная версия?

Цитата из K&R, приложение A.6.3 про преобразование целых чисел в вещественные Если результат преобразования выходит за границы диапазона допустимых значений, то результат неопределен У float потолок - 3.4е38, у uint64 - 9.2е18, у uint128 - 1.7e38 Я что-то упускаю, или это "задел на будущее" просто такой?

Как-то странно, диапазон значений float выше чем у int же ...

Как-то странно, диапазон значений float выше чем у int же ...

Ну вот да, меня это тоже сильно смутило)

Вопрос. Компилю под линукс (допустим, pure C), получаю в зависимостях libc версии GLIBC_X.Y. Копирую приложение на другую машину со старой системой - получаю ошибку запуска (очевидно, почему). Вопрос: как решают подобные проблемы? 1) Статическая линковка libc кажется стрёмной, да и не получилось с cmake договориться. 2) Снизить требуемую версию glibc - как? 3) Таскать с собой зависимости

Сборка из исходников (или объектников) под каждый конкретный линух...

Ну вот да, меня это тоже сильно смутило)

Это же книга, а не стандарт. Плюнь, забей...

Вопрос. Компилю под линукс (допустим, pure C), получаю в зависимостях libc версии GLIBC_X.Y. Копирую приложение на другую машину со старой системой - получаю ошибку запуска (очевидно, почему). Вопрос: как решают подобные проблемы? 1) Статическая линковка libc кажется стрёмной, да и не получилось с cmake договориться. 2) Снизить требуемую версию glibc - как? 3) Таскать с собой зависимости

Почитай это: https://www.easycoding.org/2018/06/17/pravilno-paketim-po-dlya-linux.html

достаточно не менять мажорную версию

у тебя на старой версии другая мажорная версия?

Скажем так, компилю я у себя с новой супер-продвинутой версией (2.17), на старье 2.12 (у клиента). Раньше я решал проблему "иди обновляй дистр", но сейчас внезапно захотелось пофиксить

Сборка из исходников (или объектников) под каждый конкретный линух...

это извращение

Почитай это: https://www.easycoding.org/2018/06/17/pravilno-paketim-po-dlya-linux.html

изучу, спасибо

ух ты, именная статья

ну обновляй дистр

это извращение

Нет, поэтому и придумали Flatpak.

Если коротко, то либо собирай по пакету для каждого дистрибутива, либо используй Flatpak.

ну обновляй дистр

это единственно верное решение кстати

скажем так - приложение не open-source, поэтому распространять сорцы не вариант

скажем так - приложение не open-source, поэтому распространять сорцы не вариант

Flatpak ваш выбор. Ещё и проблем с репозиторием и обновлениями у пользователей не будет.

уже читаю

Flatpak ваш выбор. Ещё и проблем с репозиторием и обновлениями у пользователей не будет.

и пользователи будут считать что они запускают проприетарный мусор типа драйверов HP

и пользователи будут считать что они запускают проприетарный мусор типа драйверов HP

Пользователи Linux в большинстве случаев и не будут ставить себе проприетарщину в систему если для неё есть OSS альтернатива в репозиториях.

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

Вопрос. Компилю под линукс (допустим, pure C), получаю в зависимостях libc версии GLIBC_X.Y. Копирую приложение на другую машину со старой системой - получаю ошибку запуска (очевидно, почему). Вопрос: как решают подобные проблемы? 1) Статическая линковка libc кажется стрёмной, да и не получилось с cmake договориться. 2) Снизить требуемую версию glibc - как? 3) Таскать с собой зависимости

еще такая есть штука https://github.com/wheybags/glibc_version_header

еще такая есть штука https://github.com/wheybags/glibc_version_header

о, об этом я задумывался, сейчас тоже почитаю, спасибо

достаточно не менять мажорную версию

Ну и плюс бинарная совместимость ABI есть иногд ана Linux

подскажите плз такой момент. Есть такой код shared_ptr<...> ptr = std::move(another_shared_ptr) при многопоточности могут быть проблемы с ptr в данном случае, если не залочить?

не будет проблем. не важно, с move или без

подскажите плз такой момент. Есть такой код shared_ptr<...> ptr = std::move(another_shared_ptr) при многопоточности могут быть проблемы с ptr в данном случае, если не залочить?

Нет

Ну если не трогаешь сами поинтеры

В блоке с счетчиком проблем не будет

нет, я только сами shared_ptr трогаю

ptr ты еще не сконструировал так что хз как ты его потрогаешь

another трогать ты не должен без синхронизации

Если там есть третий указатель то его можешь трогать когда угодно

да, понял, спасибо)

Учитывай что атомарен там только счетчик а не то что лежит по указателю

Учитывай что атомарен там только счетчик а не то что лежит по указателю

да, я вот за этот момент переживал) видел хорошие примеры, которые это показывают

И какова вообще альтернатива в плане статического полиморфизма для конструкции типа ConcreteAlgoritm : GenericAlgorithm<ConcreteAlgoritm>?

Читать пробовали?

Читать пробовали?

Пробовал. Статический полиморфизм без CRTP лучше чем с ним. Имеется в виду что то вроде ConcreteAlgoritm = GenericAlgorithm<Policy>?

Пробовал. Статический полиморфизм без CRTP лучше чем с ним. Имеется в виду что то вроде ConcreteAlgoritm = GenericAlgorithm<Policy>?

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

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

Например какой то жирный shared state который можно задешево шарить как protected без нарушения инкапсуляции снаружи.

Антипример - внедрение (возможно) stateful политики и пляски с бубнами наподобие allocator_traits::propagate_on*.

Маленький простой CRTP - struct Foo : intrusive_counted<Foo>.

был бы тут беркус, он бы предложил для примера реализацию SSL в бисте

был бы тут беркус, он бы предложил для примера реализацию SSL в бисте

а куда он пропал, кстати? Сгорел?

да, сел в ржавую машину

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

Читаем правила чата

Например какой то жирный shared state который можно задешево шарить как protected без нарушения инкапсуляции снаружи.

Детальнее хочется, конкретика, постановку задачи