Безопасно ли переименовывать argc и argv в основной функции?


многие программы используют стандартные имена для ряда аргументов и массивов строк. Прототип функции выглядит так: int main(int argc, char *argv[]);. Но могу ли я что-то сломать, если я выберу пользовательские имена для этих переменных?

например.int main(int n_of_args, char *args[]);

в контексте компилятора все в порядке. Эти переменные являются локальными для функции main, поэтому они могут иметь любые имена. И простой код строит и работает отлично. Но эти имена могут быть использованы препроцессором. Так безопасно ли переименовывать эти аргументы?

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

10 80

10 ответов:

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

имена argc и argv были фактически санкционированы стандартом C++ до C++11. В нем говорилось:

все реализации должны допускать оба из следующих определений main:

int main ()

и

int main ( int argc , char * argv [])

и продолжил обсуждать требования на argc и argv.

таким образом, технически любая программа, использующая разные имена, не соответствовала стандарту, и компилятору было разрешено отклонить оно. Разумеется, ни один компилятор не сделал этого. Смотрите эта нить на комп.станд.c++, или раздел 3.6.1 от это c++03 проект стандарта.

это было почти наверняка простой оплошностью и было изменено в C++11, который вместо этого говорит

все реализации должны позволять как

  • функция () returning int и
  • функция (int указатель на указатель на char) возврат int

тип main (8.3.5). В последней форме, для целей экспозиция, первый параметр функции называется argc и второй параметр функции называется argv,...

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

 int main(int wrzlbrnft, char* _42[]) {
 }

имена написаны на песке. Они не имеют никакого влияния на окончательно скомпилированный код.


единственное, что имеет значение, это то, что типы параметров объявления и определения фактически совпадают.

подпись main() функция по своей сути объявляется как

 int main(int, char*[]);

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

да. Это безопасно, это выглядит странно, но это ничего не сломает.

да, безопасно использовать разные имена.

лично я бы не рекомендовал его, Хотя, как традиционный argc и argv так широко известны и знакомы каждому программисту на C, который может когда-либо работать с вашим кодом. В конечном счете, использование ваших собственных, специальных, разных имен вызовет гораздо больше путаницы и / или разочарования среди ваших читателей, чем когда-либо спасет вас, потому что вам больше нравятся ваши имена.

"когда в Риме, делай, как римляне делать."

Да, вы можете переименовать их, как вы хотите. Это просто имена параметров функции, не более того.

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

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

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

слово "число" было заменено буквой "n".

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

main( int argumentCount, char * * argumentVector)

Я всегда думаю о двух вещах: называя вещи тем, что они есть и/или их подразумеваемым использованием. Называть его argumentVector для меня избыточно, так как свойство быть вектором подразумевается двойной косвенностью **. Таким образом, лучше длинная рука для того, как я буду писать код: ** аргументы.

некоторые сказали бы, что переменная с именем argumentCount объявлена как int, и счетчик не может быть отрицательным, но вы можете иметь отрицательный int {без знака лучше}.

опять же, что это такое и как он используется приходит играть в этой интерпретации. Если это граф, то я бы предположил, что он никогда не будет отрицательным. В конце концов, как вы можете иметь количество -2 яблок. Я бы сказал, Ты должен два яблока. Если это число, то я ожидаю, что если будет возможно. Вот почему дополнительное слово "of", вероятно, важно для вас. Это и, возможно, число, на которое ссылается коллекция, подразумевает конкретный элемент, а не свойство самой коллекции. Ie: argumentsNumber = 5 подразумевает конкретный аргумент, но не numberOfArguments.

main (int maxArgumentsIndex, char ** аргументы ).

Это устраняет неоднозначность. Называя его индексом, вы устраняете двусмысленность отрицательного регистра, а также описываете, что это такое, и кроме того, как его использовать. Это также подразумевает английскую формулировку, что max является абсолютным и будет странно писать код, который изменяет это значение (он должен быть const). "аргументы" здесь имеют смысл, поскольку они множественны, описывают, что это такое и как его уже следует использовать. Даже интерпретация этого способа может быть опасной, поскольку индекс равен -1 от количества/числа. 5 аргументов дает maxIndex 4!!

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

недействительным функция (const unsigned int maxArgumentsIndex, const char ** аргументы )

Не все ситуации заслуживают длинные руки дескрипторов. На самом деле, иногда короткая рука дает больше читаемости, в частности, в случае написания математических классов, таких как Vec3f, Матрица, кватернион и т. д... Я почти всегда буду пытаться соответствовать математическому языку, а не лингвистическому. поплавок x, y, z vrs. float xComponent и тому подобное.

Я понимаю, что все это стиль выбор, но осознание выбора действительно поможет в долгосрочной перспективе. Я гарантирую, что опытные программисты беспокоятся, когда массивы не пишутся во множественном числе, но опять же, main-это особая проза существования;)

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

argc --> argument count

argv --> argument vector

что также имеет смысл с точки зрения использования, так что вы можете изменить на любое имя ожидать Reserved names

в GCC выполнение программы начинается с имени функции main это не зависит от его параметров.

когда вы пишете автономную программу для микро контроллеров, вам не нужно беспокоиться о названии main вместо этого вы можете определить свой собственный name и измените сборку entry_point, чтобы указать свою функцию. Это зависит от компилятора контроллера и наличия предварительно определенного исходного кода контроллера. Я сделал это в контроллере Freescale под Code-warrior.

Мое Примечание:

лучше следовать общим стандартам / стилю кода, чтобы сделать код более видимым и читаемым

это безопасно для компилятора.

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

int main(int foo, char ** bar)
{
    int argc;
    float argv;

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

Если вам не нравятся имена переменных, почему бы не заменить их макросом #define:

#define yourCounterName argc
#define yourVectorName  argv 

вы не будете рисковать и производить "чистое решение".