Можно ли переименовать argc и argv в основную функцию?

Ответ 1

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

Из раздела 5.1.2.2.1 стандарта C:

Функция, вызванная при запуске программы, называется main. реализация не объявляет прототипа для этой функции. Он должен определяется с типом возврата int и без параметров:

int main(void) { /*  ... */ }

или с двумя параметрами (называемыми здесь argc и argv, , хотя любые имена могут использоваться, поскольку они являются локальными для функции, в которой они находятся объявлена ​​):

int main(int argc, char *argv[]) { /* ...   */ }

или эквивалент; или каким-либо другим способом, определенным реализацией

Говоря это, использование чего-либо другого, кроме argc и argv, может смутить других, читающих ваш код, который используется для обычных имен для этих параметров. Так лучше ошибаться на стороне clairity.

Ответ 2

Имена argc и argv были фактически заданы стандартом С++ до С++ 11. Он заявил:

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

int main ()

и

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

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

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

Это был почти наверняка простой надзор и был изменен на С++ 11, который вместо этого говорит

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

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

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

Ответ 3

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

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

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

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

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

 int main(int, char*[]);

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

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

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

Слово "номер" заменено буквой "n".

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

main (int argumentCount, char ** argumentVector)

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

Некоторые скажут, что переменная с именем argumentCount объявлена ​​как int, и граф не может быть отрицательным, но вы можете иметь отрицательный int {unsigned is better}.

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

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

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

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

функция void (const unsigned int maxArgumentsIndex, const char ** аргументы)

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

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

Ответ 8

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

argc --> argument count

argv --> argument vector

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

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

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

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

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

Ответ 9

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

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

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

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

Ответ 10

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

#define yourCounterName argc
#define yourVectorName  argv 

Вы не рискуете и не создадите "чистое решение".