Использование/Смешивание C в коде С++?

Ответ 1

Я постоянно говорю им, что, пока вы знаете, что делаете, и вы удаляете свой новый и освобождаете свой malloc, тогда C не проблема.

Это правда; если вы необычайно осторожны и убедитесь, что вы вручную очищаете вещи, это не проблема. Но у вас действительно есть время для этого? Каждый вызов new может вызывать std::bad_alloc. Вы всегда поймаете все исключения, которые могут быть выброшены и вручную очистить любые ресурсы?

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

Если ответ "да", то почему вы тратите столько времени на беспокойство по поводу управления ресурсами? Идиомы С++, такие как управление ресурсами с привязкой к области (SBRM, более широко известная как сбор ресурсов, - это инициализация (RAII)), и библиотеки, подобные стандартной библиотеке шаблонов, помогут вам легче написать правильный код. Почему все труднее, когда вам не нужно?

Если вы используете ТОЛЬКО 100% С++ при кодировании С++?

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

Ответ 2

Мое убеждение в том, что ваш вопрос вообще не связан с C или С++. Ваш вопрос о торговле сомнительной эффективностью для безопасности. Да, C может быть более эффективным. Но насколько эффективнее? И что вы платите за это? Это вопросы, на которые вы должны ответить. В большинстве случаев накладные расходы string vs. const char * незаметны. Если вы разрабатываете приложение с чрезвычайно высокой критичностью, то почему бы не записать его на C в первую очередь?

Ответ 3

Я искренне удивлен поляризацией в ответах и ​​комментариях.

В моих глазах ответ довольно прост:

При написании проекта на С++ используйте С++, избегайте C (и семейства) и придерживайтесь стандартной библиотеки и STL. Обеспечьте однородный С++-интерфейс (это все-таки С++-проект!) При использовании внешнего проекта в C, который, как представляется, написан на C, вы можете его использовать. (см. примеры ниже)

Два простых примера:

• Напишите программу/библиотеку С++, которая выполняет научные вычисления. Я бы определенно использовал GSL (Научная библиотека GNU), и он написан на C. Существует только несколько предостережений (таких как специализированные инициализации и бесплатные функции для конкретных структур и функций в GSL), которые могут быть поглощены std::unique_ptr typedef, Существует также проблема обработки ошибок: проверка кодов ошибок может быть абстрагирована в случае механизма исключения, если это необходимо/требуется, или вы можете сохранить коды ошибок, содержащиеся в функциях расчета. У GSL есть способ настроить обработчик ошибок, я полагаю, что некоторые другие библиотеки C имеют такую ​​функциональность.

• Написание программы на С++ с использованием Win32 API, который ужасно основан на C. Я говорю об использовании легкого API, например, чтении файлов в каталоге, проверке наличия файла и т.д., А не тяжелом GDI + или других материалах. Мне нравится обертывать все функции C, которые предоставляет API Win32 в приятных функциях стиля С++, возможно, с необходимыми исключениями и возвращая std::string вместо того, чтобы передавать в качестве аргумента буфер char*.

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

Ответ 4

Лучший вопрос здесь: зачем использовать C? Представление? Во-первых, я считаю, что нет никакой измеримой разницы в производительности для программы с той же функцией. Во-вторых, вам нужно будет профилировать и доказать, что для вашего конкретного случая С++ медленнее. В-третьих, вы отказываетесь от огромного количества безопасности приложений, используя C вместо С++.

Ответ 5

изменение аргумента по std::string vs char *.

std::string не будет медленнее, чем char * (для кучи char *); многие реализации намного быстрее, потому что они используют частный пул памяти. И в любом случае надежность std::string намного превосходит любой (маловероятный) перфомант

Ответ 6

Ответ, конечно: это зависит.

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

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

Это очень редкий случай, когда использование char * over std::string даст вам какие-либо заметные преимущества в производительности, и это стоит того, чтобы справляться с проблемами управления памятью в тех случаях, когда это действительно делается.

Ответ 7

Да, плохо смешивать C и С++, любая причина не имеет ничего общего с производительностью или безопасностью:

Это плохая причина ремонтопригодности:
* программист на С++ ожидает, что весь код будет вести себя как С++.
* Программист C ожидает, что весь код будет вести себя как C.

Итак, когда вы смешиваете С++ и C, вы нарушаете ожидания обоих программистов о том, как все должно работать.

Ответ 8

Простой ответ здесь: профиль; определите, что лучше всего работает в вашем случае, и используйте его с умом!

Ответ 9

Является ли использование C в С++ плохим?

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

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

вы повторно вводите недостатки и опасности С++, которые были разработаны для преодоления, и это не так, как это делается в программах на С++.

Я регулярно проверяю/отклоняю/переписываю код, который вводит кодовые базы с "c с функциями С++" или "С++ с функциями c". я даже зашел так далеко, чтобы изменить malloc, free и т.д., чтобы утверждать в корневых пространствах имен (между прочим).

Сейчас я на форуме, где происходит аргумент над std::string vs. a char *. Некоторые люди говорят, что выделение простого блока памяти char * более эффективно, и до тех пор, пока вы его освободите, это прекрасно. С другой стороны, у нас есть люди, говорящие, что std::string превосходен, потому что у него нет управления памятью, но он менее эффективен.

есть больше опций для представления строки в С++, чем std::string.

на мой взгляд, он полностью действителен для создания нового класса, который представляет строку и служит определенной цели, или следует дополнительным контрактам (при необходимости). часть контрактов таких строковых представлений (конечно) состоит в том, что они управляют своими собственными ресурсами, используя new[]/delete[], когда используется динамическая память.

Если эффективность важна, а std::string меньше идеальной для конкретной задачи, то С++ достаточно мощна, чтобы выразить ваше намерение для этих конкретных случаев, создав специализированный интерфейс в С++. существует множество случаев, когда это приемлемо (imo), но не всегда стоит затрат времени. в любом случае легче управлять, чем интегрировать c-идиомы/стили/опасности в С++-программы.

Итак, главный вопрос: смешивается ли C/С++ плохо? Должен ли ваш ТОЛЬКО использовать 100% С++ при кодировании С++?

Лучше всего создавать многоразовые объектно-ориентированные решения для ваших нужд. опасности в представленном примере могут быть полностью инкапсулированы (если эта оптимизация действительно стоит времени на инвестиции) и должны быть написаны для использования идиом С++ без потери производительности и с лучшей ремонтопригодностью.

Ответ 10

В конкретном случае string по сравнению с const char * вы должны использовать bare const char * для всех переменных, которые содержат строковые константы (и только строковые константы), конвертируя в string только при передаче в API, который требует string. Выполнение этого последовательно может устранить огромное количество глобальных конструкторов, не вызывает головных болей памяти (поскольку строковые константы являются постоянными, постоянными данными), а ИМО действительно делает код более понятным - вы видите const char *, вы знаете, что это будет строковая константа.

Ответ 11

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

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

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

Ответ 12

Ну, я в странной ситуации. Я работаю над системой, которая должна быть на С++ (используется компилятор С++ и используется термин С++), но все написано на C. Это очень неприятно, потому что оно доходит до точки, где я должен "доказать" "С++ лучше использовать, чем C, даже если мы кодируем на С++. Это был ад, когда я представил std::string. Я считаю, что теперь все начинает захламлять (смешивание C и С++). Существуют редкие случаи обработки ошибок. На самом деле, я думаю, что могу считать три системных заявления о попытках. Код грязный, утечки памяти видны, и поиск ошибки - это иголка в стоге сена. Существуют сотни строк кода, которые могут быть заменены функциями С++. Я бы сказал, что писать код является более эффективным, понятным и понятным.

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