LINUX.ORG.RU

Продуктивность разработки на C++.

 , ,


6

12

Уважаемые программисты!

Предлагаю порассуждать о продуктивности разработки на C++ по сравнению с так называемыми скриптовыми языками. Вот, принято считать, что языки на вроде Python позволяют работать программисту более продуктивно по сравнению с C++. И что, дескать, на C++ надо писать только узкие места и всё такое.

Мне же хочется четкого понимания. Может быть это миф? А может быть это просто инерция, потому что так вот принято считать и все тут. Вот сегодня в C++ уже не надо думать об освобождении памяти, так как есть умные указатели. Сегодня есть уже более-менее нормальные IDE для C++. Так? Так.

Так что же тогда мешает писать на C++ столь же продуктивно, как на том же Python? Какие будут рассуждения? Может быть есть какие-то реальные обоснования на этот счёт, кроме как «в конторе Y так делают, значит смысл есть, они умные, им виднее». А может быть есть какие-то рецепты по продуктивности работы на C++?

Ответ на: комментарий от rustonelove

Слишком невнятно. Что есть язык? Чем он ограничен?

Если это цепепе, то это цепепе. Он ограничен возможностями компилятора.

Потому что в твоём кулл-языке нет никакой компиляции. Это жаваскрипт.

В Лисповых макрах это доступно. Хоть ракету в космос запускай на стадии компиляции.

Опять мир пхп. Всё это делается на пхп.
Мало того, что ты описал какую-то неведомую херню. Какую хранилку, какие процедуры, чего вызывать.

Причём тут пхп? Ты или слушай что тебе говорят внимательно, или так и скажи, что «все потуги меня убедить обречены на фейл.» И тогда я не буду тратить на тебя своё время. Нахрен ты мне нужен вообще?

Ну хорошо, я даже с тобою поиграюсь:

С собой лучше поиграйся. Со мной лучше не надо.

Что делает эта лапша? Определяет глобал foo? Что делает он?

Этот макрос (по задумке) определяет хранимую процедуру на сервере СУБД (т.е. выполняет SQL-запрос CREATE FUNCTION) и определяет функцию на стороне клиента (т.е. выполняет defun), с помощью которой можно вызывать удалённую хранимку естественным для клиента образом, т.е. так (foo arg1 arg2 ...).

azelipupenko
() автор топика
Ответ на: комментарий от azelipupenko

Этот макрос (по задумке) определяет хранимую процедуру на сервере СУБД (т.е. выполняет SQL-запрос CREATE FUNCTION) и определяет функцию на стороне клиента (т.е. выполняет defun), с помощью которой можно вызывать удалённую хранимку естественным для клиента образом, т.е. так (foo arg1 arg2 ...).

Ну э, в чём соль использовать для этих целей именно макрос ?

Xwo
()
Ответ на: комментарий от azelipupenko

насчет лиспа я тоже наслушался сказок. Только в плоскости Emacs'a. Где в теории всё круто, а на практике всё отваливается на ходу.

Xwo
()
Ответ на: комментарий от azelipupenko

Если это цепепе, то это цепепе. Он ограничен возможностями компилятора.

Нет. Ты говорил там про то, что язык для метапрограммирования в цпп - это не цпп. Вот я тебе и спрашиваю - как определить то, где цпп, а где не цпп? Для меня это всё цпп.

В Лисповых макрах это доступно. Хоть ракету в космос запускай на стадии компиляции.

Ну, как в жаваскрипте.

Причём тут пхп? Ты или слушай что тебе говорят внимательно, или так и скажи, что «все потуги меня убедить обречены на фейл.» И тогда я не буду тратить на тебя своё время. Нахрен ты мне нужен вообще?

Потому что это то, из чего состоит любой пхп. Там это именно так, как ты хочешь, и работает. Что тебе непонятно?

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

Дак и мне непонятно - зачем ты сравниваешь жопу с пальцем?

Этот макрос (по задумке) определяет хранимую процедуру на сервере СУБД (т.е. выполняет SQL-запрос CREATE FUNCTION) и определяет функцию на стороне клиента (т.е. выполняет defun), с помощью которой можно вызывать удалённую хранимку естественным для клиента образом, т.е. так (foo arg1 arg2 ...).

Откуда он возьмёт аргументы? Из космоса? А если компиляция отвалиться? А как мне потом перекомпилировать это ещё раз, если БД уже будет засрана?

В твоих объяснениях столько дыр, что я даже не знаю - троллишь ты меня специально, либо действительно всё так плохо.

А такой хелворд пишется и на крестах - для этого никакой компилтайм не нужен. Я так и не понял - к чему ты тут прикрутил какой-то компилтайм. Зачем он нужен, что он делает - мне неведомо.

Ты это поясни. Я за тебя должен придумывать смысл твоим примерам?

rustonelove
()
Ответ на: комментарий от Xwo

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

Да что там пересобрать - я её ещё и на локалхосте собрать не могу. Отличная компиляция.

И тут два варианта - либо я чего-то не понимаю, либо пацан.

rustonelove
()
Ответ на: комментарий от rustonelove

Насколько я слышал ото всех адептов

Подозрительно то, что все их слышали, но никто их не видел. Мб лисперы - это ии на лиспе, который ходить по интернетам и рассказывает сам про себя сказки ?

Xwo
()
Ответ на: комментарий от azelipupenko

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

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

Ага

для тех, кто занимается компиляторами

Сколько таких? Для остальных по умолчанию сложное. Почему сложное? Потому что возиться с кодом как с AST — это задача компилятора. Если тебе потребовалась макра — значит, тебе нужно то, чего нет в компиляторе, но могло бы быть в более мощном(гибком) компиляторе или в более мощном ЯП. Ага, этот момент я упустил вчера.
Переформулирую, если макра определяет некий (e)DSL — это годно, а если макра нужна, чтобы превозмочь тупость компилятора/непродуманность ЯП — то возможности этой макры должно добавить в сам компилятор или ЯП, то есть я рассматриваю макры как инструмент исследования и критерий оценки выразительных возможностей ЯП и его реализации aka компилятор.

Virtuos86 ★★★★★
()
Ответ на: комментарий от Xwo

Ну э, в чём соль использовать для этих целей именно макрос ?

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

azelipupenko
() автор топика
Ответ на: комментарий от Virtuos86

если макра нужна, чтобы превозмочь тупость компилятора/непродуманность ЯП — то возможности этой макры должно добавить в сам компилятор или ЯП

Ахахах, но ведь в расте макросы именно для этого - превозмогать. Никакими DSL там не пахнет. А ты точно фанбой?

anonymous
()
Ответ на: комментарий от rustonelove

Вот я тебе и спрашиваю - как определить то, где цпп, а где не цпп? Для меня это всё цпп.

Вот код на _языке шаблонов_ цепепе, который в компайл-тайме вычисляет Фибоначчи:

template<long long I>
struct Fib { enum : long long { S = Fib<I-1>::S + Fib<I-2>::S }; };

template<>
struct Fib<1> { enum : long long { S = 1 }; };

template<>
struct Fib<0> { enum : long long { S = 0 }; };

А вот код на самом цепепе для этой же цели:

long long fib(long long n)
{
  long long a = 0, b = 1;
  while (a < n) {
    std::tie(a, b) = std::make_tuple(b, a + b);
  }
  return a;
}

Т.е. язык шаблонов цепепе не является цепепе, а является неким извращением. Чтобы вычислить Фибоначчи в компайл-тайме на шаблонах пришлось городить параметризацию шаблонов enum-мом, чтобы компилятор родил в итоге сумму (при этом сделал это с нереальными тормозами по сравнению со вторым примером для рантайма).

Ну, как в жаваскрипте.

Нет, в JS нет макр. Но Айк планирует.

На самом деле ничего этого нет.

Не знаю что тут сказать. Нечего сказать.

Откуда он возьмёт аргументы? Из космоса?

Из аргументов макроса. Извиняюсь, что не указал их:

(define-storable-procedure foo (arg1 arg2)
  begin
  // ...
  end)

А если компиляция отвалиться?

Будет сигнал об ошибке. Компиляция остановится в этой точке. Можно будет вмешаться интерактивно, потом продолжить.

А как мне потом перекомпилировать это ещё раз, если БД уже будет засрана?

Это нужно учесть в коде макроса.

А такой хелворд пишется и на крестах - для этого никакой компилтайм не нужен. Я так и не понял - к чему ты тут прикрутил какой-то компилтайм. Зачем он нужен, что он делает - мне неведомо.

Нет, на крестах не пишется такой. На крестах можно написать какой-нибудь шаблон call(func, args...), который развернётся в хрень типа stream << func << "(" << args << ")". И потом вызывать хранимки как call(«foo», arg1, arg2), но не как foo(arg1, arg2). А вот Лиспе foo будет обычной функцией. И генерится SQL-запрос SELECT foo(arg1, arg2) будет ещё в компайл-тайме, в отличии от крестовой параши на стримах.

azelipupenko
() автор топика
Ответ на: комментарий от azelipupenko

Вот код на _языке шаблонов_ цепепе, который в компайл-тайме вычисляет Фибоначчи:

Это не язык шаблонов, тебя обманули. Это генератор ЦЕПЕПЕ_КОДА на подстановках типов, который так же является частью языка.

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

Т.е. язык шаблонов цепепе не является цепепе, а является неким извращением.

Извращением является не язык, а сам подход. Все методики шаблонные - это в основном кастыли. И твой пример с енумами - такой же кастыль.

Чтобы вычислить Фибоначчи в компайл-тайме на шаблонах пришлось городить параметризацию шаблонов enum-мом, чтобы компилятор родил в итоге сумму (при этом сделал это с нереальными тормозами по сравнению со вторым примером для рантайма).

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

template<size_t n> constexpr size_t fib = fib<n - 1> + fib<n - 2>;
template<> constexpr size_t fib<0> = 0;
template<> constexpr size_t fib<1> = 1;

Нет, в JS нет макр. Но Айк планирует.

Понимаешь. Неважно как это называется. Макро-хренакро. Жаваскрипт тут имеется ввиду как динамический язык и всё это - свойства именно динамичности.

Из аргументов макроса. Извиняюсь, что не указал их:

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

Будет сигнал об ошибке. Компиляция остановится в этой точке. Можно будет вмешаться интерактивно, потом продолжить.

Отличная история.

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

И ты никогда не расскажешь мне о том - нахрена тут нужен компилтайм и что он делает.

Нет, на крестах не пишется такой. На крестах можно написать какой-нибудь шаблон call(func, args...), который развернётся в хрень типа stream << func << "(" << args << ")". И потом вызывать хранимки как call(«foo», arg1, arg2), но не как foo(arg1, arg2).

Да ты совсем эксперт. man operator() перед тем, как нести ахинею.

А вот Лиспе foo будет обычной функцией. И генерится SQL-запрос SELECT foo(arg1, arg2) будет ещё в компайл-тайме, в отличии от крестовой параши на стримах.

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

Ты там не обижайся на меня за грубость, но это просто нереально.

Ну и да, рассказывать про компилтайм, который является оптимизацией в контексте «хранимых процедук», скул-параши, лисп-параше - это надо прям обладать явно нестандартным мышлением.

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

rustonelove
()
Ответ на: комментарий от azelipupenko

Вот пожалуйста, просто сядь и подумай. Задай себе вопрос - зачем? Попытайся и себе и мне ответить. Это же так просто.

Какое преимущество даёт твоя кулл-идея по сравнению с пхп. Зачем тут вообще нужен «компилтайм». Распиши всё по-пунктам.

rustonelove
()
Ответ на: комментарий от rustonelove

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

Нет, на крестах не реализуется.

Да ты совсем эксперт. man operator() перед тем, как нести ахинею.

Да, так и есть. Но хрен редьки не слаще. Пусть будет operator(). Но внутри у него будет генерация запроса в рантайме.

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

Будет. В рантайме у него не аргументы, а значения аргументов. Значения аргументов функции в любой СУБД передаются отдельно (man prepared statement). Поэтому, уже на стадии компиляции можно сгенерить запрос вида SELECT foo($1, $2), и уже потом в рантайме передавать значения аргументов отдельно - этим займётся драйвер к СУБД. Ты не в теме, походу.

Ты действительно не понимаешь уровня того маразма, что ты мне транслируешь?

Нет. Судя по тому, что пишешь сейчас ты, как раз ты не понимаешь что говоришь.

azelipupenko
() автор топика
Ответ на: комментарий от azelipupenko

Поэтому, уже на стадии компиляции можно сгенерить запрос вида SELECT foo($1, $2)

Ну и да. В цепепе даже такой запрос будет генерится в рантайме.

azelipupenko
() автор топика
Ответ на: комментарий от Virtuos86

Потому что возиться с кодом как с AST — это задача компилятора.

Имеешь в виду, что синтаксис имеет значение?

если макра нужна, чтобы превозмочь тупость компилятора/непродуманность ЯП — то возможности этой макры должно добавить в сам компилятор или ЯП

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

azelipupenko
() автор топика
Ответ на: комментарий от azelipupenko

Поэтому, уже на стадии компиляции можно сгенерить запрос вида SELECT foo($1, $2)

Тут так и просится DSL, нормальный, внешний. Так что давай запилим декларативный язык для запросов с трансляцией в сишку. Wait! O shi! Может и хорошо, что шаблоны такие тупые, сразу дают по яйцам изобретателям SQL из говна и палок.

anonymous
()
Ответ на: комментарий от anonymous

Так что давай запилим декларативный язык для запросов с трансляцией в сишку.

Такой уже есть. По крайней мере в Postgres. ecpg.

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

Может кому-то и хорошо. Лол :-)

azelipupenko
() автор топика
Ответ на: комментарий от azelipupenko

Нет, на крестах не реализуется.

Реализуется.

Но внутри у него будет генерация запроса в рантайме.

Вот ты мне объясни. Тебе реально такой альтернативное одарённый, либо притворяешься? Ты понимаешь, что компилтайм генерация - это оптимизация.

Начнём с того, что у тебя НЕТ ДОКАЗАТЕЛЬСТВ ТОГО, ЧТО ОНА У ТЕБЯ КОМПИЛТАЙМ. Это твои бла-бла.

А продолжим тем, что никакая оптимизация не имеет смысла в ситуации той, где ты обделаешься по производительности по умолчанию. Понимаешь? Это тебе уже сказали, но ты продолжаешь игнорировать. Зачем?

Будет. В рантайме у него не аргументы, а значения аргументов.

Аргументы это и есть значения.

Значения аргументов функции в любой СУБД передаются отдельно (man prepared statement).

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

Поэтому, уже на стадии компиляции можно сгенерить запрос вида SELECT foo($1, $2), и уже потом в рантайме передавать значения аргументов отдельно - этим займётся драйвер к СУБД. Ты не в теме, походу.

Уважаемый балабол. Я тебе уже сказал, но ты игнорируешь. Твой недоязык в дерьме. Твой скул в дерьме. Твои строки в дерьме. Твои возможности на писать не дерьмо равны нулю.

И после всего этого НИКАКОГО смысла говорить о ПРОИЗВОДИТЕЛЬНОСТИ попросту НЕТ.

Нет. Судя по тому, что пишешь сейчас ты, как раз ты не понимаешь что говоришь.

Поподробнее об этом.

rustonelove
()
Ответ на: комментарий от rustonelove

Сишке и цепепешке ты научился. Что-то там умеешь. А вот разговаривать нормально - нет. Так что всего доброго. Лимит времени на тебя исчерпан.

azelipupenko
() автор топика
Ответ на: комментарий от rustonelove

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

Расскажешь подробнее об этих внутренних структурах?

I60R ★★
()
Ответ на: комментарий от tailgunner

Я бы спросил, на чем основан этот вывод, но лимит исчерпан %)

Конкретно на данного персонажа лимит исчерпан. А вывод. Человек так рьяно рассказывает про безальтернативность крестов и сей, что поневоле напрашиваются выводы о каких-то там знаниях. Или ты думаешь, что он не знает си/цепепе?

azelipupenko
() автор топика
Ответ на: комментарий от azelipupenko

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

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

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

Особенно обожаю россказни мне о том, что можно запилить, а что нет.

rustonelove
()
Ответ на: комментарий от azelipupenko

У меня нет никаких причин считать, что он знает Си или Си++ на уровне «умею решать практические задачи». То, что он демонстрировал - просто трюки примерно одинаковой степени бесполезности; единственное свое более-менее четкое обещание он не выполнил.

tailgunner ★★★★★
()
Ответ на: комментарий от I60R

Расскажешь подробнее об этих внутренних структурах?

О чём именно? Ты чувствуешь руку? Ты же не проверяешь каждый раз - есть ли она реально, либо нет. Я не знаю что именно тут можно рассказать. Задавай какой-то более конкретный вопрос.

rustonelove
()
Ответ на: комментарий от tailgunner

У меня нет никаких причин считать, что он знает Си или Си++ на уровне «умею решать практические задачи»

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

azelipupenko
() автор топика
Ответ на: комментарий от azelipupenko

Ты сказал «сишке и цэпепешке ты научился», кто-то другой сказал, что царь в 98% случаев прав. Я считаю, что оба утверждения - чушь, но вдруг я что-то упускаю, а другие видят?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Ты сказал «сишке и цэпепешке ты научился»

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

кто-то другой сказал, что царь в 98% случаев прав

Лол. Прав - это значит, что не виноват? Ну так я тоже в 98% случаев прав. :-)

вдруг я что-то упускаю, а другие видят?

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

azelipupenko
() автор топика

Эволюция Царя

1. Буду все песать на асме, будет быстра пребыстра.

2. Ой, чото нулева на асме воще, лучши нопишу свой езык, убийцу сишки.

3. Да ну свой езык ваще днище, лучши буду царем сишки.

4. Ну а чо, си++ не токой уже и плахой, там есть сишка плюс еще много чиго. <--- Царь находится здесь

5. Указатили все мне абасали и питухи, а у джавы сборка мусара, попацаночке ваще.

6. Императивщина абосаное гавно, а функцианальщина для чистова запила.

7. Байлерплейт лалка и питух, нука чо там за этот ваш лисп.

8. А я всигда знал, что лисп лудший, я проста вас тралил, азазазазза!

anonymous
()
Ответ на: комментарий от azelipupenko

Он продемонстрировал лично мне пример конкатенации строк в компайл-тайме, из чего я могу сделать вывод, что он таки научился программировать на цепепе.

Он все свои троюки из гугла копипастит. Его уже несколько раз не этом ловили.

anonymous
()
Ответ на: комментарий от tailgunner

Да он еще более больной, чем я думал!

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

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

Нашла новую методику. Да какую новую - старую. Эти крысы в надежде, что невтемный человек не пойдёт и не проверит, в надежде, что с этой крысы никто ничего не спорить - врёт.

И вот ты спроси эту крысу про «копипаст из гугла» - оно так же обделается. Почему? Потому что трепло никчёмное.

rustonelove
()
Ответ на: Эволюция Царя от anonymous

Точно так же. Спроси эту крысу за пруфы - точно так же обосрётся.

rustonelove
()
Ответ на: комментарий от tailgunner

Я и твои потуги так же множил на ноль. Ну ничего, авось кто-то негуглит и не почитает.

rustonelove
()
Ответ на: комментарий от I60R

Раскрой сердце своё всей благости nullptr

anonymous
()
Ответ на: комментарий от I60R

чужом

Это проблема чужого кода. Ты с этим ничего не сделаешь. Если ты интегрируешь это инородное тело внутрь/сбоку от своей логики - то тебе нужно его валидировать. Если ты сможешь гарантировать то, что никакой nullptr тебе чужой код никогда не даст - ты можешь его спокойно использовать и ничего не бояться.

как перестать бояться nullptr в коде своём

Очень просто - их просто не должно быть. За примера далеко ходить не надо - их и сейчас в крестах быть не должно. Это прямое отображение той концепции, что описывал я. У тебя есть некий источник( той же памяти), который проверяется и после у тебя есть гарантия на то, что никакого nullptr у тебя в try не будет.

Тебе нужно гарантировать валидность данных/ресурсов приходящих из вне. Делать ты это можешь как угодно. Ты можешь использовать те же свойства всех этих внешних источников. Если этих источников много - их круг можно сузить.

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

Допустим то, что никакой malloc() и обёртки над ним не могут вернуть nullptr при аллокации блоков до 4к НИКОГДА. Да и много чего ещё.

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

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

Ну и так же, не стоит путать nullptr и nullptr как флаг. Обычно все ламерки от мира пхп и прочих рустов над этим часто манипулируют - приписывая nullptr-флаг к проблемам работы с памятью.

rustonelove
()
Ответ на: комментарий от rustonelove

Ты понимаешь, что компилтайм генерация - это оптимизация.

Бред сивой кобылы :-) Лол :-) Компайл-тайм генерация - это генерация во время компиляции :-) А оптимизация - это процесс поиска оптимума чего-либо :-) Так что не неси туфту, сходи в школу :-)

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

Что ты там пиликаешь ахинею? :-) Лол :-) Ты хоть слышишь себя? :-)

Уважаемый балабол

Лол :-) А кто лучше, уважаемый балабол или неуважаемый балабол? :-) Ты себя к какому типу причисляешь? :-)

И после всего этого НИКАКОГО смысла говорить о ПРОИЗВОДИТЕЛЬНОСТИ попросту НЕТ.

С тобой - да :-) Смысла мало :-) Лол :-)

anonymous
()
Ответ на: комментарий от anonymous

Бред сивой кобылы :-) Лол :-) Компайл-тайм генерация - это генерация во время компиляции :-) А оптимизация - это процесс поиска оптимума чего-либо :-) Так что не неси туфту, сходи в школу :-)

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

Давай я тебе покажу как просто и незатейливо ты множишься на ноль.

Компайл-тайм генерация - это генерация во время компиляции

Зачем? В чём заключается смысл компилтайм-генерации в сравнении с рантайм-генерацией?

Ну для публики я объясню. Что пытается сделать эта амёба. Амёба пытается съехать на подмене понятий.

Компайл-тайм генерация - это генерация во время компиляции

Т.е. тут амёба написала «компилтайм-генерация - это компилтай генерация». Мало того, что эта потуга просто не имеет смысла, но суть не в этом.

Это отвечает на вопрос что. Что такое компилтайм-генерация. А теперь смотрим сюда:

А оптимизация - это процесс поиска оптимума чего-либо :-)

И тут ламерок так же пытается ответить на вопрос «что?». Я тут даже не буду разбирать то - почему определения дерьмо. Это неважно.

Дак вот. А процитировал ламерок мне это:

Ты понимаешь, что компилтайм генерация - это оптимизация.

И это отвечает не на вопрос «что?», а на вопрос «зачем?». Это совершенно другое что. Т.е. не что такое компилтайм, а «что это нам даёт?».

Дак вот, компилайм генерация значений - есть оптимизация генерации значений, т.е. поиск оптимума генерации этого самого значения. В примере ламерка - сигнатуры запросы.

Т.е. что в компилтайме, что в рантайме - будет тот же самый запрос/строка. Она будет именно такой и никакой иной. И самый оптимальный способ получения строки в рантайме - это не генерация её в рантайме, а генерация в компилтайме. В этом и смысл компилтайма.

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

rustonelove
()

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

на С++ либы особенно под виндой это просто разрыв жопы. причем у меня есть проект с Qt, shared libs и плагинами в отдельном каталоге, где еще и в процессе сборки под виндой надо все библиотеки складывать в один каталог иначе не линкуется при запуске.

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

с другой, вот я делаю софтину на С++. на питоне её не сделать, просто вообще не сделать. ну или можно но она будет работать меееедленно и жрать как не в себя. как тут сравнить продуктивность?

есть вещи которые можно сделать только на С++, например тот же Qt. это сложные вещи. очень очень сложные. но если оченьсложности нет, то питон продуктивнее. если есть, то продуктивность питона строго равна нулю.

ckotinko ☆☆☆
()
Ответ на: Эволюция Царя от anonymous

Кстати, особенно интересно то, что чуть-ли не первая моя тема на лоре про кресты и она почищена, но не выпилена. Вот ведь незадача. Как ты это объяснишь? Мне даже интересно.

rustonelove
()
Ответ на: комментарий от rustonelove

Давай я тебе покажу как просто и незатейливо ты множишься на ноль.

Нет, не покажешь :-) Скорее надорвёшься :-)

Зачем? В чём заключается смысл компилтайм-генерации в сравнении с рантайм-генерацией?

Смысл генерации заключается в возникновении результата :-) Бывает, он возникает в ходе компиляции, а бывает - в ходе выполнения :-) Не ищи смысла там, где его нет :-) Лол :-)

Дак вот, компилайм генерация значений - есть оптимизация генерации значений

Нет, это бред и ахинея :-) Выбирай из двух что тебе больше нравится :-) Просто компайл-тайм генерация предоставляет результат вычисления ещё до запуска программы :-) Рантайм генерация предоставляет результат уже в ходе работы программы :-) Компайл-тайм генерация отрабатывает ровно один раз в ходе компиляции :-) Но и рантайм генерацию тоже можно выполнить ровно один раз, но это уже на плечах программиста (вот это и будет твоя любимая оптимизация) :-) Но откуда тебе это знать? :-) Лол :-)

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

Не бывает «самого оптимального», как не бывает «чуть менее оптимального» или «чуть более оптимального» :-) Бывает просто «оптимальное» или «неоптимальное» :-) Ты чего-нибудь про экстремумы слышал? :-)

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

Лол :-) Место подобных неучей в школе :-)

anonymous
()
Ответ на: комментарий от anonymous

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

Далее пошли убоги потуги опять уезжать с темы на «что такое компилтай-генерация».

Нет, это бред и ахинея :-) Выбирай из двух что тебе больше нравится :-) Просто компайл-тайм генерация предоставляет результат вычисления ещё до запуска программы :-) Рантайм генерация предоставляет результат уже в ходе работы программы :-) Компайл-тайм генерация отрабатывает ровно один раз в ходе компиляции :-) Но и рантайм генерацию тоже можно выполнить ровно один раз, но это уже на плечах программиста (вот это и будет твоя любимая оптимизация) :-) Но откуда тебе это знать? :-) Лол :-)

Т.е. что из этой ахинеи следует? Ничего. Этого идиота кто-то спрашивал о том, что такое компилтайм-генрация? Нет. Зачем он это пишет? просто так.

Не бывает «самого оптимального», как не бывает «чуть менее оптимального» или «чуть более оптимального» :-) Бывает просто «оптимальное» или «неоптимальное» :-) Ты чего-нибудь про экстремумы слышал? :-)

О, а тут школотёнок решил блеснуть, но опять же - ему это не удастся. А почему? Потому что идиоту с уровнем развития в районе табуретки просто невозможно не обосраться.

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

Допустим, в рантайме нельзя достичь «самым оптимальным» способом, а именно отсутствием вычислений. Но в рантайме можно организовать оптимальные вычисления, но опять же. Оптимальные только в рамках определённых условий и по определённым критериям.

Это логика доступна всем, начиная от развития районе тумбочки, но табуретка пока не доросла.

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

И вот сейчас, эта малоразвитая амёба решили, что со своей убогой потугой может оппонировать мне. Не может.

Лол :-) Место подобных неучей в школе :-)

Это типичное поведение мусора. Оно пытается съехать с темы, пытается подменить понятия, рассказывает про школу из которой ещё не вылезла. Амёбка пытается всех загнать в рамки своей убогости, в рамки своего примитивного понимания, в рамки тех, убогих определений, что ей давали за партой.

А этом и проблема подобных клоунов. Они, будучи невероятно тупыми, свято верят в то, что они смогут кого-то там поймать, подменить и ограничить понятия незаметно для меня. Съехать и поменять тему незаметно для меня.

Пусть верят.

rustonelove
()
Ответ на: комментарий от rustonelove

Тоесть, по твоему, «ручная» проверка всего и вся — лучше системы типов, предоставляющей гарантии по умолчанию?
Или лучше описать все возможности в документации, вместо вернуть Result/Optional?
Делая так, я стану лучше доверять внутренним структурам?
edit: И если не проверкой, то каким ещё образом можно изучить поведение платформы?

I60R ★★
()
Последнее исправление: I60R (всего исправлений: 1)
Ответ на: комментарий от I60R

Тоесть, по твоему, «ручная» проверка всего и вся — лучше системы типов, предоставляющей гарантии по умолчанию?

Где я такое писал? Я как раз писал о том, что если ты можешь эти гарантии взять где-то - то ты их оттуда и берёшь. Там было и про типы и про всё остальное.

Но опять же, есть нюансы. Надо отличать кастыли и гарантии.

Или лучше описать все возможности в документации, вместо вернуть Result/Optional?

Я уже писал о том, что в рядовом коде nullptr ещё используется как флаг отсутствия результата, а не только как какая-то ошибка из вне. Это поведение нужно отличать.

Result/Optional - это именно про это, а так же про возврат ошибок.

Вот ты написал get() -> nullptr - он к тебе пришел. Как ты отличишь ситуацию «нету объекта» и от ситуации «нету памяти». Это решается через в крестах теми же исключениями. А nullptr остался с сишных 70 годов.

Т.е. я не обсуждаю тут nullptr как флаг - он для этого не нужен.

Делая так, я стану лучше доверять внутренним структурам?

nullptr-флаг это твоя внутренняя логика, нету результата - это внутренняя логика. Это мало соотносится с тем, о чём говорил я. Я говорил именно о том, что привноситься в твою программу из вне и что ты внутри неё обрабатываешь.

Если любую твою структуру может инвалидировать что-то из вне - это обратное тому, о чём говорил я. И не важно - проверяешь ты это, либо нет. Я агитировал за то, чтобы сделать так, чтобы подобного в принципе не было.

edit: И если не проверкой, то каким ещё образом можно изучить поведение платформы?

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

И как я уже говорил - для этого в крестах существуют те же исключения. И логика тут очень простая. Любая ошибка из вне нарушает внутреннее состояние программы и это не надо пихать и разбираться с этим где-то внутри.

Что такое платформа? Это железо под которым работает программа, это ОС под которой работает программа. Вот их устройство и надо изучать, если тебе это надо, конечно же. Выше я описал нюансы.

rustonelove
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.