Да, но откуда он его скачает? Где мы разместим и будем хранить эти бинарные зависимости. У пакетных менеджеров есть свои registry, которые можно поднять. Если менеджить бинарные зависимости просто в гит репозитории, у этого есть свои существенные недостатки
Наверняка можно организовать это через условые releases из условного github, но эту логику со скачиванием определенной версии релиза и тд, ее нужно реализовывать руками. Если вам известно о другом существующем способе через cmake заниматься менеджментом бинарных зависимостей, поделитесь пожалуйста
Как цмэйком управлять бинарными зависимостями, их кэшированием, версиями и тд? Скачивать это хорошо, но ведь множество библиотек мы подключаем уже собранными, в т.ч. локальные внутри проекта, как этим всем управлять?
Я не понял для чего мне dev контейнеры в этой задаче. Делая свой Dockerfile я имею полный контроль над этим образом, его содержимым, конфиг файлах и тд. Местами иногда приходилось "хакать" - например ставить сурс-листы для пакетов из более высоких версий дистрибутива linux и докачивать только определенные пакеты определенных версий. dev контейнер описывается декларативно через жисон и как будто в этом всем меньше контроля над происходящим.
Не говоря уже о том, что это снижение производительности (каждый вызов метода - создание, а потом свертывание еще одного уровня стека). Если все это вас не волнует - вам повезло.
Чем это лучше, чем clang libtool (примерно так)? В общем инструментарий фронтенда компилятора кланг. Там на входе может быть не какой-то специальный dsl который нужно изучить/понимать, а вполне себе c++ код. Там вполне себе документированные и понятные инструменты для работы с AST C++.
И этот инструмент гарантированно работает, т.к. является неотъемлемой частью полного цикла работы компилятора, ну т.е. серьезные требования к работоспособности и корректности
Как следствие, clang будет поддерживать код из нужного стандарта c++. Например, пришла бы вам в голову идея поддержать ключевое слово trivially_relocatable_if_eligible, которое скоро https://habr.com/ru/companies/yandex/articles/882518/ станет частью разбора структуры/класса и между вашими name и parents встроится? Пример только для иллюстрации того что всегда поддерживать актуальный разбор AST c++ это быть в роли догоняющего за компиляторами
Однобуквенность. Вопрос привычки, такая практика. Их всего 2 таких алиаса, как самые часто-используемые, понятно что если бы их было 10, это уже совсем другой разговор, но эти даже интуитивно понятные
В примере с ShapeUptr угловых скобок было бы на одну пару меньше, они не то чтобы куда-то испарятся все. Но вместе с тем появился и дополнительный символ, его нужно написать. Не сделать forward decl с оригинальным классом, чтобы использовать этот юзинг (т.к. он как правило рядом с определением класса), а в моем примере можно в U<MyClass> пихать такую декларацию при определённых условиях. Ну и то что говорил про поиск по символу
Про замену типа указателя. Для меня выглядит как исключительное событие и думаю писал полный тип хитрого указателя по месту, чтобы не вводить в заблуждение пользователя этого символа на предмет что под капотом. Вообще пример странный, не могу представить себе такое.
Приведу шутошную аналогию, это не аргумент и не всерьез:
Давайте в проекте определим и будем использовать
using Int = int;
Мало ли нам понадобится массово подменить целые числа, а имя Int все равно останется на месте
Сделали в проекте такие глобальные юзинги (в условном common/core.h) :
template <class T>
using U = std::unique_ptr<T>;
И также SH с шаредптр
Читаемость не теряется и не нужно руками делать на каждый такой класс отдельный юзинг.
Плюс такого подхода, что мы всегда видим оригинальный класс и например поиск по символу нужно делать не для каждого такого юзинга, а только для оригинального класса
Девайс очень модный и молодежный, выглядит вкусно. Сам бы точно не купил, по причинам описанным выше @engine9
Рекламные материалы тоже выглядят отлично, дам им немного критики:
https://busy.bar/ при скроллинге на десктопе очень заметно фризит (на заметку)
Самый первый блок с демонстрационным примером, подписанный как Show you’re BUSY - ИМХО видео совсем не отражает кейс использования. Текущий порядок:
Коробка неактивна
подходят с вопросом
коробка демонстративно активируется
раздраженный коллега уходит
На мой взгляд ценность коробки в том, чтобы заранее ее активировать, если знаешь что будешь занят ближайшее время, тогда коллега на подходе к тебе увидит это и будет иметь ввиду, когда ему подойти, так что я сделал бы такую сценку:
Коробка активируется
Таймлапсом проходит 5 минут
подходят с вопросом, но видят коробку, разворачиваются
Таймлапсом проходит все время занятости -> занятость снимается
снова подходят с вопросом, на этот раз коллега получит ответ
ИМХО стек это не структура данных, а некий намеренно ограниченный по операциям интерфейс взаимодействия со структурой данных
С какой структурой данных? Это вопрос, т.к. стек можно реализовать и на базе массива, и на связном списке, на каких-то промежуточных типа deque, ...
Это конечно дискуссионный вопрос, тут смотря как трактовать термины. Но если бы мне предложили выбрать из предложенных элементов, то что меньше всего относится к структурам данных:
Ты находишься на сайте, который был создан для помощи энтузиастам, программистам и просто хорошим людям. Сайт посвящен Российским процессорам архитектуры Эльбрус и не является официальным представителем какого-либо разработчика.
Можно добавить, что "традиционная база" вполне себе может быть развернута на условном tmpfs (in memory).
Это конечно далеко не основной сценарий использования (для тестов гуд), но такая возможность есть, т.е. они тоже могут работать "исключительно в памяти"
Для этой фичи, которая кмк весьма опциональная, ввели аж ключевое слово. Я бы понял, если например механизмы шаред\юник птры обернули бы в ключевые слова и языковые конструкции (не библиотечные), чтобы где-то добавить им элегантности - это повсеместная история.
Новое ключевое слово - еще больше усложняется разбор исходного кода C++, нужно поддержать всякие matcher-ы, разрабам компиляторов сильно больше работы (чем в сравнении с п.3)
Это при том что в синтаксисе уже есть работающий механизм толкать мета-информацию к символам - атрибуты. Зачем вводить вводить новый механизм, если можно использовать старый
С атрибутом будет длиннее на 4 символа т.к. [[]]
4.Я имел ввиду что это могло бы выглядеть примерно так, как подобные вещи решаются в Java\C#\Rust\... почти любой современный язык на самом деле, про динамические и говорить не нужно:
template <class T>
[[trivially_relocatable_if_eligible]]
class Pencil {
// ...
};
Давайте попробуем масштабировать количество атрибутов, допустим еще +2 опциональной мета-информации с большим именем появится в С++29 или еще где, неважно. Получается на любую такую фичу нужно вводить новое ключевое слово? Или только выборочно, значит какие-то вещи через атрибуты, какие-то нет
// OK
template <class T>
[[trivially_relocatable_if_eligible]]
[[serializable_if_trivial]]
[[hello_from_stdcpp_mazafaka]]
class Pencil {
// ...
};
// Сомнительно
template <class T>
class Pencil trivially_relocatable_if_eligible serializable_if_trivial hello_from_stdcpp_mazafaka {
// ...
};
// Сомнительно, но окей (вкусовщина, но считаю хуже первого варианта)
// + завал мусорных ключевых слов,
// которые не должны быть ключевыми словами (имхо)
template <class T>
class Pencil
trivially_relocatable_if_eligible
serializable_if_trivial
hello_from_stdcpp_mazafaka {
// ...
};
Представим такой код:
Есть ли смысл в частичном преобразовании в ANY? т.е. примерно вот так: (все что можно, суем в ANY, остальное оставляем как было)
p.s. я не силен в особенностях внутреннего устройства postgresql
> сколько хауса
p.s. хаоса, но мой комент только ради спойлера
Да, но откуда он его скачает? Где мы разместим и будем хранить эти бинарные зависимости. У пакетных менеджеров есть свои registry, которые можно поднять. Если менеджить бинарные зависимости просто в гит репозитории, у этого есть свои существенные недостатки
Наверняка можно организовать это через условые releases из условного github, но эту логику со скачиванием определенной версии релиза и тд, ее нужно реализовывать руками. Если вам известно о другом существующем способе через cmake заниматься менеджментом бинарных зависимостей, поделитесь пожалуйста
Как цмэйком управлять бинарными зависимостями, их кэшированием, версиями и тд? Скачивать это хорошо, но ведь множество библиотек мы подключаем уже собранными, в т.ч. локальные внутри проекта, как этим всем управлять?
Я не понял для чего мне dev контейнеры в этой задаче. Делая свой Dockerfile я имею полный контроль над этим образом, его содержимым, конфиг файлах и тд. Местами иногда приходилось "хакать" - например ставить сурс-листы для пакетов из более высоких версий дистрибутива linux и докачивать только определенные пакеты определенных версий. dev контейнер описывается декларативно через жисон и как будто в этом всем меньше контроля над происходящим.
А какие преимущества?
зацепила фраза
Безальтернативное утверждение, которое в общем случае подвергается сомнению. Если бы формулировка была что-то вроде:
то и докопаться было бы не до чего =)
Инлайнинг, оптимизация хвостовой рекурсии?
Чем это лучше, чем clang libtool (примерно так)? В общем инструментарий фронтенда компилятора кланг. Там на входе может быть не какой-то специальный dsl который нужно изучить/понимать, а вполне себе c++ код. Там вполне себе документированные и понятные инструменты для работы с AST C++.
И этот инструмент гарантированно работает, т.к. является неотъемлемой частью полного цикла работы компилятора, ну т.е. серьезные требования к работоспособности и корректности
Как следствие, clang будет поддерживать код из нужного стандарта c++. Например, пришла бы вам в голову идея поддержать ключевое слово trivially_relocatable_if_eligible, которое скоро https://habr.com/ru/companies/yandex/articles/882518/ станет частью разбора структуры/класса и между вашими name и parents встроится? Пример только для иллюстрации того что всегда поддерживать актуальный разбор AST c++ это быть в роли догоняющего за компиляторами
Однобуквенность. Вопрос привычки, такая практика. Их всего 2 таких алиаса, как самые часто-используемые, понятно что если бы их было 10, это уже совсем другой разговор, но эти даже интуитивно понятные
В примере с ShapeUptr угловых скобок было бы на одну пару меньше, они не то чтобы куда-то испарятся все. Но вместе с тем появился и дополнительный символ, его нужно написать. Не сделать forward decl с оригинальным классом, чтобы использовать этот юзинг (т.к. он как правило рядом с определением класса), а в моем примере можно в U<MyClass> пихать такую декларацию при определённых условиях. Ну и то что говорил про поиск по символу
Про замену типа указателя. Для меня выглядит как исключительное событие и думаю писал полный тип хитрого указателя по месту, чтобы не вводить в заблуждение пользователя этого символа на предмет что под капотом. Вообще пример странный, не могу представить себе такое.
Приведу шутошную аналогию, это не аргумент и не всерьез:
Давайте в проекте определим и будем использовать
Мало ли нам понадобится массово подменить целые числа, а имя Int все равно останется на месте
Сделали в проекте такие глобальные юзинги (в условном common/core.h) :
И также SH с шаредптр
Читаемость не теряется и не нужно руками делать на каждый такой класс отдельный юзинг.
Плюс такого подхода, что мы всегда видим оригинальный класс и например поиск по символу нужно делать не для каждого такого юзинга, а только для оригинального класса
Девайс очень модный и молодежный, выглядит вкусно. Сам бы точно не купил, по причинам описанным выше @engine9
Рекламные материалы тоже выглядят отлично, дам им немного критики:
https://busy.bar/ при скроллинге на десктопе очень заметно фризит (на заметку)
Самый первый блок с демонстрационным примером, подписанный как Show you’re BUSY - ИМХО видео совсем не отражает кейс использования. Текущий порядок:
Коробка неактивна
подходят с вопросом
коробка демонстративно активируется
раздраженный коллега уходит
На мой взгляд ценность коробки в том, чтобы заранее ее активировать, если знаешь что будешь занят ближайшее время, тогда коллега на подходе к тебе увидит это и будет иметь ввиду, когда ему подойти, так что я сделал бы такую сценку:
Коробка активируется
Таймлапсом проходит 5 минут
подходят с вопросом, но видят коробку, разворачиваются
Таймлапсом проходит все время занятости -> занятость снимается
снова подходят с вопросом, на этот раз коллега получит ответ
ИМХО стек это не структура данных, а некий намеренно ограниченный по операциям интерфейс взаимодействия со структурой данных
С какой структурой данных? Это вопрос, т.к. стек можно реализовать и на базе массива, и на связном списке, на каких-то промежуточных типа deque, ...
Это конечно дискуссионный вопрос, тут смотря как трактовать термины. Но если бы мне предложили выбрать из предложенных элементов, то что меньше всего относится к структурам данных:
массив,
связный список,
хэш-таблица,
стек,
ассоциативный массив на красно-черном дереве
То это был бы стек
Эх, магии не случилось, и тут нужно заклинание с трех букв
Когда играешь в factorio и выходишь на баланс мощностей только на панелях + аккумуляторах
Можно добавить, что "традиционная база" вполне себе может быть развернута на условном tmpfs (in memory).
Это конечно далеко не основной сценарий использования (для тестов гуд), но такая возможность есть, т.е. они тоже могут работать "исключительно в памяти"
Теперь можно из него + кучи плагинов, синхронизацией с гит и блаблабла ... Склепать корпоративную wiki ?
Агап, про [[]] пишу "вынуждено", маловероятно что будут менять синтаксис атрибутов.
Но если бы меняли, лично мне нравится Java вариант, достаточно элегантно
Спасибо, чуть понятнее стало почему так (хоть и все равно не очень нравится концептуально по причинам из пунктов)
Спасибо, окей, по кишкам нет вопросов
Возвращаюсь в область вкусовщины и синтаксиса :)
Для этой фичи, которая кмк весьма опциональная, ввели аж ключевое слово. Я бы понял, если например механизмы шаред\юник птры обернули бы в ключевые слова и языковые конструкции (не библиотечные), чтобы где-то добавить им элегантности - это повсеместная история.
Новое ключевое слово - еще больше усложняется разбор исходного кода C++, нужно поддержать всякие matcher-ы, разрабам компиляторов сильно больше работы (чем в сравнении с п.3)
Это при том что в синтаксисе уже есть работающий механизм толкать мета-информацию к символам - атрибуты. Зачем вводить вводить новый механизм, если можно использовать старый
4.Я имел ввиду что это могло бы выглядеть примерно так, как подобные вещи решаются в Java\C#\Rust\... почти любой современный язык на самом деле, про динамические и говорить не нужно:
Давайте попробуем масштабировать количество атрибутов, допустим еще +2 опциональной мета-информации с большим именем появится в С++29 или еще где, неважно. Получается на любую такую фичу нужно вводить новое ключевое слово? Или только выборочно, значит какие-то вещи через атрибуты, какие-то нет