Здравствуйте, so5team, Вы писали:

V>>Вам объяснить как в С можно решить всё без шаблонов и магии?
S>Не всё, а пример, на который вы сослались. Но, т.к. с этим вряд ли получится, давайте вернемся чуток назад.
Зачем решать то что и не нужно было решать?

S>Я вам показал грабли с malloc/free. Типичные, про которые должен знать любой разработчик на C. Вы от этого примера отмахнулись и заявили, что это ерунда по сравнению с проблемами шаблонов и enable_if.
Да, ерунда, потому-что эти проблемы разжеваны и пережёваны тысячу раз, и не являются из разряда чего-то сверхъестественного и решаются макросами.

S>Ну так покажите же эти проблемы. Где они? В синтетическом тесте, который специально был написан, чтобы показать проблему о которой раньше никто не задумывался? Прекрасный аргумент. Какое отношение это имеет к повседневной разработке на C++?
Таких вопросов на форуме С++ вагон и маленькая тележка и ты спрашиваешь какое оно к С++ имеет отношение? У авторов не пробовал спросить?

V>>Брехня
S>Ожидаю, что все остальные аргументы будут какого же уровня.

Т.е. придется сравнивать "сложное" с "невозможным".

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

Здравствуйте, Vain, Вы писали:

V>На С решают прикладные проблемы

причем в основном путем ручной эмуляции конструкций, которые являются частью языка C++

Здравствуйте, landerhigh, Вы писали:

V>>На С решают прикладные проблемы
L>причем в основном путем ручной эмуляции конструкций, которые являются частью языка C++
L>)
Зато нету особого выбора между шашечками и пишешь сразу по делу

Здравствуйте, Vain, Вы писали:

V>Зато нету особого выбора между шашечками и пишешь сразу по делу

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

Здравствуйте, landerhigh, Вы писали:

V>>Зато нету особого выбора между шашечками и пишешь сразу по делу
L>ага. пишешь сначала виртуальные таблицы вручную, потом конструкторы вручную, потом освобождение ресурсов вручную, а потом, если время останется, уже можно и по делу
Зачем, там уже всё написано. Бери да пользуй. Я даже в своё время удивился, что такое вообще возможно.

Здравствуйте, Vain, Вы писали:

V>>>Вам объяснить как в С можно решить всё без шаблонов и магии?
S>>Не всё, а пример, на который вы сослались. Но, т.к. с этим вряд ли получится, давайте вернемся чуток назад.
V>Зачем решать то что и не нужно было решать?

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

S>>Я вам показал грабли с malloc/free. Типичные, про которые должен знать любой разработчик на C. Вы от этого примера отмахнулись и заявили, что это ерунда по сравнению с проблемами шаблонов и enable_if.
V>Да, ерунда, потому-что эти проблемы разжеваны и пережёваны тысячу раз, и не являются из разряда чего-то сверхъестественного и решаются макросами.

Еще раз. Вот пример граблей на C:

void foo() {
  char * b = malloc(1024);
  ...
}

Вот как это решается на C++, номер раз:

void foo() {
  auto b = std::make_unique<char[]>(1024);
  ...
}

номер два:

void foo() {
  std::vector<char> b(1024);
  ...
}

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

V>>>Брехня
S>>Ожидаю, что все остальные аргументы будут какого же уровня.
V>

V>Т.е. придется сравнивать "сложное" с "невозможным".

V>Ты сам придумал задачу, которую невозможно решить на С и сделал неверный вывод что С не сможет решать задачи С++. На С решают прикладные проблемы, а не сахарные конструкции из С++.

Давайте уж цитировать полностью:

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

Сможете показать решение какой-то нетривиальной проблемы на C и C++ дабы их сравнить можно было?

Здравствуйте, so5team, Вы писали:

S>Покажите, пожалуйста, пример реальной проблемы с enable_if, с которой может столкнуться обычный разработчик на C++, и способы ее обхода в чистом C.
Да нет реальной проблемы на C++ с enable_if. На C такой проблемы нет, там другие проблемы.

S>Сможете показать решение какой-то нетривиальной проблемы на C и C++ дабы их сравнить можно было?
Выведите адреса виртуальных методов класса

Здравствуйте, Vain, Вы писали:

V>Здравствуйте, _NN_, Вы писали:

_NN>>Не стесняемся, угадываем выхлоп программы
V>6?

А теперь проверьте себя

https://www.tutorialspoint.com/compile_c99_online.php
http://godbolt.org/

Здравствуйте, so5team, Вы писали:

V>>Зачем решать то что и не нужно было решать?
S>Вы-то этого не знаете.
Я это знаю, потому-что писал на С много времени и мне есть что сравнивать.

S>>>Я вам показал грабли с malloc/free. Типичные, про которые должен знать любой разработчик на C. Вы от этого примера отмахнулись и заявили, что это ерунда по сравнению с проблемами шаблонов и enable_if.
V>>Да, ерунда, потому-что эти проблемы разжеваны и пережёваны тысячу раз, и не являются из разряда чего-то сверхъестественного и решаются макросами.
S>Еще раз. Вот пример граблей на C:
И? Как будто лики это такая большая проблема в С. В С++ так же прекрасно возникают лики, т.к. приходится всё-равно где-то работать с сырыми указателями. Иначе бы просто не нужны были все эти тулы для поиска ликов, представь, в С++.
А при бездумном использовании смартпоинтеров возникает ещё большая проблема "висящих" объектов, которые хрен знает кто держит в момент деинициализации или выгрузки, что бывает ещё хуже.

S>Покажите, пожалуйста, пример реальной проблемы с enable_if, с которой может столкнуться обычный разработчик на C++, и способы ее обхода в чистом C.
Нагромождения нечитаемого кода и непонятные косяки с выборкой перегруженной функции-шаблона не реальные проблемы?

S>Сможете показать решение какой-то нетривиальной проблемы на C и C++ дабы их сравнить можно было?
Проблему придумаешь? А то мы кругами ходим.

Здравствуйте, Vain, Вы писали:

V>>>Зачем решать то что и не нужно было решать?
S>>Вы-то этого не знаете.
V>Я это знаю, потому-что писал на С много времени и мне есть что сравнивать.

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

S>>Еще раз. Вот пример граблей на C:
V>И? Как будто лики это такая большая проблема в С.

Окай.

S>>Покажите, пожалуйста, пример реальной проблемы с enable_if, с которой может столкнуться обычный разработчик на C++, и способы ее обхода в чистом C.
V>Нагромождения нечитаемого кода и непонятные косяки с выборкой перегруженной функции-шаблона не реальные проблемы?

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

S>>Сможете показать решение какой-то нетривиальной проблемы на C и C++ дабы их сравнить можно было?
V>Проблему придумаешь? А то мы кругами ходим.

Я не вижу проблем с C++, но я и не пишу мудреный код с обилием enable_if и с проблемами перегрузки шаблонов функций. Вы постоянно твердите про какие-то проблемы и про то, что на C все решается проще. Так что странно, что ни одного примера вы пока не привели.

Здравствуйте, _NN_, Вы писали:

_NN>>>Не стесняемся, угадываем выхлоп программы
V>>6?
_NN>А теперь проверьте себя
_NN>https://www.tutorialspoint.com/compile_c99_online.php
_NN>http://godbolt.org/
Первый раз это расширение вижу, но clang ошибку показал:

#include <stdio.h>
  
#define type_x(T) _Generic( (T), double*: 1, double: 2, default: 3)
#define type_idx(T) _Generic( (T), char: 1, int: 2, long: 3, default: type_x( (T) ) + 1.0 * type_x( (T) ))
   
int main(void) {
    printf("%d\n", type_idx(1u)); // warning: format specifies type 'int' but the argument has type 'double' [-Wformat]
    printf("%f\n", type_idx(1u));
    return 0;
}

Здравствуйте, so5team, Вы писали:

V>>Я это знаю, потому-что писал на С много времени и мне есть что сравнивать.
S>Я был бы вам крайне признателен, если бы вы взяли на себя труд следить за нитью обсуждения. А то приходится повторять еще раз: вы взяли с форума пример проблемы в C++. На просьбу показать, как в этом случае себя поведет C, вы сказали, что не знаете, для чего пример был предназначен и в чем именно состояла задача. На это я вам в очередной раз указал. Но сейчас вы говорите о том, что что-то знаете, потому что много писали на C. Чтобы это значило?
Я Вам показал пример того, где в С++ у людей вопросы вызникают с длинными обсуждениями на этом форуме, когда в С таких проблем гораздо меньше и соответственно вопросов на форуме.

S>>>Покажите, пожалуйста, пример реальной проблемы с enable_if, с которой может столкнуться обычный разработчик на C++, и способы ее обхода в чистом C.
V>>Нагромождения нечитаемого кода и непонятные косяки с выборкой перегруженной функции-шаблона не реальные проблемы?
S>В очередной раз вас прошу показать проблему, с которой может столкнуться обычный разработчик, и в которой сложности будут с enable_if.
Покажите мне наконец этого обычного разработчика, потому-что на этом форуме я таких в упор не видел и не вижу.

S>Это же был ваш исходный тезис. Вам его и доказывать.
Сначало докажи, что обычный разработчик не решает подобных проблем.

S>>>Сможете показать решение какой-то нетривиальной проблемы на C и C++ дабы их сравнить можно было?
V>>Проблему придумаешь? А то мы кругами ходим.
S>Я не вижу проблем с C++, но я и не пишу мудреный код с обилием enable_if и с проблемами перегрузки шаблонов функций. Вы постоянно твердите про какие-то проблемы и про то, что на C все решается проще. Так что странно, что ни одного примера вы пока не привели.
Ты не пишешь, другие пишут и тыкают здесь в качестве примеров. Окай?

Здравствуйте, Vain, Вы писали:

V>Я Вам показал пример того, где в С++ у людей вопросы вызникают с длинными обсуждениями на этом форуме, когда в С таких проблем гораздо меньше и соответственно вопросов на форуме.

Язык C++ многократно сложнее языка C, поэтому когда люди пытаются решить нетривиальную задачу, то они, естественным образом сталкиваются со сложностью языка. И приходят за помощью на профильный форум. Что естественно. Так же естественно, что чем сложнее проблема, тем больше споров и разговоров вызывает ее решение и/или обходные пути.

Так что судить о частоте возникновения проблем с C++ в обычной разработке по обсуждением темных мест C++ на форумах -- это странно. И это во-первых.

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

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

S>>В очередной раз вас прошу показать проблему, с которой может столкнуться обычный разработчик, и в которой сложности будут с enable_if.
V>Покажите мне наконец этого обычного разработчика, потому-что на этом форуме я таких в упор не видел и не вижу.

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

Давайте скажем так: обычный разработчик пишет прикладной код, а не библиотеки, вроде Boost-а, Eigen-а или даже fmtlib-а.

S>>Это же был ваш исходный тезис. Вам его и доказывать.
V>Сначало докажи, что обычный разработчик не решает подобных проблем.

Ну вот я обычный разработчик, у меня нет проблем с enable_if. В стандарт я заглядываю только по следам каких-то обсуждений на профильных форумах. По работе в стандарт иногда приходилось заглядывать во времена VC++ 6.0, дабы проверить соответствие поведения компилятора/STL-я стандарту.

S>>Я не вижу проблем с C++, но я и не пишу мудреный код с обилием enable_if и с проблемами перегрузки шаблонов функций. Вы постоянно твердите про какие-то проблемы и про то, что на C все решается проще. Так что странно, что ни одного примера вы пока не привели.
V>Ты не пишешь, другие пишут и тыкают здесь в качестве примеров. Окай?

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

Здравствуйте, so5team, Вы писали:

V>>Я Вам показал пример того, где в С++ у людей вопросы вызникают с длинными обсуждениями на этом форуме, когда в С таких проблем гораздо меньше и соответственно вопросов на форуме.
S>Язык C++ многократно сложнее языка C, поэтому когда люди пытаются решить нетривиальную задачу, то они, естественным образом сталкиваются со сложностью языка. И приходят за помощью на профильный форум. Что естественно. Так же естественно, что чем сложнее проблема, тем больше споров и разговоров вызывает ее решение и/или обходные пути.
S>Так что судить о частоте возникновения проблем с C++ в обычной разработке по обсуждением темных мест C++ на форумах -- это странно. И это во-первых.
Это было справедливо 20 лет назад. Сейчас язык С++ стал сложнее самого себя в прошлом и продолжает усложняться с кучей груза в виде совместимости, которая стала больше геморроем и для разработчиков, и для производителей компиляторов. Так что это усложнение не естественно ни разу.

S>Во-вторых, позволяет делать то, что не позволяет C.
С на месте тоже не стоит и тоже позволяет делать то, что С++ делал всегда (см. диалекты).

S>Ну и, в-третьих, вам не приходило в голову, что C, мягко говоря, мало кому нужен.
Да, да, мало кому нужен. Именно поэтому он на первых местах во всяких рейтингах

S>>>В очередной раз вас прошу показать проблему, с которой может столкнуться обычный разработчик, и в которой сложности будут с enable_if.
V>>Покажите мне наконец этого обычного разработчика, потому-что на этом форуме я таких в упор не видел и не вижу.
S>Такое ощущение, что вы пытаетесь спрятаться за обсуждением терминов, т.к. доказать свои утверждения примерами не можете.
Спрятались за "докажи существование/отсутствие бога"?

S>Давайте скажем так: обычный разработчик пишет прикладной код, а не библиотеки, вроде Boost-а, Eigen-а или даже fmtlib-а.
Докажи!

S>>>Я не вижу проблем с C++, но я и не пишу мудреный код с обилием enable_if и с проблемами перегрузки шаблонов функций. Вы постоянно твердите про какие-то проблемы и про то, что на C все решается проще. Так что странно, что ни одного примера вы пока не привели.
V>>Ты не пишешь, другие пишут и тыкают здесь в качестве примеров. Окай?
S>Нет. Не надо пенять на других. Вы сами сталкивались с тем, о чем пытаетесь сказать?
Меня эти другие окружают, а я не должен значит? Или, не нравиться, чемодан-вокзал-другой язык?

Здравствуйте, so5team, Вы писали:

S>Язык C++ многократно сложнее языка C, поэтому когда люди пытаются решить нетривиальную задачу, то они, естественным образом сталкиваются со сложностью языка. И приходят за помощью на профильный форум. Что естественно. Так же естественно, что чем сложнее проблема, тем больше споров и разговоров вызывает ее решение и/или обходные пути.
S>Так что судить о частоте возникновения проблем с C++ в обычной разработке по обсуждением темных мест C++ на форумах -- это странно. И это во-первых.
Вот вам статья почему C предпочтительнее С++, из которой можно почерпнуть ответ сразу на несколько ваших вопросов: http://eax.me/c-vs-cpp/

Здравствуйте, Vain, Вы писали:

V>Здравствуйте, _NN_, Вы писали:

_NN>>>>Не стесняемся, угадываем выхлоп программы
V>>>6?
_NN>>А теперь проверьте себя
_NN>>https://www.tutorialspoint.com/compile_c99_online.php
_NN>>http://godbolt.org/
V>Первый раз это расширение вижу,
Это не расширение, а чистый ANSI C: https://en.wikipedia.org/wiki/C11_(C_standard_revision)

V>но clang ошибку показал:
Тут предупреждение, а не ошибка компиляции.
В этом простом прямолинейном коде конечно же легко понять что нужно писать в printf в общем виде.

Здравствуйте, Vain, Вы писали:

V>Это было справедливо 20 лет назад. Сейчас язык С++ стал сложнее самого себя в прошлом и продолжает усложняться с кучей груза в виде совместимости, которая стала больше геморроем и для разработчиков, и для производителей компиляторов. Так что это усложнение не естественно ни разу.

См. выше про компилятораписателей.

V>С на месте тоже не стоит и тоже позволяет делать то, что С++ делал всегда (см. диалекты).

П — переносимость. О — отсутствие.

V>Да, да, мало кому нужен. Именно поэтому он на первых местах во всяких рейтингах

Ссылка на TIOBE, как на авторитет. Показательно.

V>Меня эти другие окружают, а я не должен значит? Или, не нравиться, чемодан-вокзал-другой язык?

К — конструктивность.

V>Вот вам статья почему C предпочтительнее С++, из которой можно почерпнуть ответ сразу на несколько ваших вопросов: http://eax.me/c-vs-cpp/

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

Так что не того авторитета вы привели, ох не того. Особенно после эпичного фейла с попыткой обосрать Rust. Надо было сразу с козырей заходить, с Линуса, вашего, Торвальдса.

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

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

Здравствуйте, Vain, Вы писали:

V>Вот вам статья почему C предпочтительнее С++, из которой можно почерпнуть ответ сразу на несколько ваших вопросов: http://eax.me/c-vs-cpp/

Пример с торможением там отлично описывает уровень всего поста. Это

Здравствуйте, so5team, Вы писали:

S>Покажите, пожалуйста, пример реальной проблемы с enable_if, с которой может столкнуться обычный разработчик на C++, и способы ее обхода в чистом C.

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

Здравствуйте, Lexey, Вы писали:

L>Здравствуйте, Vain, Вы писали:

V>>Вот вам статья почему C предпочтительнее С++, из которой можно почерпнуть ответ сразу на несколько ваших вопросов: http://eax.me/c-vs-cpp/

L>Пример с торможением там отлично описывает уровень всего поста. Это
Вам не надоело обсуждать всякую ерунду? Скорость тут совершенно не причем. Весь современный софт уже давно ценит не ресурсы, а монетизацию.
Проблема в том что C++ способен порождать больше абстрактных проблем на ровном месте, особенно в командах разработчиков и
в условиях его постоянной эволюции к комфортному программированию.
Напоминаю что человек всегда стремится к комфорту, это главная цель мозга комфортно ничего не делать и экономить энергию.
Использовать шаблоны патерны и предыдущий успешный опыт — "думать лучше лёжа". Создание чего-то нового всегда требует внешнего насилия.