“Портативный” C должен скомпилировать как C++?

Попробуйте удалить приложение. Затем очистите проект, запустите cd android & amp; & amp; ./gradlew clean

Затем вернитесь в корневой каталог cd ..

Затем снова выполните отладочную сборку реагировать на родную версию run-android или какую-либо другую команду в сценарии

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

19
задан Community 23 May 2017 в 11:55
поделиться

11 ответов

Нет. Мой ответ, Почему искусственно ограничивают Ваш код C? имеет некоторые примеры совместимого стандартами C99, не компилирующего как C++; ранее C имел меньше различий, но C++ имеет более сильный ввод и другое отношение (void) список аргумента функции.

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

16
ответ дан 30 November 2019 в 02:22
поделиться

Мобильность означает писать Ваш код так, чтобы это скомпилировало и имело то же поведение с помощью различных компиляторов и/или различных платформ (т.е. полагаясь на поведение, переданное под мандат стандартом (стандартами) ISO везде, где возможный).

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

С другой стороны, когда запись C кодирует, я все еще избегал бы использования "класса" как идентификатора, например.

8
ответ дан 30 November 2019 в 02:22
поделиться

Нет, "портативный" не означает "компиляции на компиляторе C++", это означает "компиляции на любом Стандартном совместимом компиляторе C" с последовательным, определенным поведением.

И не лишайте себя, скажем, улучшений C99 только для поддержания совместимости C++.

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

Будучи "хорошим стюардом" не отъезд мусора вокруг походного костра, просто хорошая карма в том, что Вы делаете.

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

3
ответ дан 30 November 2019 в 02:22
поделиться

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

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

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

2
ответ дан 30 November 2019 в 02:22
поделиться

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

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

Если необходимо сохранить код строго C, необходимо быть осторожными.

2
ответ дан 30 November 2019 в 02:22
поделиться

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

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

Текущий C++ (1998) стандарт включает C (1989) стандарт. Некоторый мелкий шрифт относительно отложенной безопасности типов, который означает "хороший" C89, должен скомпилировать прекрасный в компиляторе C++.

Проблема состоит в том, что текущий стандарт C имеет что 1 999 (C99) - который еще не является официально частью стандарта C++ (AFAIK) (*). Это означает, что многие "более хорошие" функции C99 (долгое длинное целое, stdint.h...), в то время как поддерживается многими компиляторами C++, не строго совместимы.

"Портативный" C означает что-то еще полностью и имеет мало общего с официальными стандартами ISO/ANSI. Это означает, что Ваш код не делает предположения на серверной среде. (Размер интервала, порядка байтов, нестандартных функций или errno чисел, наполняет как этот.)

От руководства стиля кодирования я однажды записал для межплатформенного проекта:

Межплатформенный DNA (не принимают),

  • Нет никаких собственных типов данных. Единственные типы данных, которые Вы могли бы использовать, являются объявленными в стандартной библиотеке.
  • символ, короткий, международный и длинный, имеет другой размер каждый, точно так же, как плавание, дважды, и долго удваивается.
  • интервал не составляет 32 бита.
  • символ ни не подписывается, ни не не подписан.
  • символ не может содержать число, только символы.
  • Кастинг короткого типа в более длинный (интервал-> долго) нарушает правила выравнивания ЦП.
  • интервал и интервал* имеют другой размер.
  • интервал* и долго* имеет другой размер (как указатели на любой другой тип данных).
  • Вы помните, что собственные типы данных даже не существуют?
  • - не приводят к тому же результату как 'z' - 'Z'.
  • 'Z' - не приводит к тому же результату как 'z' - и не равно 25.
  • Вы ничего не можете сделать с Нулевым указателем кроме теста его значение; разыменование его разрушит систему.
  • Арифметика, включающая и подписанные и неподписанные типы, не работает.
  • Правила выравнивания для типов данных изменяются случайным образом.
  • Внутреннее расположение типов данных изменяется случайным образом.
  • Определенное поведение сверх - и потери значимости изменяется случайным образом.
  • Вызов функции ABIs изменяется случайным образом.
  • Операнды оценены в произвольном порядке.
  • Только компилятор может работать вокруг этой случайности. Случайность изменится со следующим выпуском ЦП / ОС / компилятор.
  • Для указателей, == и! = только работайте на указатели на тот же самый тип данных.
  • работа только для указателей в тот же массив. Они работают только на символ, явно заявленный неподписанный.
  • Вы все еще помните, что собственные типы данных не существуют?
  • size_t (тип возвращаемого значения sizeof) не может быть брошен ни в какой другой тип данных.
  • ptrdiff_t (тип возвращаемого значения substracting один указатель от другого) не может быть брошен ни в какой другой тип данных.
  • wchar_t (тип "широкого" символа, точный характер которого определяется реализацией) не может быть брошен ни в какой другой тип данных.
  • Любой... _t тип данных не может быть брошен ни в какой другой тип данных

(*): Это было верно во время записи. Вещи изменились немного с C++ 11, но суть моего ответа сохраняется.

18
ответ дан 30 November 2019 в 02:22
поделиться

Нет, быть компилируемым C++ не является общей интерпретацией портативного устройства. Имея дело с действительно старым кодом, объявления стиля K&R являются очень портативными, но не могут быть скомпилированы под C++.

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

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

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

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

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

Возьмите экземпляр исходного кода ядра Linux, который главным образом записан в C с некоторым встроенным ассемблерным кодом, это - кошмар, компилирующий код ядра Linux с компилятором C++, из-за наименее возможной причины, настолько 'новой', используется в качестве имени переменной в коде ядра Linux, где, поскольку C++ не позволяет использование 'новых' как имя переменной. Я просто даю один пример здесь. Помните, что ядро Linux является портативным и компилирует и работает очень хорошо в Intel, PPC, sparc и т.д. архитектура. Это должно только проиллюстрировать, что мобильность действительно имеет различные значения в мире программного обеспечения. Если Вы хотите скомпилировать код C с помощью компилятора C++, Вы перемещаете свою кодовую базу от C до C++. Я рассматриваю его как два различных языка программирования по самой очевидной причине, что программистам C не нравится C++ очень. Но мне нравятся они оба, и я использую их обоих много. Ваш код C является портативным, но необходимо удостовериться, что Вы следуете за стандартными методами, чтобы иметь Ваш код C++, портативный при миграции кода C в код C++. Продолжайте читать для наблюдения от того, где Вы получили бы стандартные методы.

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

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

Используйте следующие правила при выборе мобильности:

a) Ваш код (C или C++) должен быть скомпилирован на различной архитектуре возможно с помощью собственных компиляторов C/C++? b) Сделайте исследование компиляторов C/C++ на различной архитектуре, что Вы хотите запустить свою программу и план относительно портирования кода. Инвестируйте хорошее время на этом. c) В максимально возможной степени попытайтесь обеспечить чистый слой разделения между кодом C и кодом C++. Если Ваш код C является портативным, просто необходимо записать обертки C++ вокруг того портативного кода C снова использование портативных методов кодирования C++.

Обратитесь к некоторым хорошим книгам C++ по тому, как написать портативный код C++. Я лично рекомендую язык программирования на C++ самим Bjarne Stroustrup, Эффективным рядом C++ от Scott meyers и популярных статей DDJ там в www.ddj.com.

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

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

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

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

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

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

И на самом деле , в настоящее время идет работа над gcc ( в дереве FSF!) по переносу исходных кодов gcc в допустимый синтаксис C ++ (подробности см. в gcc-in-cxx ), чтобы Для компиляции исходного кода можно использовать компилятор C ++.

По сути, это было инициировано давним хакером gcc: Яном Лэнсом Тейлором.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

t обязательно идеальный инструмент для работы.

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

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

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

t обязательно идеальный инструмент для работы.

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

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

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

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

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

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

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

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

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

или что оно действительно эффективно в первую очередь.

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

или что оно действительно эффективно в первую очередь.

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

2
ответ дан 30 November 2019 в 02:22
поделиться

Нет, дело вкуса. Ненавижу бросать пустые указатели, сбивать код с толку.

char * p = (char *)malloc(100);

vs

char * p = malloc(100);

и когда я пишу "объектно-ориентированный" модуль библиотеки Си, мне очень нравится использовать 'this' в качестве указателя на объект, а так как это ключевое слово на Си++, то он не будет компилироваться на Си++ (это намеренно, так как такие модули бессмысленны в Си++, учитывая, что они существуют как таковые в stl и библиотеках).

2
ответ дан 30 November 2019 в 02:22
поделиться
Другие вопросы по тегам:

Похожие вопросы: