Конструкции C++, заменяющие конструкции C

встроенная инициализация структуры и встроенные конструкторы

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

// C-like code in C++
struct CRect
{
   int x ;
   int y ;
} ;

void doSomething()
{
   CRect r0 ;               // uninitialized
   CRect r1 = { 25, 40 } ;  // vulnerable to some silent struct reordering,
                            // or adding a parameter
}

; Я вижу три проблемы с приведенным выше кодом:

• если объект специально не инициализирован, он не будет инициализирован полностью
• если мы поменяем местами x или y (по любой причине), инициализация C по умолчанию в doSomething () теперь будет неправильной
• если мы добавим элемент z и хотим, чтобы он по умолчанию был "нулевым", нам все равно нужно будет изменить каждую встроенную инициализацию

В приведенном ниже коде конструкторы будут встроены (если они действительно полезны), и, следовательно, будет иметь нулевую стоимость (как код C выше):

// C++
struct CRect
{
   CRect() : x(0), y(0) {} ;
   CRect(int X, int Y) : x(X), y(Y) {} ;
   int x ;
   int y ;
} ;

void doSomething()
{
   CRect r0 ;
   CRect r1(25, 40) ;
}

(Бонус в том, что мы могли бы добавить методы operator ==, но этот бонус не по теме, поэтому стоит упомянуть, но не стоит в качестве ответа.)

Обновлено: C99 назвал инициализированный

Адам Розенфилд сделал интересный комментарий, который я считаю очень интересным:

C99 допускает именованные инициализаторы: CRect r = {.x = 25, .y = 40}

Это не будет компилироваться на C++. Думаю, это нужно добавить в C++, хотя бы для C-совместимости. Во всяком случае, в C это облегчает проблему, упомянутую в этом ответе.

Практически любое использование void*.

Макросы и встроенные шаблоны

Стиль C:

#define max(x,y) (x) > (y) ? (x) : (y)

Стиль C++

inline template<typename T>
const T& max(const T& x, const T& y)
{
   return x > y ? x : y;
}

Причина предпочесть подход C++:

• Безопасность типов - обеспечивает, чтобы аргументы были одного типа.
• Синтаксические ошибки в определении max будут указывать на правильное место, а не на то, где вы вызываете макрос.
• Может отлаживать функцию

Параметры по умолчанию:

C:

void AddUser(LPCSTR lpcstrName, int iAge, const char *lpcstrAddress);
void AddUserByNameOnly(LPCSTR lpcstrName)
  {
  AddUser(lpcstrName, -1,NULL);
  }

Замена / эквивалент C++:

void User::Add(LPCSTR lpcstrName, int iAge=-1, const char *lpcstrAddress=NULL);

Почему это улучшение:

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

RAII и вся последующая слава по сравнению с ручным сбором / выпуском ресурсов

В C:

Resource r;
r = Acquire(...);

... Code that uses r ...

Release(r);

где, например, Resource может быть указателем на память, и Acquire / Release будет выделять / освобождать эту память, или это может быть дескриптор открытого файла, где Acquire / Release откроет / закроет этот файл.

Это создает ряд проблем:

1. Вы можете забыть вызвать Release
2. Код не передает никакой информации о потоке данных для r. Если r приобретается и выпускается в том же объеме, код не документирует это самостоятельно.
3. В течение времени между Resource r и r.Acquire(...), r фактически доступен, несмотря на то, что он не инициализирован. Это источник ошибок.

Применяя методологию RAII (Resource Acquisition Is Initialization), в C++ получаем

class ResourceRAII
{
  Resource rawResource;

  public:
  ResourceRAII(...) {rawResource = Acquire(...);}
  ~ResourceRAII() {Release(rawResource);}

  // Functions for manipulating the resource
};

...

{
  ResourceRAII r(...);

  ... Code that uses r ...
}

Версия C++ гарантирует, что вы не забудете освободить ресурс (если вы это сделаете, у вас будет утечка памяти, которую легче обнаружить инструментами отладки). Это вынуждает программиста четко указать, как поток данных ресурса (то есть: если он существует только во время области действия функции, это будет ясно показано построением ResourceRAII в стеке). Нет точки между созданием объекта ресурса и его уничтожением, когда ресурс недействителен.

Это также безопасно!

iostream против stdio.h

В C:

#include <stdio.h>

int main()
{
    int num = 42;

    printf("%s%d%c", "Hello World\n", num, '\n');

    return 0;
}

Строка формата анализируется во время выполнения, что означает, что она небезопасна по типу.

в C++:

#include <iostream>

int main()
{
    int num = 42;

    std::cout << "Hello World\n" << num << '\n';
}

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

Динамические массивы против контейнеров STL

C-стиль:

int **foo = new int*[n];
for (int x = 0; x < n; ++x) foo[x] = new int[m];
// (...)
for (int x = 0; x < n; ++x) delete[] foo[x];
delete[] foo;

C++ - стиль:

std::vector< std::vector<int> > foo(n, std::vector<int>(m));
// (...)

Почему контейнеры STL лучше:

• Их размер можно изменять, массивы имеют фиксированный размер.
• Они безопасны в отношении исключений - если необработанное исключение возникает в части (...), тогда может произойти утечка памяти массива - контейнер создается в стеке, поэтому он будет должным образом уничтожен во время раскрутки
• Они реализуют проверку привязки, например вектор :: at () (выход за пределы массива, скорее всего, вызовет нарушение доступа и завершит программу)
• Их проще использовать, например vector :: clear () против ручной очистки массива
• Они скрывают детали управления памятью, делая код более читаемым

#define vs. const

Я все время вижу такой код от разработчиков, которые давно пишут на C:

#define MYBUFSIZE 256

.  .  . 

char somestring[MYBUFSIZE];

и т. д. и т. д.

В C++ это было бы лучше:

const int MYBUFSIZE = 256;

char somestring[MYBUFSIZE];

Конечно, еще лучше для разработчика использовать std :: string вместо массива char, но это отдельная проблема.

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

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

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

Функция C qsort по сравнению с шаблоном функции C++ sort. Последний предлагает безопасность типов с помощью шаблонов, которые имеют очевидные и менее очевидные последствия:

• Безопасность типов делает код менее подверженным ошибкам.
• Интерфейс sort немного проще (размер элементов указывать не нужно).
• Компилятору известен тип функции сравнения. Если вместо указателя функции пользователь передает функцию объект, sort выполнит Быстрее, чем qsort, потому что вложение сравнения становится тривиальным. Это не относится к указателям на функции, которые необходимы в версии C.

Следующий пример демонстрирует использование qsort по сравнению с sort на массиве int в стиле C.

int pint_less_than(void const* pa, void const* pb) {
    return *static_cast<int const*>(pa) - *static_cast<int const*>(pb);
}

struct greater_than {
    bool operator ()(int a, int b) {
        return a > b;
    }
};

template <std::size_t Size>
void print(int (&arr)[Size]) {
    std::copy(arr, arr + Size, std::ostream_iterator<int>(std::cout, " "));
    std::cout << std::endl;
}

int main() {
    std::size_t const size = 5;
    int values[] = { 4, 3, 6, 8, 2 };

    { // qsort
        int arr[size];
        std::copy(values, values + size, arr);
        std::qsort(arr, size, sizeof(int), &pint_less_than);
        print(arr);
    }

    { // sort
        int arr[size];
        std::copy(values, values + size, arr);
        std::sort(arr, arr + size);
        print(arr);
    }

    { // sort with custom comparer
        int arr[size];
        std::copy(values, values + size, arr);
        std::sort(arr, arr + size, greater_than());
        print(arr);
    }
}

Следуя сообщению fizzer на Конструкции C++, заменяющие конструкции C, я напишу здесь свой ответ:

Предупреждение: предлагаемое ниже решение C++ не является стандартным C++, а является расширением для g ++ и Visual C++ и предлагается в качестве стандарта для C++ 0x. (Спасибо за комментарии Шипучка по этому поводу)

Обратите внимание, что Йоханнес Шауб - ответ litb в любом случае предлагает другой способ, совместимый с C++ 03.

Вопрос

Как извлечь размер массива C?

Предлагаемое решение C

Источник: Когда полезны макросы C++?

#define ARRAY_SIZE(arr) (sizeof arr / sizeof arr[0])

В отличие от «предпочтительного» шаблонного решения, обсуждаемого в текущем потоке, вы можете использовать его как постоянное выражение:

char src[23];
int dest[ARRAY_SIZE(src)];

Я не согласен с Fizzer, поскольку существует шаблонное решение, способное генерировать постоянное выражение (на самом деле, очень интересная часть шаблонов - это их способность генерировать постоянные выражения при компиляции)

В любом случае, ARRAY_SIZE - это макрос, способный извлекать размер массива C. Я не буду вдаваться в подробности о макросах в C++: цель состоит в том, чтобы найти такое же или лучшее решение для C++.

Лучшее решение на C++?

Следующая версия C++ не имеет никаких проблем с макросами и может делать что-нибудь аналогичным образом:

template <typename T, size_t size>
inline size_t array_size(T (&p)[size])
{
   // return sizeof(p)/sizeof(p[0]) ;
   return size ; // corrected after Konrad Rudolph's comment.
}

демонстрация

Как демонстрирует следующий код:

#include <iostream>

// C-like macro
#define ARRAY_SIZE(arr) (sizeof arr / sizeof arr[0])

// C++ replacement
template <typename T, size_t size>
inline size_t array_size(T (&p)[size])
{
   // return sizeof(p)/sizeof(p[0]) ;
   return size ; // corrected after Konrad Rudolph's comment.
}

int main(int argc, char **argv)
{
   char src[23];
   char * src2 = new char[23] ;
   int dest[ARRAY_SIZE(src)];
   int dest2[array_size(src)];

   std::cout << "ARRAY_SIZE(src)  : " << ARRAY_SIZE(src) << std::endl ;
   std::cout << "array_size(src)  : " << array_size(src) << std::endl ;
   std::cout << "ARRAY_SIZE(src2) : " << ARRAY_SIZE(src2) << std::endl ;
   // The next line won't compile
   //std::cout << "array_size(src2) : " << array_size(src2) << std::endl ;

   return 0;
}

Это выведет:

ARRAY_SIZE(src)  : 23
array_size(src)  : 23
ARRAY_SIZE(src2) : 4

В приведенном выше коде макрос принял указатель за массив и, таким образом, вернул неверное значение (4 вместо 23). Вместо этого шаблон отказался компилироваться:

/main.cpp|539|error: no matching function for call to ‘array_size(char*&)’|

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

Заключение

Таким образом, аргументы в пользу шаблона следующие:

• отсутствие макроподобного загрязнения кода
• может быть скрыт внутри пространства имен
• может защитить от неправильной оценки типа (указатель на память не является массивом)

Примечание: спасибо за реализацию Microsoft strcpy_s для C++ ... Я знал, что однажды это пригодится мне ... ^ _ ^

http://msdn.microsoft.com/en-us/library/td1esda9.aspx

Обновлено: решение представляет собой расширение, стандартизированное для C++ 0x

Fizzer правильно прокомментировал, что это недопустимо в текущем стандарте C++ и было совершенно правдой (как я мог проверить на g ++ с установленной опцией -pedantic).

Тем не менее, сегодня это можно не только использовать в двух основных компиляторах (то есть Visual C++ и g ++), но это было рассмотрено для C++ 0x, как предлагается в следующих черновиках:

• http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1521.pdf (см. Разделы «2.1 Функции константных выражений»)
• http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2691.pdf (см. Разделы «5.19 Постоянные выражения» и «7.1.5 Спецификатор constexpr»)

Единственное изменение для C++ 0x, вероятно, выглядит примерно так:

inline template <typename T, size_t size>
constexpr size_t array_size(T (&p)[size])
{
   //return sizeof(p)/sizeof(p[0]) ;
   return size ; // corrected after Konrad Rudolph's comment.
}

(обратите внимание на ключевое слово constexpr)

Редактировать 2

Йоханнес Шауб - ответ litb предлагает другой способ, совместимый с C++ 03. Я скопирую сюда источник для справки, но обязательно посетите его ответ, чтобы увидеть полный пример (и модернизируйте его!):

template<typename T, size_t N> char (& array_size(T(&)[N]) )[N];

Что используется как:

int p[] = { 1, 2, 3, 4, 5, 6 };
int u[sizeof array_size(p)]; // we get the size (6) at compile time.

Многие нейроны в моем мозгу сгорели, чтобы я понял природу array_size (подсказка: это функция, возвращающая ссылку на массив из N символов).

:-)

приведение C-пути (type) к static_cast<type>(). см. там и там в stackoverflow по теме

Объявление локальных (автоматических) переменных

(Неправда с C99, как правильно указал Джонатан Леффлер)

В C вы должны объявить все локальные переменные в начале блока, в котором они определены.

В C++ можно (и желательно) отложить определение переменной до того, как ее нужно будет использовать. Позже предпочтительнее по двум основным причинам:

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

Перегруженные функции:

C:

AddUserName(int userid, NameInfo nameinfo);
AddUserAge(int userid, int iAge);
AddUserAddress(int userid, AddressInfo addressinfo);

Эквивалент / замена C++:

User::AddInfo(NameInfo nameinfo);
User::AddInfo(int iAge);
User::AddInfo(AddressInfo addressInfo);

Почему это улучшение:

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

iostreams

Форматированный ввод-вывод может быть быстрее при использовании среды выполнения C. Но я не верю, что низкоуровневый ввод-вывод (чтение, запись и т. д.) Работает медленнее с потоками. Возможность читать или писать в поток, не заботясь о том, является ли другой конец файлом, строкой, сокетом или каким-либо определяемым пользователем объектом, невероятно полезна.

В ответ на Алекс Че и справедливости ради C:

В C99, текущей спецификации стандарта ISO для C, переменные могут быть объявлены в любом месте блока, как и в C++. Следующий код действителен C99:

int main(void)
{
   for(int i = 0; i < 10; i++)
      ...

   int r = 0;
   return r;
}

Я предлагаю кое-что, что, возможно, совершенно очевидно, - Пространства имен.

Переполненная глобальная область видимости c:

void PrintToScreen(const char *pBuffer);
void PrintToFile(const char *pBuffer);
void PrintToSocket(const char *pBuffer);
void PrintPrettyToScreen(const char *pBuffer);

против.

Определяемые C++ подразделения глобальной области видимости, пространства имен:

namespace Screen
{
   void Print(const char *pBuffer);
}

namespace File
{
   void Print(const char *pBuffer);
}

namespace Socket
{
   void Print(const char *pBuffer);
}

namespace PrettyScreen
{
   void Print(const char *pBuffer);
}

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

В c большая часть ваших динамических функций достигается за счет передачи указателей на функции. C++ позволяет иметь объекты-функции, обеспечивая большую гибкость и безопасность. Я представлю пример, адаптированный из превосходного Общие знания C++ Стивена Дьюхерста.

Указатели функций C:

int fibonacci() {
  static int a0 = 0, a1 =1; // problematic....
  int temp = a0;
  a0 = a1;
  a1 = temp + a0;
  return temp;
}

void Graph( (int)(*func)(void) );
void Graph2( (int)(*func1)(void), (int)(*func2)(void) ); 

Graph(fibonacci);
Graph2(fibonacci,fibonacci);

Вы можете видеть, что, учитывая статические переменные в функции fibonacci(), порядок выполнения Graph и Graph2() изменит поведение, несмотря на тот факт, что вызов Graph2() может иметь неожиданные результаты, поскольку каждый вызов func1 и func2 приведет к следующему значение в серии, а не следующее значение в отдельном экземпляре серии по отношению к вызываемой функции. (Очевидно, вы могли бы экстернализовать состояние функции, но в этом не было бы смысла, не говоря уже о том, что это сбивает пользователя с толку и усложняет клиентские функции)

Объекты функций C++:

class Fib {
  public:
    Fib() : a0_(1), a1_(1) {}
    int operator();
  private:
    int a0_, a1_;
};
int Fib::operator() {
    int temp = a0_;
    a0_ = a1_;
    a1_ = temp + a0_;
    return temp;
}


template <class FuncT>
void Graph( FuncT &func );

template <class FuncT>
void Graph2( FuncT &func1, FuncT &func2); 

Fib a,b,c;
Graph(a);
Graph2(b,c);

Здесь порядок выполнения функций Graph() и Graph2() не меняет результат вызова. Кроме того, при обращении к Graph2()b и c поддерживают отдельное состояние по мере их использования; каждый будет генерировать полную последовательность Фибоначчи индивидуально.

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

template<typename T, size_t N> char (& array_size(T(&)[N]) )[N];

Я написал это в некоторых других своих ответах, но он не подходит лучше, чем в этом потоке. Итак, вот как его можно использовать:

void pass(int *q) {
    int n1 = sizeof(q); // oops, size of the pointer!
    int n2 = sizeof array_size(q); // error! q is not an array!
}

int main() {
    int p[] = { 1, 2, 3, 4, 5, 6 };
    int u[sizeof array_size(p)]; // we get the size at compile time.

    pass(p);
}

Преимущество перед размером

1. Не работает для не массивов. Будет ли нет тихо работать для указателей
2. В коде скажет, что размер массива взят.

новое в C++ против malloc в C. (для управления памятью)

Оператор new позволяет вызывать конструкторы классов, тогда как malloc - нет.

std::copy против memcpy

Во-первых, есть проблемы с удобством использования:

• memcpy принимает недействительные указатели. Это отбрасывает безопасность типов.
• std::copy допускает перекрытие диапазонов в определенных случаях (с std::copy_backward, существующим для других случаев перекрытия), в то время как memcpy никогда не допускает этого.
• memcpy работает только с указателями, а std::copy работает с итераторами (из которых указатели являются особым случаем, поэтому std::copy работает и с указателями). Это означает, что вы можете, например, включить элементы std::copy в std::list.

Разумеется, вся эта дополнительная безопасность и универсальность имеют свою цену, не так ли?

Когда я измерил, я обнаружил, что std::copy имел небольшое преимущество в производительности по сравнению с memcpy.

Другими словами, кажется, что нет причин использовать memcpy в реальном коде C++.