Войти
ПрограммированиеФорумОбщее

C++20 vs C11 (2 стр)

Страницы: 1 2 3 4 5 Следующая »
#15
11:13, 4 июня 2018

Delfigamer
> enum gpu_model
> {
> UNKNOWN = -1,
> INTEL = 0,
> AMD = 1,
> ATI = 2,
> NVIDIA = 3
> };
>
> inline int GetGPU()
> {
> char* gpu_vendor = strupr(strdup((char*)glGetString(GL_VENDOR)));
> if(strstr(gpu_vendor, "AMD") != NULL) return AMD;
> if(strstr(gpu_vendor, "ATI") != NULL) return ATI;
> if(strstr(gpu_vendor, "NVIDIA") != NULL) return NVIDIA;
> if(strstr(gpu_vendor, "INTEL") != NULL) return INTEL;
> return UNKNOWN;
> }
а где тут C++ ?


#16
11:29, 4 июня 2018
FlyOfFly
> а где тут C++ ?
inline же
#17
11:33, 4 июня 2018

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

...Что, не заметили ошибку? Ничего удивительного, в чистом си такая ситуация - это норма.
Ошибка заключается в том, что результат strdup не освобождается перед выходом из функции.
Соответственно, иллюстрация заключается в том, чтобы реализовать корректную аллокацию и освобождение: с одной стороны - средствами чистого си, с другой - средствами С++; а затем сравнить два варианта и оценить их по следующим параметрам:
- объём кода,
- лёгкость для чтения,
- вероятность совершить ошибку при написании - или, что практически эквивалентно, вероятность упустить ошибку при повторном прочтении.

#18
12:13, 4 июня 2018

Delfigamer
> с одной стороны - средствами чистого си, с другой - средствами С++;

enum gpu_model
{
  UNKNOWN = -1,
  INTEL   = 0,
  AMD     = 1,
  ATI     = 2,
  NVIDIA  = 3
};

int GetGPU()
{
  char* gpu_vendor = (char*)glGetString(GL_VENDOR);
  if(strstri(gpu_vendor, "AMD") != NULL) return AMD;
  if(strstri(gpu_vendor, "ATI") != NULL) return ATI;
  if(strstri(gpu_vendor, "NVIDIA") != NULL) return NVIDIA;
  if(strstri(gpu_vendor, "INTEL") != NULL) return INTEL;
  return UNKNOWN;
}

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

#19
12:20, 4 июня 2018

exchg
> > иллюстрация заключается в том, чтобы реализовать корректную аллокацию и
> > освобождение
> Они тут вообще не нужны.
Давайте ради примера на минуту представим, что вместо сравнения строк - у нас операция, которой действительно нужен дополнительный временный буфер, и эта операция содержит 5 возвратов в разных местах функции.
Или вам прямо обязательно надо откопать реальный пример такой функции?

#20
12:32, 4 июня 2018

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

С другой стороны очевидно что имея раи код будет короче за счет автоматики. Но при
упорном желании делать несколько точек выход в Си можно использовать
__attribute__((cleanup(...))), но зачем?


Delfigamer
> Или вам прямо обязательно надо откопать реальный пример такой функции?
Да нет, мне просто не совсем понятен смысл.

#21
12:50, 4 июня 2018

Господи, развели вокруг С++ какое-то сектантство. Язык как язык, со своими плюсами и минусами. Почему-то у одних он вызывает благоговейный трепет, у других - схватки, потуги и преждевременный отход вод.

#22
12:54, 4 июня 2018

exchg
> Проблема в том, что в структурном программировании должна быть одна точка
> выхода.
Структурное программирование не всегда является лучшим решением проблемы.

exchg
> С другой стороны очевидно что имея раи код будет короче за счет автоматики. Но
> при
> упорном желании делать несколько точек выход в Си можно использовать
> __attribute__((cleanup(...))), но зачем?
Delfigamer
> - объём кода,
> - лёгкость для чтения,
> - вероятность совершить ошибку при написании - или, что практически
> эквивалентно, вероятность упустить ошибку при повторном прочтении.
exchg
> __attribute__((cleanup(...)))
- портируемость.

Went
> Господи, развели вокруг С++ какое-то сектантство. Язык как язык, со своими
> плюсами и минусами. Почему-то у одних он вызывает благоговейный трепет, у
> других - схватки, потуги и преждевременный отход вод.
Delfigamer
> А есть какие-то веские причины использовать C вместо C++11?
Ну давай, расскажи про плюсы преимущества си перед плюсами и недостатки плюсов перед си, я внимательно слушаю

#23
13:18, 4 июня 2018

Delfigamer
> Структурное программирование не всегда является лучшим решением проблемы.
Да? А почему вы тогда пишете в структурном стиле? ))

> - портируемость.
Ну как я сказал это можно использовать, но не нужно. Этот пример сам по себе неудачный.
Я пишу на Си и вот так бы я не писал, я бы писал как то так (да да, я знаю что для С++ ребят
это говнокод):

#define AS_ENUM(a, b) a,
#define AS_ARRAY(a, b) [a] = b,
#define GPU_MODEL(X)                            \
    X(AMD,    "AMD")                            \
    X(ATI,    "ATI")                            \
    X(INTEL,  "INTEL")                          \
    X(NVIDIA, "NVIDIA")                         \

enum gpu_model {GPU_MODEL(AS_ENUM) UNKNOWN};
const char* gpu_model_str[] = {GPU_MODEL(AS_ARRAY) };

enum gpu_model GetGPU(void)
{
    char* gpu_vendor = (char*)glGetString(GL_VENDOR);
    for (u=0; u<UNKNOWN && !strstri(gpu_vendor, gpu_model_str[u]); ++u)
        ;
    return u;
}

Как видно никаких проблем с аллокацией и последующим освобождение в данном примере нету.

#24
13:27, 4 июня 2018

Delfigamer
> Ну давай, расскажи про преимущества си перед плюсами и недостатки плюсов перед си, я внимательно слушаю
Собственно, я не утверждал, что у С есть какие-то преимущества перед С++ (какой редакцией?). Вообще, какие могут быть преимущества у подмножества перед надмножеством? Очевидно, простота. Несмотря на то, что я в целом поддерживаю развитие С++ к новым стандартам, очевидно, что этот динамизм бьет по портируемости между компиляторами. Вот, например, возьму я последний хкод и буду ввертывать новомодные фишки везде. А потом потребуется собрать на каком-то древнем, вижуале. И "упс!". А С это проще. Новомодных фишек меньше, их можно вообще не использовать, и чувствовать себя сухо и комфортно практические везде.

#25
13:53, 4 июня 2018

У нас перед полным переходом в C++20 и выше есть одна преграда - Vulkan API (а вернее, vulkan.h), который бы неплохо было бы переделать в C++ аж на уровне стандарта Khronos.
Я в разработке низкоуровненного API для трассировки лучей окончательно задался вопросом практически на уровне философии: идти по стандарту Khronos в стиле C, или забросить все нахрен и переходить на C++ экосистему (со всеми optional, "vk::", и т.д.).
Дело в том, что в C++ хотят полностью избавиться от raw указателей.

#26
14:09, 4 июня 2018

elviras9t
> Дело в том, что в C++ хотят полностью избавиться от raw указателей.
Кто такое сказал, как это "избавиться"?

#27
14:47, 4 июня 2018

exchg
Окей, мой запрос явно не поняли, поэтому вот вам специально найденный боевой код - cv::HoughLinesSDiv.
Он реализован на C++.
В теле функции - 5 временных буферов, один динамический массив, фоллбек на альтернативную реализацию для особых вариантов посередине тела:

    if( count * 100 > rn * tn )
    {
        HoughLinesStandard( image, lines, type, rho, theta, threshold, linesMax, min_theta, max_theta );
        return;
    }
и работа с абстрактными внешними контейнерами:
    lines.create((int)lst.size(), 1, type);
    Mat _lines = lines.getMat();
    for( size_t idx = 0; idx < lst.size(); idx++ )
    {
      // ...
      _lines.at<Vec2f>((int)idx) = Vec2f(lst[idx].rho, lst[idx].theta);
      // ...
    }
Кто-то из вас серьёзно считает, что ручная возня с всем этим сделать для кода что-то хорошее?

exchg
> Как видно никаких проблем с аллокацией и последующим освобождение в данном
> примере нету.
Ты уверен?
Delfigamer
> > - лёгкость для чтения,
> > - вероятность совершить ошибку при написании - или, что практически
> > эквивалентно, вероятность упустить ошибку при повторном прочтении.
Прежде всего, твой код - это чёрная магия, а за неё принято ругать матом.
А кроме этого, я вижу у тебя в коде ошибки. А даже после исправлений, он всё равно либо не переваривается компилятором С++, либо error LNK2019: unresolved external symbol strstri referenced in function GetGPU.

+ Мой вариант, разумеется,

Went
> какой редакцией?
> C++11
Went
> Очевидно, простота.
Вот в #23, извините, лично мне простота нихрена не очевидна.
Went
> А С это проще. Новомодных фишек меньше, их можно вообще не использовать, и
> чувствовать себя сухо и комфортно практические везде.
Вообще не аргумент. То же самое я уже сказал про C++ - новое можно не использовать.
Отличие в том, что в С++ есть возможность сделать код лучше по параметрам
> - объём кода,
> - лёгкость для чтения,
> - вероятность совершить ошибку при написании - или, что практически
> эквивалентно, вероятность упустить ошибку при повторном прочтении,
> - портируемость.
а в чистом си этой возможности нет - ты либо занимаешься сексом с malloc/free, либо занимаешься сексом с макросами, либо занимаешься сексом с сомнительными расширениями, либо все вместе занимаются сексом с тобой. Почему RAII в крестах не является таким садомазохизмом? Потому что
> - объём кода,
> - лёгкость для чтения,
> - вероятность совершить ошибку при написании - или, что практически
> эквивалентно, вероятность упустить ошибку при повторном прочтении,
> - портируемость.

#28
14:54, 4 июня 2018

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

> Ты уверен?
Да, в том примере о котором я говорил проблем нету.

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

> А кроме этого, я вижу у тебя в коде ошибки.
Потому, что это набросок.

> А даже после исправлений, он всё равно либо не переваривается компилятором С++,
> либо error LNK2019: unresolved external symbol strstri referenced in function
> GetGPU.
Во первых это С код а не С++, во вторых что мешает реализовать 'strstri()' ?

> + Мой вариант, разумеется,
Я бы так не писал. Если у вас в С++ это нормальный код, в чем я сомневаюсь, то пишите так.

#29
15:13, 4 июня 2018

Delfigamer
> я вижу у тебя в коде ошибки. А даже после исправлений
Самую главную не исправил. Функция всегда возвращает либо AMD либо ATI и никогда правильно.

Delfigamer
> Мой вариант
> strupr
Нет такой функции.

Страницы: 1 2 3 4 5 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.