Почему я получаю синтаксическую ошибку, когда я пытаюсь запустить свою программу C++ после компиляции ее?

Я пытаюсь изучить C++, но я не могу даже сделать первое (привет мир) примером от работы cplusplus.org с g++ команда или c++. Я создал файл точно так же, как пример и работал g++ myfile, затем ./myfile.

Я получаю проблему разрешения, затем я использую chmod +x myfile и проблемы разрешения не стало, но эта проблема происходит:

gzuspower@gzuspower:~/Desktop$ ./4
./4: line 1: //myfirst: No such file or directory
./4: line 4: syntax error near unexpected token `('
./4: line 4: `int main ()'

Я назвал свой файл 4 потому что это - моя 4-я попытка. Это находится на Xubuntu 16.04. Дублирующийся ответ вопроса не работал, я попробовал.c, .cpp, как расширение файла и попробовал firstc ++ (мой первый файл попытки) вместо 4 (мой четвертый файл попытки), и ничто не работает. я собираюсь попробовать другую форму привет мирового кода.

-1
задан 14 April 2018 в 03:57

3 ответа

Вы называете компилятор неправильно. Необходимо также использовать .cc или .cpp расширение файла для файлов C++. Корректное колдовство команды компилятора там было бы, например, g++ hello-world.cpp -o hello-world.

3
ответ дан 30 October 2019 в 02:32

Что идет не так, как надо

Редко полезно работать chmod на файле Вы думаете, что Ваш компилятор произвел. Когда компилятор производит двоичный файл, который предназначается, чтобы быть выполненным - то есть, когда он произведет Вашу программу - он автоматически отметит его исполняемый файл. Если Вы можете успешно отметить файл как исполняемый файл с chmod +x- которым Вы были - затем, Ваш компилятор сможет сделать то же самое. При попытке выполнить то, что Вы думаете, программа, произведенная Вашим компилятором, и Вы получаете ошибку о полномочиях, это обычно означает, что Вы петляете.

В этом случае определенные сообщения об ошибках показывают, что Вы пытаетесь выполнить свой собственный файл исходного кода C++. Это никогда не будет работать. Необходимо петлять произведенные компилятором, который является отдельным файлом. С большинством компиляторов, включая g++, этот файл называют a.out если Вы не передали другое выходное имя файла путем передачи -o filename как параметры командной строки к компилятору. Необходимо обычно делать это.

Кроме того, если Ваш файл исходного кода C++ не называют с именем, которое заканчивается в .cpp, .cxx, .cc, или .C, затем это должно быть. Кроме того, это чувствительно к регистру. Файл назвал окончание в .c средства C исходный код, не C++, и даже когда Вы выполняете C ++-specific команда компилятора как g++, это будут рассматривать как C. Большинство компиляторов C++ - включая g++ и почти все другие, которые работают на Ubuntu - исследуют суффикс Ваших входных файлов, чтобы выяснить, как рассматривать их. Существуют способы явно сказать Ваш компилятор, в каком языке Ваш исходный код записан, но они являются громоздкими по сравнению с простым именованием Ваших файлов исходного кода стандартным способом.

Каталог изменения туда, где Вы сохранили свой файл исходного кода

Вы записали (или вставили в), некоторый код C++ в текстовом редакторе, и сохранили его в файле. Сначала удостоверьтесь, что Вы перешли к каталогу, где тот файл находится. В терминале можно использовать cd управляйте для изменения каталога. При открытии окна терминала Вы обычно находитесь в Вашем корневом каталоге. Предположим, что Ваш файл исходного кода называют hello.cpp. Затем выполняя команду как g++ -o hello hello.cpp только успешно выполнится если hello.cpp на самом деле сразу расположен в Вашем корневом каталоге. Если это находится вместо этого, например, на Вашем рабочем столе, то первый показ:

cd ~/Desktop

( ~/ часть представляет Ваш корневой каталог. Если Вы уже находитесь там в Вашем терминале, то Вы не должны включать ту часть. Но я включал его, потому что та команда получит Вас к Desktop подкаталог Вашего корневого каталога, неважно, где Вы уже.)

Как другой пример, если у Вас есть каталог на Вашем названном рабочем столе source и Вы сохранили свой файл исходного кода в том каталоге, затем Вы могли добраться там в терминале путем выполнения:

cd ~/Desktop/source

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

После того как Вы имеете cdредактор к тому, везде, где Ваш файл исходного кода расположен, проверьте на него. Например, Вы могли выполнить это для списка всех файлов в текущем месте (кроме файлов, имена которых запускаются с ., который Вы, вероятно, не хотите видеть):

ls -l

Или Вы могли передать имя файла своего файла исходного кода к ls. Например, если это называют hello.cpp, затем можно работать:

ls -l hello.cpp

Если, когда Вы делаете это, Вы видите эту ошибку, это означает, что нет никакого файла тем именем в текущем каталоге:

ls: cannot access 'hello.cpp': No such file or directory

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

Попытайтесь скомпилировать свой исходный код и видеть, существуют ли ошибки

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

Вот пример ошибки компиляции, которую Вы могли бы видеть:

hello.cpp:55:84: error: expected primary-expression before ‘<<’ token

Заметьте, что компилятор включает error: в сообщении. Ищите это. Можно получить много различных видов ошибок, в зависимости от исходного кода и как Вы используете свой компилятор. Они не будут все вполне походить на это. Но они будут обычно говорить error:.

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

Имея это в виду, можно попытаться скомпилировать программу путем выполнения команды как этот:

g++ -o hello hello.cpp

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

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

Попытайтесь запустить свою программу и видеть то, что происходит

Предположим, что Вы передали -o hello к компилятору как показано выше, и компиляция, за которой следуют. Затем Вы попытались бы запустить свою программу с командой:

./hello

Если Вы видите ошибку как это, то это означает, что Ваша программа не найдена:

bash: ./hello: No such file or directory

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

bash: ./hello: Permission denied

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

Одна из вещей, работающих ls -l (или возможно просто ls) может иногда помогать Вы обнаружить - то, если Вы ввели имя с опечаткой и случайно записали что-то другое после -o (когда Вы скомпилировали программу), чем, что Вы записали после ./ когда Вы пытались запустить программу.

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

Что Вы видели

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

./4: line 1: //myfirst: No such file or directory

Я даже не видел Ваш исходный код, но я могу сказать, что это похоже на него, содержит фрагмент его. А именно, //myfirst похож на начало одной строки, комментируют, что Вы, возможно, поместили наверху своего исходного кода. Хотя он возможный попытаться запустить программу и иметь проблемы, которые показывают сообщения, содержащие текст из Вашего файла исходного кода, это редко. То, что намного более распространено, - то, что Вы случайно попытались выполнить свой файл исходного кода вместо Вашего двоичный файл, произведенный компилятором! Таким образом, если Вы видите сообщения об ошибках, когда Вы запускаете программу C++, которые похожи, они упоминают части Вашего исходного кода, всегда проверяют на это. И когда Вы пытаетесь запустить программу C++, всегда выполнять файл, который произвел Ваш компилятор, который не является тем же как файлом исходного кода, Вы записали себя.

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

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

  • Если в Вашем компиляторе было сказано что-то, что он назвал "ошибку" затем, маловероятно, что он создал Вашу программу.
  • При попытке запустить свою программу, и Вы видите вывод, который не имеет никакого смысла вообще, особенно если тот вывод содержит сообщения, которые, кажется, упоминают части Вашего исходного кода, затем проверяют ту Вашу программу дважды, был действительно создан и что Вы выполняете его и не выполняете Ваш файл исходного кода, или некоторый другой файл или некоторую другую программу.
7
ответ дан 30 October 2019 в 02:32

Как объяснено в этом ответе Eliah Kagan, сообщения об ошибках, которые Вы видели, произошли, потому что Вы пытались выполнить свой исходный файл. Здесь я попытаюсь объяснить, почему Вы получили те конкретные сообщения.

Когда Вы даете файл, выполняют разрешение, и затем Вы пытаетесь выполнить его путем выполнения /path/to/filename (который часто является ./filename), и это - текстовый файл, это будет выполнено как сценарий. Сценарии обычно имеют строку хижины как свою первую строку, состоя из #! сопровождаемый сразу полным путем намеченного интерпретатора.

Когда Вы пытаетесь выполнить исполняемый текстовый файл от оболочки Bash, и файл не имеет строки хижины, Bash предположит, что это - сценарий оболочки и запускает новую оболочку Bash для выполнения его. (Это - все еще хорошая идея записать #!/bin/bash наверху сценария Bash, в случае, если оболочка, которая выполняет его, не является Bash.), Но если файл будет содержать что-то другое, чем код Bash, то Вы будете обычно получать многочисленные синтаксические ошибки. Это - то, что произошло с Вами, как сообщения об ошибках, которые Вы получили, указывают:

$ ./4
./4: line 1: //myfirst: No such file or directory
./4: line 4: syntax error near unexpected token `('
./4: line 4: `int main ()'

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

$ bash <<< 'echo Hello World!'
Hello World!

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

$ bash <<<'//myfirst C++ program'
bash: line 1: //myfirst: No such file or directory

Я высказал предположение о том, какую строку 1 из Вашего исходного файла сказал на основе ошибки. //, то, которое запускает однострочный комментарий в C++, не является комментарием в Bash. Если первая команда имеет a / в нем Bash берет то слово, чтобы быть путем. Если бы путь был путем исполняемого файла, то файл был бы выполнен. (Это точно, что произошло, когда Вы работали ./4: файл, путь которого был ./4 выполнялся.), Если нет такого файла, то мы получаем сообщение об ошибке, говоря так.

// твердость к корневому каталогу /, и так как это не содержало названный файл myfirst в Вашей системе Вы получили это No such file or directory. Если бы это содержало файл соответствия, у Вас, вероятно, была бы другая ошибка:

$ bash <<< '/dev'
bash: line 1: /dev: Is a directory           # matches, but it's a directory
$ bash <<< '/swapfile'
bash: line 1: /swapfile: Permission denied   # matches, but not executable

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

Вы не получили ошибок о строке 2 или 3. Это могло бы быть то, потому что они были пусты, или потому что они содержали некоторый действительный код Bash (очень вряд ли), который не произвел вывода, или у них была строка, которая началась #, который является комментарием в Bash. Например, у Вас, возможно, была строка как:

#include <iostream>

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

Затем на строке 4 Вы получили синтаксическую ошибку:

$ bash <<< 'int main()'
bash: line 1: syntax error near unexpected token `('
bash: line 1: `int main()'

( и ) метасимволы оболочки и управляют операторами. Они могут породить подоболочку, в которой могут быть выполнены команда или список команд. Общее использование этого является заменой команды, где вывод команды, выполненной в подоболочке, заменяет его во внешней оболочке. Это происходит когда $ предшествует (stuff). Вот (полезный) пример:

$ which g++
/usr/bin/g++
$ readlink -e $(which g++)
/usr/bin/x86_64-linux-gnu-g++-7

Двойные круглые скобки вызывают арифметическое расширение:

$ bash <<< 'echo $((3+4))'
7

Другое использование () должен указать, что предыдущее слово является определяемой функцией, как объяснено в ответах, чтобы Что проку от круглых скобок' ()' в определении функции оболочки? Если существует два слова прежде () в команде, если первое слово не function, ( будет синтаксическая ошибка:

$ bash <<< 'foo bar()'
bash: line 1: syntax error near unexpected token `('
bash: line 1: `foo bar()'
$ bash <<< 'function bar()'
bash: line 2: syntax error: unexpected end of file

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

Когда оболочка встретится с синтаксической ошибкой, она прекратит обрабатывать текущий вход (и если это - неинтерактивная оболочка, сразу выйдите), таким образом, Вы не будете видеть дальнейших ошибок независимо от того, что следует. Независимо от того, что Ваш исходный файл продолжил после int main(), оболочка не считала его.

Большое спасибо Eliah Kagan для поощрения меня записать этот ответ и обеспечение различного полезного понимания!

2
ответ дан 30 October 2019 в 02:32

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

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