Re[21]: Разработка на чистом C - C/C++

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

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

_>>Получается добавили вы лямды в свой архиватор и он уже не будет пускаться не под win9x ни под winnt ни даже под winxp.
Ops>Запускаться и нормально работать твоя программа под XP будет.
Видимо Вы не пробывали. Просто попробуйте на простом примере. И увидите проблему под другим углом.
Ops>А вот разрабатывать под ней не получится.
Разрабатывать можно и в vim. Но нормального компилятора C++11 под WinXP нету. Если есть дайте ссылку я попробую.

Надо выбрать toolset с поддержкой XP.

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

_>Разрабатывать можно и в vim. Но нормального компилятора C++11 под WinXP нету. Если есть дайте ссылку я попробую.

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

_>Видимо Вы не пробывали. Просто попробуйте на простом примере. И увидите проблему под другим углом.
RTFM

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

S>Или даже вот в таком.

На С это будет так

int ub_ctx_add_ta(struct ub_ctx* ctx, const char* ta)
{
  char* dup = strdup(ta);
  if(!dup) return UB_NOMEM;
  int res = UB_NOERROR;
  lock_basic_lock(&ctx->cfglock);

  if(ctx->finalized) res = UB_AFTERFINAL;
  else
    if(!cfg_strlist_insert(&ctx->env->cfg->trust_anchor_list, dup)) res = UB_NOMEM;

  lock_basic_unlock(&ctx->cfglock);
  free(dup);
  return res;   
}

Чем на С++ лучше, кроме очевидного RAII, совершенно непонятно. И зачем функции дублируются и как это связано с недостатками С тоже непонятно.

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

P>На С это будет так

P>

P>int ub_ctx_add_ta(struct ub_ctx* ctx, const char* ta)
P>{
P>  char* dup = strdup(ta);
P>  if(!dup) return UB_NOMEM;
P>  int res = UB_NOERROR;
P>  lock_basic_lock(&ctx->cfglock);

P>  if(ctx->finalized) res = UB_NOERROR;
P>  else
P>    if(!cfg_strlist_insert(&ctx->env->cfg->trust_anchor_list, dup)) res = UB_AFTERFINAL;

P>  lock_basic_unlock(&ctx->cfglock);
P>  free(dup);
P>  return res;   
P>} 
P>

P>Чем на С++ лучше, кроме очевидного RAII, совершенно непонятно.

Так толсто, что даже тонко. Особенно мне нравится вот это:

int res = UB_NOERROR;
lock_basic_lock(&ctx->cfglock);

if(ctx->finalized) res = UB_NOERROR;

У вас res уже содержит UB_NOERROR. Запутались в трех простых соснах. В типа простом C.

P>И зачем функции дублируются и как это связано с недостатками С тоже непонятно.

Почитайте про шаблоны C++, может станет понятнее.

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

S>У вас res уже содержит UB_NOERROR. Запутались в трех простых соснах. В типа простом C.
Угу, запутался. Коварно воспользуюсь предоставленной возможностью править сообщения.
Но мне простительно. Во-первых, воскресенье же, во-вторых, я в отличие от автора и возможного чтеца кода с вниканием в смысл даже не задумывался что значат эти коды возврата и почему возвращаются именно они.
Но мы же хотели посравнивать С и С++, предлагаю о моей невнимательности забыть

S>Почитайте про шаблоны C++, может станет понятнее.
И что шаблоны? Предположу, что в С проблема решается передачей еще одного параметра, на шаблонах на самом деле лучше получится?

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

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

S>>У вас res уже содержит UB_NOERROR. Запутались в трех простых соснах. В типа простом C.
P>Угу, запутался.

В этом и проблема. В C слишком много деталей, про которые нужно помнить. Поэтому люди путаются.

S>>Почитайте про шаблоны C++, может станет понятнее.
P>И что шаблоны?

Дают удобные средства борьбы с копипастой.

P>Предположу, что в С проблема решается передачей еще одного параметра, на шаблонах на самом деле лучше получится?

Да, решается. Но, в большинстве своем, в C-коде процветает копипаста или чрезмерное использование макросов.

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

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

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

Кстати, а какие в C есть best practices по достижению гибкого и хорошо поддающегося тестированию кода?
Я имею в виду языковой уровень, не уровень архитектуры проекта в целом.

Вот, например, в C++ можно вовсю использовать полиморфизм, т.е. абстрактные классы, скрытие реализации за
"интерфейсами", мок-объекты и т.п. И там оно реализуется естественно, средствами языка. Надо протестить
какой-то компонент, который работает с базой данных — нет проблем, делаем "интерфейс" IDatabase (условно) и
в тестируемом классе работаем с базой через него. А во время теста вместо базы подставляем fake/mock/etc.

А в C что? Макросы на дефайнах? Нет, я понимаю, что на C тоже можно реализовать "объекты" и "методы",
которые будут вызываться через указатели в некой таблице, но насколько я понимаю, такой подход в C не
очень-то распостранен.

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

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

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

O>Кстати, а какие в C есть best practices по достижению гибкого и хорошо поддающегося тестированию кода?
O>Я имею в виду языковой уровень, не уровень архитектуры проекта в целом.
Есть рекомендации по стилю кода, но писать фортраном это не мешает. Еще гибкий и хорошо тестируемый код не всегда я вляется целью.
Оптимизированный код бывает очень трудно читаем, только тесты. Да и в C++ если у вас векторная математика, то читать все интрисикты на трезвую голову тяжко.
А так как и везде decoupling, kiss и т.п. Просто в C приходится писать чуть длиньше, хотя это приводит к тому
что некоторые архитектурные изыски "нинужны".

O>Вот, например, в C++ можно вовсю использовать полиморфизм, т.е. абстрактные классы, скрытие реализации за
O>"интерфейсами", мок-объекты и т.п. И там оно реализуется естественно, средствами языка. Надо протестить
O>какой-то компонент, который работает с базой данных — нет проблем, делаем "интерфейс" IDatabase (условно) и
O>в тестируемом классе работаем с базой через него. А во время теста вместо базы подставляем fake/mock/etc.
Всё тоже самое, но без излишеств, при сборке вместо реализации линкуешь мок объектник.

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

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

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

S>В С++ так же можно вдаваться в крайности и использовать шаблоны ради шаблонов, но лучше иметь мощный инструмент, возможности которого, при необходимости, ограничиваются административными средствами.
Ну вот в этом случае на мой взгляд использование шаблонов здесь и будет извращением. Даже на С++ куда как лучше trust_anchor_file_list, trust_anchor_list, auto_trust_anchor_file_list заменить массивом индексируемым элементами перечисления.

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

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

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

S>>>У вас res уже содержит UB_NOERROR. Запутались в трех простых соснах. В типа простом C.
P>>Угу, запутался.

S>В этом и проблема. В C слишком много деталей, про которые нужно помнить. Поэтому люди путаются.
Как говорит народная мудрость "если у вас голова как жопа то заведте блокнот, или два как у меня"
Что бы помнить детали их приходится записывать на бумагу, а не держать в голове.

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

P>>Предположу, что в С проблема решается передачей еще одного параметра, на шаблонах на самом деле лучше получится?
S>Да, решается. Но, в большинстве своем, в C-коде процветает копипаста или чрезмерное использование макросов.
Макросы используют чтоб меньше писать текста и вынесения общих блоков что бы не заниматься копипастой.
Ничего плохого в макросах, при их правильном применении нет. Плохо что макросы не развились в что-то большее.
Как например в техе.

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

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

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

Вперед!

void 
ub_ctx_add_ta(ub_ctx & ctx, std::string ta)
{
   std::mutex<some_lock> lock(ctx.cfglock);
   if(ctx.finalized)
      throw some_exception(UB_AFTERFINAL);
   ctx.env->cfg->trust_anchor_list.insert(std::move(ta));
}

S>>В С++ так же можно вдаваться в крайности и использовать шаблоны ради шаблонов, но лучше иметь мощный инструмент, возможности которого, при необходимости, ограничиваются административными средствами.
P>Ну вот в этом случае на мой взгляд использование шаблонов здесь и будет извращением. Даже на С++ куда как лучше trust_anchor_file_list, trust_anchor_list, auto_trust_anchor_file_list заменить массивом индексируемым элементами перечисления.

В лоб, совершенно выключив могзи, на C++ можно было бы написать вот так:

template< typename L >
void ub_ctx_add_prop(ub_ctx & ctx, L l )
{
   std::mutex<some_lock> lock(ctx.cfglock);
   if(ctx.finalized)
      throw some_exception(UB_AFTERFINAL);
   l();
}

void ub_ctx_add_ta(ub_ctx & ctx, std::string ta)
{
   ub_ctx_add_prop(ctx, [&ta]{ ctx.env->cfg->trust_anchor_list.insert(std::move(ta)); } );
}

void ub_ctx_add_ta_file(ub_ctx & ctx, std::string ta_file)
{
   ub_ctx_add_prop(ctx, [&ta_file]{ ctx.env->cfg->trust_anchor_file_list.insert(std::move(ta_file)); } );
}
...

И получить точно такой же результат, как с вручную написанной копипастой в C. Только большую часть работы сделает транслятор.

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

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

Ну вам-то эта мудрость не помогает постить сюда примеры кода без ошибок.

S>>Дают удобные средства борьбы с копипастой.
_>И возможность создавать проблемы которых раньше не было.

Огласите весь список, пожалуйста.

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

Если вас обилие деталей при работе с plain old C не пугает, то тут-то чего бояться. На одно могзов (типа) хватает, на второе -- нет?

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

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

Интринсинки заворачиваются в шаблоны, expression templates сами оптимизируют выражения — смотри например Eigen — этой технике уже лет двадцать.

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

_>Макросы используют чтоб меньше писать текста и вынесения общих блоков что бы не заниматься копипастой.
_>Ничего плохого в макросах, при их правильном применении нет. Плохо что макросы не развились в что-то большее.

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

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

EP>>Отсутствие компилятора это один из немногих случаев где оправданно использование C, по очевидным причинам.
_>Есть еще причина. Т.к. C менее универсальный нежели С++ авторы вынужденые реализовывать конкретику, а не абстракции.
_>Такая деятельность дисциплинирует, требует большей ответственности и усердия от ремеслеников, занимающихся подобным трудом.

То есть программисты тратят свои ресурсы на "усердие" и прочую борьбу с языком.

_>И если нужно понять как что-то работает, то смотреть лучше в C реализации, нежели в C++.
_>Что бы далеко не ходить можно посмотреть реализацию базовых операций с полигонами GPC и boost

Конкретный пример — бинарный поиск:

template<typename I, typename P>
I partition_point_m(I first, I last, P p)
{
    while(first != last)
    {
        I middle = first + (last - first)/2;
        if( p(*middle) )
            last = middle;
        else
            first = middle + 1;
    }
    return first;
}

Покажи аналог на C — вот и сравним где понятнее как "что-то работает"

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

S>Вперед!
Так копировал же с варианта, где и UB_AFTERFINAL и UB_NOMEM было, точно так же промахнулся бы. Если бы сам писал заодно соображая — здесь нужно то-то вызвать, оно при этом возникнуть может такая-то ситуация... тогда наверно не ошибся бы и там и там.

S>В лоб, совершенно выключив могзи, на C++ можно было бы написать вот так:
...
...
S>И получить точно такой же результат, как с вручную написанной копипастой в C. Только большую часть работы сделает транслятор.

Вот это и есть извращение

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

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

EP>Конкретный пример — бинарный поиск:
EP>

EP>template<typename I, typename P>
....
....
EP>

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

... << RSDN@Home 1.2.0 alpha 5 rev. 1495>>

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

EP>>Конкретный пример — бинарный поиск:
EP>>

EP>>template<typename I, typename P>
P>....
P>....
EP>>

P>Так это же совсем другое дело, здесь шаблоны как раз к месту применены.

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

если нужно понять как что-то работает, то смотреть лучше в C реализации, нежели в C++

Вот я и прошу показать на простом примере как на C всё становится понятнее.

	От:	kov_serg
	Дата:	06.11.16 08:12
	Оценка:

	От:	swingus
	Дата:	06.11.16 08:29
	Оценка:

	От:	Ops
	Дата:	06.11.16 09:02
	Оценка:	+1

	От:	pagid
	Дата:	06.11.16 09:53
	Оценка:

От:	so5team	https://stiffstream.com
Дата:	06.11.16 10:09
Оценка:	+1

От:	okman	https://searchinform.ru/
Дата:	06.11.16 11:45
Оценка:

	От:	Evgeny.Panasyuk
	Дата:	06.11.16 15:10
	Оценка: