То, каковы были бы ограничения C++, сравнило язык C? [закрытый]

Чтобы проверить, выполнил ли пользователь SSR (рендеринг на стороне сервера), другими словами, обновить страницу и набрать ее в строке URL-адреса, вы можете узнать, проверив ее в getInitialProps следующим образом:

static async getInitialProps({req}){
  if(req){
  // Called on server
  // Here you can set a variable true
  // Later on on the code if this variable is true, then trigger the animation
  } else {
    // Called on client
  }
 }

Это то, что вам нужно сделать.

116
задан 9 revs, 3 users 65%anon 26 February 2018 в 23:43
поделиться

25 ответов

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

C является полным языком программирования. C не является произвольным подмножеством C++. C не является подмножеством C++ вообще.

Это - допустимый C:

foo_t* foo = malloc ( sizeof(foo_t) );

, Чтобы заставить его скомпилировать как C++ необходимо записать:

foo_t* foo = static_cast<foo_t*>( malloc ( sizeof(foo_t) ) );

, который больше не является допустимым C. (Вы могли использовать бросок C-стиля, это, какой случай это скомпилирует в C, но избежится большинством стандартов кодирования C++, и также многими программистами C; засвидетельствуйте, "не бросают malloc" комментарии на всем протяжении Переполнения стека).

<час>

Они не тот же язык, и если у Вас есть существующий проект в C, Вы не хотите переписывать его на другом языке только для пользований библиотекой. Вы предпочли бы пользоваться библиотеками, к которым можно взаимодействовать через интерфейс на языке, в котором Вы работаете. (В некоторых случаях это возможно с некоторыми extern "C" функции обертки, в зависимости от того, как обрабатывают библиотеку C++ по шаблону/встраивают.)

Взятие первого файла C в проекте я продолжаю работать, это - то, что происходит, если Вы просто подкачиваете gcc std=c99 для g++:

sandiego:$ g++ -g  -O1 -pedantic -mfpmath=sse -DUSE_SSE2 -DUSE_XMM3  -I src/core -L /usr/lib -DARCH=elf64 -D_BSD_SOURCE -DPOSIX -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112L -Wall -Wextra -Wwrite-strings -Wredundant-decls -Werror -Isrc  src/core/kin_object.c -c -o obj/kin_object.o | wc -l
In file included from src/core/kin_object.c:22:
src/core/kin_object.h:791:28: error: anonymous variadic macros were introduced in C99
In file included from src/core/kin_object.c:26:
src/core/kin_log.h:42:42: error: anonymous variadic macros were introduced in C99
src/core/kin_log.h:94:29: error: anonymous variadic macros were introduced in C99
...
cc1plus: warnings being treated as errors
src/core/kin_object.c:101: error: ISO C++ does not support the ‘z’ printf length modifier
..
src/core/kin_object.c:160: error: invalid conversion from ‘void*’ to ‘kin_object_t*’
..
src/core/kin_object.c:227: error: unused parameter ‘restrict’
..
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier

В общих 69 строках ошибок, четыре из которых являются недопустимыми преобразованиями, но главным образом для функций, которые существуют в C99, но не в C++.

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

, Таким образом, это просто неправильный, чтобы предположить, что

компилятор C является почти наверняка действительно компилятором C++, таким образом, нет никаких последствий стоимости программного обеспечения

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

Настолько предлагающий 'используют станд. C++:: класс очереди как ответ на вопрос, ища реализацию библиотеки очереди в C более ненормален, чем предложение 'цель использования C' и 'называет Java java.util. Класс очереди с помощью JNI' или 'называет библиотеку CPython' - Objective C на самом деле является надлежащим надмножеством C (включая C99), и библиотеки Java и CPython, оба являются вызываемыми непосредственно от C, не имея необходимость портировать несвязанный код на язык C++.

, Конечно, Вы могли предоставить C faГ§ade к библиотеке C++, но как только Вы делаете, тот C++ не отличается от Java или Python.

136
ответ дан 5 revs, 2 users 96% 24 November 2019 в 02:10
поделиться

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

1
ответ дан Rob deFriesse 24 November 2019 в 02:10
поделиться

Я думаю, что C является более портативным. Я сделал некоторую работу, приблизительно 5 лет назад портирующую код на многие ароматы Unix (AIX, Irix, HPUX, Linux). Код C был легок к порту, но у нас были различные проблемы при портировании части кода C++ через. Возможно, это были просто незрелые среды разработки, но я буду очень скорее использовать C по C++ поэтому...

3
ответ дан Gordon Thompson 24 November 2019 в 02:10
поделиться

Я использую C++ с C, программирующим по двум причинам:

  • vector и string, чтобы заставить управление матрицей элементов памяти далеко от меня
  • строгая проверка типа и броски предупреждать и/или ловить allthe неприятности я отсутствовал бы иначе.

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

3
ответ дан dubnde 24 November 2019 в 02:10
поделиться

Если Вы работаете в среде с двумя языками, Вы могли бы использовать C для некоторой производительности критические функции низкого уровня и более функциональный / высокоуровневый язык как C#/Java для бизнес-логики. Если код C++ является usedfor эти функции, C-обертки требуются для кода JNI / неуправляемого кода вокруг, и это делает вещи более сложными, чем единственное использование C.

3
ответ дан weismat 24 November 2019 в 02:10
поделиться

Я могу думать о нескольких причинах.

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

корреспондент или люди, с которыми он работает, могут быть знакомы с C, но не C++.

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

у корреспондента может быть устаревшее представление кривой обучения C++. (При корректном приближении это легче, чем C. Большинство вводных книг, которые я видел, не обращается к нему правильно.)

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

4
ответ дан David Thornley 24 November 2019 в 02:10
поделиться

Можно считать интересную напыщенную речь о том, почему Linus Torvalds одобряет C здесь

6
ответ дан Paul Dixon 24 November 2019 в 02:10
поделиться

Собственный код на Mac объективен-c. Собственный код на ПК является c (window.h) или C++ (mfc). Обе из этих сред позволят Вам использовать c с минимальными изменениями. То, когда я хочу, чтобы библиотека кода была кросс-платформенным ansi c, походит на хороший выбор.

5
ответ дан Nick Van Brunt 24 November 2019 в 02:10
поделиться

Разработка ядра Windows не поддерживает C++ (печально).

7
ответ дан LegendLength 24 November 2019 в 02:10
поделиться

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

, Если я добираюсь для выбора, я запишу весь материал высокого уровня как интерфейс и взаимодействие базы данных в Python (или возможно C#) и весь материал, который должен быть быстрым в C. Мне, который дает мне лучший из всех миров. Запись всего в C++ испытывает желание получать худший из всех миров.

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

115
ответ дан dagw 24 November 2019 в 02:10
поделиться

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

58
ответ дан Joonas Pulakka 24 November 2019 в 02:10
поделиться

Я очень не хочу программировать в C++.

49
ответ дан Georg Schölly 24 November 2019 в 02:10
поделиться

Несколько причин могли бы быть:

  • Отсутствие поддержки - Не каждый компилятор C является также компилятором C++. Не все компиляторы особенно совместимы со стандартом, даже если они утверждают, что поддерживали C++. И некоторые компиляторы C++ генерируют безнадежно чрезмерно увеличенный в размере и неэффективный код. Некоторые компиляторы имеют ужасные реализации стандартной библиотеки. Разработка привилегированного режима обычно использует невозможную библиотеку стандарта C++, а также некоторые функции языка. Можно все еще написать код C++, если Вы придерживаетесь ядра языка, но тогда может быть более просто переключиться на C.
  • Знакомство. C++ является сложным языком. Легче преподавать кому-то C, чем C++, и легче найти хорошего программиста C, чем хороший программист на C++. (ключевое слово здесь "хорошо". Существует много программистов на C++, но большинство из них не выучило язык правильно)
  • Кривая обучения - Как выше, преподавая кому-то, кого C++ является огромной задачей. Если Вы пишете приложение, которое должно сохраняться другими в будущем, и эти другие не могут быть программистами на C++, пишущий, что оно в C делает намного легче справиться с.

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

38
ответ дан jalf 24 November 2019 в 02:10
поделиться

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

Просто недавно запрограммировав в C++ больше 15 лет я открывал вновь свои корни C. Я должен сказать, что, в то время как существуют хорошие функции в C++, который делает жизнь легче, существует также загрузка ловушек и своего рода "there-is-always-a-better-way" выполнения вещей. Вы никогда на самом деле становитесь довольно довольными решением, которое Вы сделали. (Не понимайте меня превратно, это могло быть хорошей вещью, но главным образом не).

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

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

30
ответ дан Anders Hansson 24 November 2019 в 02:10
поделиться

Во встроенной среде низкого уровня некоторые "разработчики программного обеспечения" будут иметь фон EE и едва освоили C. C++ более сложен, и некоторые из этих парней просто боятся выучить новый язык. Таким образом C используется в качестве наименьшего общего знаменателя. (Прежде чем Вы предложите избавиться от этих парней, они, по крайней мере, так же важны как крупные фирмы CS, которые не понимают жесткий аналоговый материал.)

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

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

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

20
ответ дан bstpierre 24 November 2019 в 02:10
поделиться

Почему предел, говорящий на английском языке? Возможно, Вы были бы более творческим автором на сербском языке.

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

13
ответ дан SPWorley 24 November 2019 в 02:10
поделиться

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

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

10
ответ дан quinmars 24 November 2019 в 02:10
поделиться

Я хотел бы следовать ответу Dan Olson. Я полагаю, что люди боятся потенциально опасных и контрпродуктивных функций C++, и оправданно так. Но в отличие от того, что говорит Dan, я не думаю, что просто выбор стандарта кодирования является эффективным по двум причинам:

  1. стандарты Кодирования может быть трудно строго осуществить
  2. , может быть очень трудно придумать хорошее.

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

  1. Вам разрешают использовать stl контейнеры, но не использовать шаблоны в любом Вашем собственном коде.
  2. Люди начинают жаловаться, что они были бы более продуктивными, если бы им просто позволили кодировать это или что шаблонный класс.
  3. стандарт Кодирования пересмотрен для разрешения этого.
  4. Слайд наклон к чрезмерно сложному стандарту кодирования, за которым никто не следует и использование точно вида опасного кода, который стандарт, как предполагалось, предотвратил, объединен с избыточной бюрократией, окружающей стандарт.

(Альтернатива, что стандарт не пересмотрен на шаге 3, является опытным путем слишком невероятной для рассмотрения и не была бы этим намного лучше так или иначе.)

, Хотя я раньше использовал C++ для примерно всего несколько лет назад, я начинаю сильно чувствовать, что C предпочтителен в задачах низкого уровня, с которыми нужно справиться или C или C++, и все остальное должно быть сделано на некотором другом языке полностью. (Только возможные исключения, являющиеся некоторыми определенными высокоэффективными проблемными областями, wrt. Блиц ++ )

10
ответ дан TrayMan 24 November 2019 в 02:10
поделиться

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

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

9
ответ дан Dan Olson 24 November 2019 в 02:10
поделиться

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

  • Классы и функции членства имеют нуль наверху по сравнению с нормальными функциями (если Вы не используете виртуальные функции, в этом случае нет никаких издержек по сравнению с использованием указателей функций)
  • , Шаблоны имеют очень мало служебное (чаще всего никакие издержки вообще)

, Одна допустимая причина состояла бы в том, когда Вы программируете для платформы, которая не имеет достойного компилятора C++ (никакой компилятор C++ вообще, или компилятор существует, но плохо реализован и налагает ненужные высокие издержки для некоторых функций C++).

19
ответ дан Suma 24 November 2019 в 02:10
поделиться

Я использую C или, по крайней мере, экспортирую интерфейс C., когда пишу код библиотеки.

Я не хочу плохо определенных проблем с ABI.

10
ответ дан 24 November 2019 в 02:10
поделиться

Я могу придумать три причины. Во-первых, C больше подходит для встроенных систем из-за небольшого размера его двоичных файлов и более широкой доступности компиляторов C в любой системе. Второй - переносимость: C - это меньший по размеру язык, и код ANSI C компилируется где угодно. На C ++ легче нарушить переносимость. Последнее - это сам язык. C ++ сложнее и определенно является очень плохо разработанным языком. Грипсы Торвальдса описаны выше. Вы также можете посмотреть ответы на часто задаваемые вопросы C ++ ( http://yosefk.com/c++fqa/ ).

1
ответ дан 24 November 2019 в 02:10
поделиться

Добавить к ответу Максима Кима

В нормальном методе ..

q: - > окно командной строки для команд

q/ - > окно командной строки для поиска вперед

q? - > окно командной строки для поиска назад

Ctrl-C или < CR > выведет вас из окна командной строки

-121--940624-

Использование awk гораздо проще...:

cat test.txt | awk '{ print $3 " " $4 " " "("$1")" }'

Вывод:

Doe, John (jdoe)
Doe, Jane (jad)
Smith, Jon (smith)

См. человек awk 1

-121--3049957-

Портативность может быть проблемой. В отличие от ответа Гордона Карпентера-Томпа, я бы предположил, что это скорее поддержка во время выполнения различных версий libstdc++ в разных версиях linux/unix. Для получения дополнительной информации см. по этой ссылке . Небольшой отрывок:

Код поддержки среды выполнения, используемый различными частями приложения C++, должен быть совместимым. Если одна часть программы нуждается в dynamic_cast или захвате объектов, предоставленных другой, обе части должны согласовать определенные детали реализации: как найти vtables, как размотать стек и так далее.

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

1
ответ дан 24 November 2019 в 02:10
поделиться

Один момент, который я еще не видел поднятым, который я считаю наиболее важным:

Большинство библиотек, которые я использую ежедневно, это библиотеки на Си с переплетами для Python, Ruby, Perl, Java и др. Из того, что я видел, намного проще обернуть Си библиотеки с 19 различными языковыми привязками, чем обернуть Си++ библиотеки.

Например, однажды я выучил Каир , и с тех пор использовал его в 3 или 4 различных языках. Большая победа! Лучше я напишу программу, которая в будущем может быть использована снова, а написание программы, которая легко может быть перенята на другие языки программирования, является крайним случаем.

Я знаю, что привязать библиотеки С++ можно, но AFAICT это не одно и то же. Я использовал Qt (v3 и v4) на других языках и это не так приятно использовать: они чувствуют себя как будто пишут C++ на каком-то другом языке, а не как родные библиотеки. (Вы должны передать метод Си++ sigs в виде строк!)

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

9
ответ дан 24 November 2019 в 02:10
поделиться

C имеет главное преимущество, которое вы можете просто увидеть, что на самом деле происходит, когда вы смотрите на какой-то кусок кода (да препроцессор: компилируйте с -Е, а затем вы видите его). Что-то, что слишком часто не правда, когда вы смотрите на какой-то код C ++. Там у вас есть конструкторы и деструкторы, которые подразумеваются неявно на основании объема или из-за назначений, у вас есть перегрузка оператора, которая может оказаться удивительным поведением, даже если он не плохо рассмотрен. Я признаю, что я контрольный урод, но я пришел к выводу, что это не такая плохая привычка для разработчика программного обеспечения, который хочет написать надежное программное обеспечение. Я просто хочу иметь справедливый шанс сказать, что мое программное обеспечение имеет именно то, что он должен делать, и не испытывать плохого ощущения в своем животе одновременно, потому что я знаю, что все еще может быть так много ошибок, что я бы мог T даже уведомление, когда я посмотрел на код, который заставляет их.

C ++ также есть шаблоны. Я ненавижу и люблю их, но если кто-нибудь говорит, что он или она полностью понимает их, я называю его лжецом! Это включает в себя писатели компилятора, а также люди, участвующие в определении стандарта (что становится очевидным, когда вы пытаетесь его прочитать). Есть так много абсурдно вводящих в заблуждение угловых случаев, которые просто невозможно считать их всеми, пока вы пишете настоящий код. Я люблю шаблоны C ++ для их чистой силы. Это действительно удивительно, что вы можете сделать с ними, но они также могут привести к странному и сложному находить ошибки можно (не) представить. И эти ошибки на самом деле происходят и даже не редко. Чтение о правилах, связанных с разрешением шаблонов в руке C ++, почти заставляет голову взорваться. И это дает мне плохое ощущение потраченного времени, необходимое для чтения сообщений об ошибках компилятора, которые находятся в нескольких 1000 символов, для которых мне уже нужно 10 минут или больше, чтобы понять, что компилятор на самом деле хочет от меня. В типичном C ++ (библиотечный) код также часто нахожу много кода в заголовочных файлах, чтобы сделать определенные шаблоны возможными возможными, которые, в свою очередь, делает Compill / Execute Cycles больно медленным даже на быстрых машинах и требует перекомпиляции больших частей кода при изменении чего-либо там.

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

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

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

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

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

Жизнь коротка ...

27
ответ дан 24 November 2019 в 02:10
поделиться