Обновить
-12
0

Пользователь

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

Как раз в C++ с этим всё гораздо проще. А вот в каком-нибудь питоне вообще непонятно что делается под капотом. Я из-за этого так и не научился внятно его использовать.

C++ небезопасен и не прощает ошибок, во всю эту механику приходится плотно погружаться.

Вот это поворот! Язык, близкий к железу, требователен к программисту.
Могу ошибаться, но на таких языках, как Go, Eiffel, Ada, Java это сделать гораздо сложнее.

Вообще не понимаю как можно так говорить о языках со сборщиком мусора.

Проблема в том, что глядя на код сложно себе представить что на самом деле здесь происходит (вызов функции или конструктора, количество неявных преобразований)

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

Между тем, C++ вполне позволяет такое делать.

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

Как раз нет. C++ один из немногих языков, на котором вы сможете написать ядро приложения для работы и под Windows, и под Linux, и под MacOS, и под iOS, и под Android, и под какой-нибудь Tizen.

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

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

Скажем, тот же SFINAE.

А эта техника и не должна использоваться на каждом шагу. Как и эта:
Или другой пример: проверка наличия определенного метода у объекта или у класса.

Вы всё упорно пытаетесь сделать из C++ язык для быстрого написания кода высокого уровня и удивляетесь, что это не очень удобно. Странная позиция.

работа с сетью

По-моему работа с сетью никогда не была коньком плюсов. В стандартной либе до сих пор нет ничего для работы с сетью.

достаточно низким уровнем

Эта работа с достаточно низким уровнем должна вестись во всём проекте, или нужно пару оптимизаций, а всё остальное — обычное приложение? Просто я с трудом представляю себе целый проект, который целиком про ковыряние в регистрах, но при этом его пишут на каком-нибудь C#.

обработка больших объемов данных

С этим успешно справляются многие другие языки, в которые были добавлены соответствующие диалекты или оптимизации на фоне бурного роста популярности больших данных.

написание кода, который должен работать как на дестктопе, так и на мобилках, так и на умных гаджетах

Вот это вообще не ниша плюсов. Кроссплатформенность — это к java и иже.

Тому есть ряд причин, имхо.

Имхо просто не стоит гвозди забивать микроскопом.
И какую долю в этом составляет сложность C++?

У меня появилось подозрение, что у нас разные определения термина «сложность». Я воспринимаю сложность языка как «далёкость» от естественных языков и трудности понимания базовых концепций этого языка. У Вас же, насколько я понял, сложность языка — понятие исключительно практическое; при том даже не со стороны программиста, а со стороны управленца, которому надо сделать проект, и он считает сколько человекочасов будет потрачено на определённую задачу.

Почему же эти языки лучше с практической точки зрения?

Потому что они создавались для целей эффективного написания кода для распространённых задач (бизнес-логика, пользовательские приложения)? В отличие от C++ (или C), в который закладывалась возможность напрямую обращаться к памяти.
Только Rust тут в стороне, как наследник C++, но я что-то не видел, чтобы им активно пользовался enterprise.
К сожалению, правда.

В чём принципиальная сложность плюсов?
Нет. Старички предпочитают выбирать Go, Rust, C#, Scala, Kotlin и т.д.

Так всё правильно же. Сейчас для большинства задач с практической точки зрения подходят лучше те языки, которые Вы перечислили.
Так ведь лишняя сущность. Если без нее можно обойтись, значит без нее следует обойтись

Ценой разбросанных по всему классу метафункций. Сомнительная сделка, учитывая то, что эта «лишняя сущность» занимает две строки.
Они и будут вложенными. Просто условия в них, за счет метафункций, будут понятнее.

Спасибо, не надо. Ещё не хватало в определениях классов голову в условиях ломать.
Если в простых случаях static if окажется сильно проще условного наследования, то это же хорошо.

Мы все прекрасно понимаем, что очень скоро «static if» окажется далеко не только в простых случаях. «Стрелял себе в ногу, попал в компилятор, ранены все».
Так ведь C++ и так уже слишком сложный.

Он не сложный, а объёмный. Но достаточно гармоничный пока что.
И порог входа в него для новичков слишком высок.

И это не правда. Для того, чтобы писать простые программы, каких-то особых знаний вообще не требуется. Другое дело, что многие воспринимают плюсы как «сложный питон (джаваскрипт, пхп)» и пытаются писать программы так же. Естественно, это вызывает искреннее непонимание у компилятора.
Это одна из причин, по которой от C++ отказываются в новых проектах даже там, где по техническим причинам C++ мог бы быть хорошим выбором.

Новички делают какие-то проекты, и не выбирают C++? Индустрия это переживёт, я думаю. А компании обычно способны нанять программиста, специализирущегося на C++.
А упрощать C++, чтобы порог входа был ниже.

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

В чём будет проявляться их «торчание», кроме ошибок компилера? И в этих самых ошибках я проблемы не вижу.
Мне не понятно, какая выгода от того, чтобы результат метафункции засовывать в параметр шаблона.

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

Не вижу проблемы. Как Вы и сказали, «в реализацию придётся заглядывать немногим».
И если какая-то вкусность способна сделать C++ более простым в использовании, то почему бы и нет?

Не знаю на счёт истории, но сейчас подобные конструкции явно лишние в языке. Заимствования, которые Вы описали, отторжения не вызывают, потому что они не входят в конфликт с текущим синтаксисом.
Что в таком случае мешает использовать макросы? Просто же сразу станет. По-моему простота — это не то, за чем стоит безусловно гнаться.
Тоже самое можно сказать и по поводу предиката для static if.

Каким образом? Куда Вы вложенные if'ы спрячете?
Проблема в том, что в отсутствии static if эти самые классы нужно придумать

Не вижу проблемы. Делать классы-франкентшейны не должно быть легко и быстро.
Это сложно для многих C++ разработчиков.

Если программисту сложно (именно сложно, а не геморно) решить задачу на C++, то, возможно, стоит использовать другой язык? Для меня, например, сложно писать код в функциональном стиле, но я же не предлагаю из-за этого добавить простые человеческие циклы в haskell.
Тогда как static if может все эти заботы сделать ненужными.

И добавит других забот и проблем.
Определение шаблона становится слишком сложным.

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

Это легко решается алиасом.
В Ruby, например, так же можно if в определении класса использовать, и это применяют на практике.

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

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

Я примерно об этом:
код
template<
   typename Msg,
   message_ownership_t Ownership = message_ownership_t::autodetected >,
   typename Inherited = details::message_holder_details::accessor_selector_t<
            details::message_mutability_traits<Msg>::mutability,
            details::message_holder_details::impl_selector_t<Msg, Ownership> >,
   typename Base_type = details::message_holder_details::accessor_selector_t<
            details::message_mutability_traits<Msg>::mutability,
            details::message_holder_details::impl_selector_t<Msg, Ownership> > >
class message_holder_t : public Inherited
{
...



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


Неправда, if'ы в объявлении класса мало того, что выглядят чужеродно, так ещё и создают путаницу. То, что это решение проще и реализуется за минуты, не значит, что оно лучше и будет хорошо работать потом. Банальный пример: понадобится усложнить критерии выбора наследуемых типов — Вы будете в классе уже каскады if'ов делать? Объявление тогда превратится в какой-то рабочий код.
Так в этой статье вроде бы магия и не обещалась.

Ну, упоминание шаблонной магии есть.

Что, если не секрет?

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

Понятно, что главная проблема в том, что я уже просто старый и тупой

Скорее в отсутствии опыта. Если бы Вы перед решением этой задачи пару недель ковырялись в метапрограммировании, ответ пришёл бы быстрее и проще.
А то, что Вы хотите проще, быстрее и приседаний поменьше — вполне логично и ожидаемо, только вот на мой взгляд это неправильный выбор. Это как хотеть наклепать одну большую глобальную функцию, вместо того, чтобы разбивать задачу на более мелкие и подбирать удачные структуры данных.
Не хочу показаться снобом, но где магия? Автор решил простую задачу стандартными средствами.
Кроме того, решение автора (хоть я и кое-что поправил бы) выглядит гораздо лучше чем портянка кода, где в объявлении класса тебе приходится разбираться со всякими if'ами.
Поддержка «Naming Convention» радует, но условный «camelCase» вы почему-то разделили на «PascalCase» и «camelCase», а «snake_case» в варианте с первой заглавной буквой нет.
Символично, что в топах статей на русском нет ни одной (я не нашёл), которая была бы посвящена алгоритмам, математике и прочим «серьёзным» вещам. Зато есть про фотографии Лоуренс, «IT-эмиграцию» и «русский наебизнес».
В то же время на английском есть про фильтры Калмана и каринг в C++14, хотя статьи на английском появились относительно недавно.
Я, честно говоря, не знаю зачем нужны спортсмены. На них даже всякую химию испытывать не дают =(
А зачем тогда нужны шахматисты?
Есть вариант без макросов и «compiler-specific» кода — лямбды. Да, «строгость типизации» теряется, но зато всё довольно красиво. Достаточно передать лямбду в constexpr функцию, которая вызовет эту лямбду и передаст возвращаемое значение в шаблон. Как-то так:
Код
#include <iostream>
#include <utility>

template <char... symbols>
struct Constexpr_string
{
  static constexpr char value[] = { symbols... };
};

template <typename Lambda_type, std::size_t... indexes>
constexpr auto get_string(Lambda_type function, std::index_sequence<indexes...>)
{
  return Constexpr_string<function()[indexes]...>();
}

template <std::size_t N, typename Lambda_type, typename Indices = std::make_index_sequence<N>>
constexpr auto get_string(Lambda_type function)
{
  return get_string(function, Indices{});
}

constexpr size_t length(const char* str)
{
    return (*str == 0) ? 0 : length(str + 1) + 1;
}

template <typename Lambda_type>
constexpr auto get_string(Lambda_type function)
{
  return get_string<length(function())>(function);
}

int main()
{
    auto s = get_string([](){ return "lambda"; });
    std::cout << decltype(s)::value << std::endl;
}

у вас

Не у меня, а в реальном мире. Даже если ты живёшь в общаге или квартире, ты не можешь делать всё, что тебе захочется. Что уж говорить про гораздо более тонкие материи, вроде международных отношений. Но в твоём воображаемом мире всё гораздо проще.
США то это будет считаться агрессией, а если СССР — то нет

Я уже десять раз объяснил, что это не так. В отличие от тебя, у которого чётко и понятно, что СССР плохой, а США — хорошие. Просто потому, что СССР якобы на кого-то нападал, а США кого-то от кого-то защищал. А, ну ещё интересы американцев якобы совпадают с твоими/общемировыми/прогрессивными.
нулевую опасность

Да, военные базы США около границы СССР и рядом с базами его флота — это нулевая опасность.
ядерных ракет чувакам граничащим с США

В ответ на аналогичные поставки.
дорогой мой друг

Зачем заменил «идиот» на «друг»? Постеснялся?
поставки оружия правительству Анголы для борьбы с повстанцами — колониальная оккупация

Где я такое утверждал? Мой посыл о том, что присутствие в Африке сейчас достигается не колониальным правительством, а более тонкими методами с использованием наёмников.
Вы же не считаете помощь США моджахедам нормальной, не?

Ну сколько раз тебе повторять: финансирование религиозных фанатиков на другом конце шарика чтобы подгадить СССР и помощь одной из сторон (светской) в ходе гражданской войны на территории соседней страны — это как бы вещи разного порядка, не?
что считать вмешательством и агрессией

Давай лучше зададим функцию «гадкости» действий с областью значений на промежутке от 0 до 10. Можно определить, например, как произведение расстояния от твоих границ, обратного расстояния до границ геополитического противника, степени вмешательства и какого-нибудь коэффициента. По этой шкале помощь моджахедам — чистая 10 + бонус за карму. А помощь северокорейцам на троечку может потянет.
Скажем Куба где СССР вмешался вплоть до поставок ядерного оружия — это далеко от границ СССР или нет?

Лол, как он вмешивался? Даже ракеты пошли только после согласия Кастро.
Имеют ли вообще право страны имеющие несчастье иметь общую границу с СССР на собственный суверенитет или должны делать все как СССР говорит?

Имеют, пока это не мешает соседу. Та же Украина никому не нужна была, пока не решила сменить свой внеблоковый и нейтральный статус. У Финляндии тоже проблем не было с СССР.
Поставки оружия пошли уже в 2012

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

Ну поэтому-то наёмники помогли её закончить.
Нападал

Можно мне примеры того, как СА вела общевойсковой бой во Вьетнаме или Корее? Или хотя бы батальон для охраны какого-либо объекта выделила?
А СССР стоит в сторонке

Думаю, так и было бы, если бы это была какая-то рандомная страна далеко от границ СССР. Максимум — пресловутая поддержка оружием и спецами.
Просто 7 лет назад это было.

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

Например, Ангола в девяностых. Куча нефти, и корпорации, которые помогали нужным людям с помощью наёмников.
ДР, то ГДР не имела бы права просить СССР о помощи в защите от вторжения

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

> дружить
> ставленник
Ясно-понятно
А зачем России нужны ядерные ракеты?

Россия — лакомый кусочек по многим статьям. А в Корее даже добывать особо нечего. Ей абсолютно никто не угрожал бы, и она совершенно никому не нужна.
Каким провокациям?

Ну когда в рамках учений соседи перекидываются снарядами через твою территорию — это провокация.
Гораздо лучше чем ты

Что-то не видно. По крайней мере очередные рассказы про умеренных. Если они там когда-то и были, то в мизерных количествах. Все остальные стараются под них закосить, хотя привычка резать головы никуда не пропадает.
смотреть зомбоящик

Наверное, по зомбоящику можно пообщаться с непосредственными участниками событий.
Там местные князьки правят а отнюдь не европейцы.

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

Наверное, игрушки присылали для Афганских детей, и Бжезинский именно поэтому сказал, что это спровоцирует СССР.
Удобно когда можно любую страну назвать «несуществующей», не правда ли?

Оправдывать вторжение американцев тем, что их пригласил кто-то из Южной Кореи или Южного Вьетнама, то же самое, что оправдывать вторжение по приглашению ФРГ или ГДР. Типа верхушка, которая так или иначе связана с контролирующей страной приглашает кого-то вторгнуться на территорию второй половины страны. Крутая логика.
А ничего что там американцев практически не было пока туда не припёрся Вьетконг?

> Американская администрация сделала ставку на Нго Динь Зьема, премьер-министра Государства Вьетнам. 16 июля 1955 года Зьем заявил, что Южный Вьетнам не будет выполнять Женевские соглашения, всеобщих выборов не будет
Показалось, наверное.
0.6-1 млн человек (!) свалили из чудесного коммунистического Вьетнама на Юг.

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

Какой ужас! Как посмели своё оружие разработать!
бы на голодный желудок великому лидеру клепать ракеты да ядерные заряды

Зачем Корее понадобились бы ракеты, если не было бы конфликта в самой Корее? Риторика лидеров КНДР была построена на идее объединения полуострова, либо шла в пику постоянным провокациям ЮК и США.
с США перестать конфликтовать и подружиться

Ну то есть КНДР виновата в том, что не хочет дружить с США)))
Разницу между торговой и реальной войной не улавливаете? Бедняга.

Между СССР и США тоже не было прямого конфликта. Мирно жили, что уж там.
Сирия на 90% воюет сама с собой

Ты тоже будешь рассказывать про «умеренную оппозицию»?))
ИГИЛ, к слову, в Сирии уничтожили преимущественно американцы.

Вот это топчик. Ты хоть примерно представляешь что там происходит? Думаю, что нет. Американцы стараются больше СА бомбить, а не ИГИЛ. Во всяком случае после прихода русских — точно. И уж точно ВКС нанесли куда больше вреда ИГИЛ, чем удары коалиции.
Ага, аж целая 1 постоянная (и весьма небольшая) база в Джибути созданная в 2002.

Ну ещё несколько в Нигере (и строят новую), и целая россыпь на Аравийском полуострове.
Даже там где они ушли добровольно.

Никто никуда не уходил. Там где есть что брать — берут, там где нечего — негры предоставлены сами себе.
Перечитайте о чем речь шла в комменте.

И что я должен из этого понять?

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность