Использование 'const' для параметров функции

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

Я согласен. :-) (С вопросом, а не последним комментарием!) Если значение не должно изменяться в теле функции, это может помочь остановить глупые ошибки == или =, вы никогда не должны помещать const в оба, (если он передается по значению, иначе вы должны) Это недостаточно серьезно, чтобы спорить об этом!

@selwyn: Даже если вы передадите в функцию const int, она будет скопирована (поскольку это не ссылка), поэтому константа не имеет значения.

Те же дебаты происходят и в этом вопросе: stackoverflow.com/questions/1554750/…

Я понимаю, что этому посту уже несколько лет, но, как новый программист, я задавался этим вопросом и наткнулся на этот разговор. На мой взгляд, если функция не должна изменять значение, будь то ссылка или копия значения / объекта, она должна быть константой. Это безопаснее, самодокументируется и удобнее для отладки. Даже для самой простой функции, в которой есть один оператор, я все равно использую const.

Теперь с семантикой перемещения, имеющей const, может снизиться производительность

Я не могу согласиться с частью «плохого стиля». Удаление const из прототипов функций имеет то преимущество, что вам не нужно изменять файл заголовка, если вы решите удалить const из части реализации позже.

«Лично я не использую const, за исключением параметров ссылки и указателя». Может быть, вам следует пояснить, что «Я стараюсь не использовать лишние квалификаторы в объявлениях функций, а использую const там, где это имеет полезное значение».

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

int getDouble(int a){ ++a; return 2*a; } Попробуйте это. Конечно, ++a здесь не при чем, но может можно найти там в длинной функции, написанной более чем одним программистом в течение длительного периода времени. Я настоятельно рекомендую написать int getDouble( const int a ){ //... }, который будет генерировать ошибку компиляции при обнаружении ++a;.

Все зависит от того, кому какая информация нужна. Вы предоставляете параметр по стоимости, чтобы вызывающий не нужно ничего знать определял, что вы делаете (внутренне) с ним. Так что напишите class Foo { int multiply(int a, int b) const; } в шапке. В вашей реализации ты заботишься вы можете пообещать не изменять a и b, поэтому int Foo::multiply(const int a, const int b) const { } имеет здесь смысл. (Примечание: и вызывающая, и реализация заботятся о том, чтобы функция не изменяла свой объект Foo, следовательно, константу в конце своего объявления)

Я также не думаю, что этот «ответ» справедлив, если я считаю, что это плохой стиль, что это не имеет особого значения. В вызове суждения есть некоторая практическая истина, но все аргументы для const в общем случае переменной применимы, и это проблема / недосмотр языка, которая не рассматривается по-разному для объявления. Я бы сказал, что меня не устраивают объяснения «плохой стороны», которые я вижу в других местах (которые имеют другие побочные эффекты). Для stackoverflow было плохо выбрать это в качестве ответа, не потому, что он не может быть частью более крупного ответа, а потому, что он неполон для сложной проблемы C++.

@ MichałGórny просто представьте первую строку вашей функции как void func (unsigned char const * const buffer, size_t const length); это выглядит неуклюже. Но вместо этого, если мы напишем как void func (unsigned char const * buffer, size_t length); , это выглядит намного лучше

Стоит отметить, что Страуструп (по крайней мере, в TC++ PL 4-е изд.) использует const только для параметров указателя и ссылки. Его главный комментарий по поводу передачи по значению const заключается в том, что нет опасности изменения вызывающего контекста вне зависимости от того, используется const или нет (см. Стр. 308). Одним из аргументов против const по значению является то, что беспокойство о нем требует определенного количества времени и энергии, которые лучше потратить в более значимых местах - ваши функции должны быть краткими и достаточно ясными, чтобы вы могли легко отслеживать, что происходит с параметры в любом случае.

иногда вы хотите передать объект по ссылке (по соображениям производительности), но не изменять его, поэтому const является обязательным. Сохранение всех таких параметров - даже bools - const было бы хорошей практикой, что упростило бы чтение вашего кода.

Я вообще этого не понимаю. Почему Не могли бы вы опустить его в файле cpp (определение функции)? Вот где это на самом деле что-то значит и может обнаруживать ошибки. Почему как вы думаете, лучше всего использовать const в обоих местах? В заголовочном файле (объявлении функции) это ничего не значит и загромождает API. Может быть, есть небольшая ценность в том, чтобы объявления decl и defn выглядели одинаково, но мне кажется, что это действительно незначительное преимущество по сравнению с проблемой загромождения API.

@DonHatch 8 лет спустя, вау. В любом случае, как сказал OP: «Я также был удивлен, узнав, что вы можете опустить const из параметров в объявлении функции, но можете включить его в определение функции».

По многим причинам. Создание параметра по значению const четко указывает: «Мне не нужно изменять это, поэтому я заявляю об этом. Если я попытаюсь изменить его позже, выдаст мне ошибку времени компиляции, чтобы я мог исправить свою ошибку или снять отметку const ». Так что это вопрос как гигиены кода, так и безопасности. Несмотря на все, что требуется для добавления в файлы реализации, люди должны делать это как чистый рефлекс, ИМО.

Хотя в некоторых случаях это может помочь, я подозреваю, что возможность содействия оптимизации сильно преувеличена как преимущество const. Скорее, это вопрос формулировки намерения в реализации и улавливания мыслей позже (случайное увеличение неправильной локальной переменной, потому что это был не const). Параллельно я бы также добавил, что компиляторы очень приветствуются для изменения сигнатуры функций в том смысле, что функции могут быть встроены, а после встраивания можно изменить весь способ их работы; добавление или удаление ссылок, создание литералов «переменных» и т. д. все в рамках правила «как если бы»

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

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

Полностью согласен. Все дело в общении с людьми и ограничении того, что можно сделать с переменной, тем, что должно быть сделано.

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

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

@tonylo: вы неправильно поняли. Речь идет о том, чтобы пометить локальную переменную как константу внутри блока кода (который является функцией). Я бы сделал то же самое для любой локальной переменной. Он ортогонален константно-корректному API, что действительно также важно.

Не совсем, я думаю, вы просто переоцениваете полезность const. Я думаю, [полезность] появляется тогда, когда важно определить право собственности на объект. Взгляните на API POSIX, откройте (2), например, путь (указатель) стоит сделать константой, для флагов и режимов это не имеет значения.

И он может отлавливать ошибки внутри функции - если вы знаете, что параметр не должен изменяться, то объявление его как const означает, что компилятор сообщит вам, если вы случайно измените его.

@tonylo, я к этому вопросу отношусь нейтрально. Если люди вводят в параметры const, хорошо. Но я не делаю этого в своем коде. Но упоминание руководств open и т. д. На самом деле не является аргументом. Потому что const не будет частью интерфейса. Так что показывать const на страницах руководства было бы неправильно.

@Partial, я согласен с вами в том, что никогда не ошибаюсь писать это. Но также не плохо не всегда его везде наклеивать. Бывают случаи, когда я считаю, что выгода не оправдывает ее. Это личное мнение: вы никогда не увидите, чтобы я голосовал против любого такого ответа только из-за моего личного мнения, и вы никогда не прочитаете, что я пишу, что помещать const где-либо неправильно.

Но это ограничивает ваш выбор алгоритмов (или заставляет вас делать ненужные копии) - если я назову ваш sin (x), мне все равно, должен ли ваш алгоритм sin () изменить свою копию X, пока он оценивает ответ.

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

«Reductio ad absurdum» - ответ призывает использовать «const» всякий раз, когда это возможно. Это просто приводит к загромождению API, которые труднее читать, и ограничивает алгоритмы. void bytecopy(char * CONST dest, const char * CONST source, CONST int count) { while(count--) { *dest++=*source++; } } не будет работать, и три из четырех констант (заглавные) не нужны.

«Вы всегда должны предполагать, что ваши коллеги - психопаты, пытающиеся достать вас любым возможным способом», - заставили меня громко смеяться на работе. +1 за это.

Если ваши коллеги - психопаты, ожидайте, что они напишут struct Foo { void bar(const string); }; void Foo::bar(string s) { s = "I modified a string which was supposed to be const"; } «Так много для самодокументирования».

-1 за то, что сказал Окталист, есть психопаты, а есть постоянные психопаты. Часто это один и тот же шизофреник. Если вы когда-либо отбрасываете const только один раз в любом месте кода, корректного для констант, все предположения о самодокументирующемся коде разваливаются, поскольку вы больше не можете доверять API.

Для меня есть еще одна причина написать здесь const. Я делаю это по веским причинам. Я привык делать параметры по умолчанию константными, так зачем останавливаться на типах POD? (только мое личное мнение)

Я думаю, что использование const с параметрами, не являющимися ссылками / указателями, совпадает с окружающим оператором return с круглыми скобками.

Искренне согласен! Настоящий разработчик API использует const.

Чего не хватает в этом обсуждении, так это различия между контрактом интерфейса и реализацией. Добавление константы к параметру по значению в объявлении метода не меняет семантику интерфейса и, следовательно, не может ничего сигнализировать клиенту - константа не является частью контракта. Было бы полезно включить его в определение, сигнализируя будущим разработчикам, что он не предназначен для изменения в реализации. Можно использовать const в объявлении без const в определении. по значению const в интерфейсе лишний беспорядок.

Позвольте мне не согласиться с вашим ответом здесь @rlerallut (хотя ему сейчас 10 лет). Константа в заголовке для аргументов по значению не дает значения или даже отрицательного значения. С одной стороны, это не выполняется компилятором, поэтому разработчику ничто не мешает удалить «const» в реализации (а затем забыть обновить заголовок). С другой стороны, пользователю заголовка не выгодно знать, что функция (предположительно - см. Ранее) использует значение константным способом. В лучшем случае это шум в заголовке, в худшем - обещания, которые исполнитель может легко нарушить.

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

«Я бы хотел, чтобы переменные по умолчанию были константными» - оксюморон ?? 8-) Серьезно, как «конструирование» всего помогает распутать код? Если исходный автор изменил предположительно постоянный аргумент, как узнать, что переменная должна быть константой? Более того, подавляющее большинство (не аргументов) переменных предназначены быть ... переменными. Итак, компилятор должен сломаться очень скоро после того, как вы начали процесс, не так ли?

@ysap, 1. Максимальное обозначение const позволяет мне видеть, какие части движутся, а какие нет. По моему опыту, многие местные жители де-факто постоянны, а не наоборот. 2. «Постоянная переменная» / «Неизменяемая переменная» может звучать как оксюморон, но это стандартная практика в функциональных языках, а также в некоторых нефункциональных языках; см. Rust, например: doc.rust-lang.org/book/variable-bindings.html

Также теперь стандартен в некоторых случаях в C++; например, лямбда [x](){return ++x;} - это ошибка; см. здесь

Переменные по умолчанию "const" в Ржавчина :)

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

@phoenix Для будущего читателя: Почему неизменяемость обязательна в Rust, если иное не указано в mut?

С каким компилятором это работало? GCC выдает ошибку при попытке скомпилировать foo() = 42: error: lvalue требуется как левый операнд присваивания

Это просто неверно. foo () = 42 то же самое, что 2 = 3, т.е. ошибка компилятора. А возвращать константу совершенно бессмысленно. Он ничего не делает для встроенного типа.

Я столкнулся с таким использованием const и могу вам сказать, что в конечном итоге это приносит больше хлопот, чем пользы. Подсказка: const int foo() относится к другому типу, чем int foo(), что создает большие проблемы, если вы используете такие вещи, как указатели на функции, системы сигналов / слотов или boost :: bind.

Я исправил код, чтобы включить возвращаемое значение ссылки.

Разве const int& foo() не то же самое, что int foo(), из-за оптимизации возвращаемого значения?

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

Интересно, я никогда об этом не думал.

Точно так же unsigned должен был быть по умолчанию в C++. Как это: int i = 5; // i is unsigned и signed int i = 5; // i is signed.

другой способ - использовать if (0 == number) ... else ...;

@ ChrisHuang-Leaver Ужасно, это не так, если вы говорите, как Йода, вы делаете: stackoverflow.com/a/2430307/210916

GCC / Clang -Wall дает вам -Wparentheses, который требует, чтобы вы сделали это «if ((number = 0))», если это действительно то, что вы намеревались сделать. Что хорошо работает как замена Йоде.

Херб Саттер - действительно умный парень :-) Определенно стоит прочитать, и я согласен со ВСЕМИ его пунктами.

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

Почему отрицательные голоса? Будет гораздо полезнее, если вы оставите краткий комментарий к голосованию против.

Весь смысл использования аргумента const заключается в том, чтобы пометить строку не удалось (plist = pnext). Сохранение неизменности аргумента функции - разумная мера безопасности. Я согласен с вашей точкой зрения, что они плохи в объявлениях функций (поскольку они избыточны), но они могут служить своим целям в блоке реализации.

Нет причин загромождать ваш API, чтобы раскрыть детали внутренней реализации. Достаточно просто, чтобы ваша реализация принимала параметры T parm_foo и сразу же назначала const &T foo=parm_foo, а затем использовала foo в функции - вы можете обеспечить постоянство параметров без ненужного беспорядка API для конечных пользователей.

@Adisak Я не вижу ничего плохого в вашем ответе как таковом, но из ваших комментариев кажется, что вы упускаете важный момент. Определение / реализация функции - это часть API нет, которая представляет собой только функцию декларация. Как вы уже сказали, объявление функций с параметрами const бессмысленно и добавляет беспорядка. Однако пользователям API может никогда не понадобиться его реализация. Тем временем разработчик может решить ограничить константой некоторые параметры в определении функции ТОЛЬКО для ясности, что совершенно нормально.

@ jw013 Язык не допускает реализации / определения функций, которые отличаются от деклараций. Следовательно, они ИМЕЮТ должны быть одинаковыми. «Хороший» API должен открывать только то, что фактически составляет действительный «контракт» с пользователем, и не должен быть завален лишней чепухой, не влияющей на пользователя API. Я считаю, что хороший / чистый API лучше некоторых глупых поддельных ограничений реализации, которые легко обойти.

@Adisak Я не так хорошо знаком с педантичными деталями C++, как с C, но C99 определенно позволяет это (имея const в определении, но не в объявлении прототипа). Я никогда не соглашался с вами в том, что ясность API имеет первостепенное значение и не должна загромождаться деталями реализации.

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

@ jw013 правильный, void foo(int) и void foo(const int) - это одна и та же функция, а не перегрузки. ideone.com/npN4W4 ideone.com/tZav9R Здесь константа - это только деталь реализации тела функции и не влияет на разрешение перегрузки. Оставьте const в объявлении для более безопасного и аккуратного API, но поместите const в определение, если вы не собираетесь изменять скопированное значение.

Интересный @Oktalist. Однако я не уверен, что мне очень нравится идея о том, что определение не соответствует объявлению, даже если это разрешено компилятором.

@Oktalist @ jw013 Хорошо, значит, вы можете не совпадать с const в объявлении и определении. Это делает излишнюю const только ужасной вещью и ужасной ложью, потому что вы можете игнорировать ее в своем определении - см. Этот пример: class foo { void test(int * const pi); }; void foo::test(int *pi) { pi++; }

@Adisak Я знаю, что это старый, но я считаю, что правильное использование общедоступного API было бы наоборот. Таким образом, разработчики, работающие над внутренними компонентами, не допускают ошибок, таких как pi++, когда они не должны этого делать.

@CoffeeandCode Я вижу случайное использование const в реализации функции, если вы решите ограничить себя от изменения переменной по значению в реализации, но никогда нет причин иметь ложную и ненужную константу в заголовке / общедоступном API определение. Это ложь, потому что реализация может это игнорировать.

Не поймите меня неправильно, правильность констант - замечательная вещь, которую я ценю и рекомендую всем хорошим программистам, но важным является слово «правильность». Существует разница между «правильной» константой (которая фактически относится к принудительному контракту API) и «плохой» константой (той, которая не добавляет значения контракту API и не имеет значения для вызывающего кода, присутствует ли он вообще).

«Слишком много 'const' в API, когда оно не нужно, похоже на« плачущий волк », в конечном итоге люди начнут игнорировать 'const', потому что он повсюду и большую часть времени ничего не значит« Что? Суть константы в том, что ее нельзя игнорировать, потому что компилятор не позволит вам ее игнорировать.

@Taywee - компилятор позволяет вам игнорировать лишнюю константу в объявлении, потому что ваша реализация / определение функции может не включать константу (и я специально показываю случаи, когда компилятор проигнорирует это). Есть разница между необходимыми константами и лишними, и я указываю на них в своем ответе.

Это, безусловно, помогает выявлять тонкие ошибки, к которым склонны допускать люди, особенно когда использование констант согласовано в кодовой базе. один например. будет функцией std::stringc_str(), которая возвращает const char * для базовой строки. Кто-то ошибочно изменял передаваемую строку, когда это не предназначалось. Нас спасли компиляторы.

Добавление const к параметру передачи по значению загрязняет API реализацией. Он ничего не сообщает вызывающему и (как говорит @Adisak) загромождает API, затрудняя выбор важных частей. Мы никогда не разрешаем изменять параметры функции передачи по значению в теле, и это одна из ключевых проверок при проверке кода (вы делаете проверки кода?). Если вы хотите изменить значение, сделайте копию (и вы можете дать ей имя, которое документирует ваше использование).

@AbhinavGauniyal, используя "const char *" для строки, символы которой не должны изменяться, - это разумно. Это необходимо const. Однако примером ненужной константы в API может быть использование «const char * const» для той же строки или, что еще хуже, использование «char * const» для строки, символы которой функция изменила.

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

Голосование вниз, потому что большая часть этого ответа кажется разглагольствованием о чем-то, в чем вы ошиблись (параметры const в функции определение не влияют на API). На полпути вы признаете это, но было бы полезно, если бы вы отредактировали и либо удалили исходную неправильную часть, либо добавили в начале большой отказ от ответственности, говоря, что первая часть неверна.

Этот ответ бесполезен. По сути, это длинная и многословная тирада о том, что никто не делает и не предлагает делать. Это классический аргумент соломенного человека.

@melpomene Может быть, напыщенная речь, но не соломка - в вопросе была предложена концепция посторонних констант, и это напрямую касается этого вопроса. Поэтому ваше заявление о том, что никто не предлагает этого сделать, просто ложно. А анекдотическое предположение, что никто этого не делает (потому что я видел это в природе), логически является аргументом от незнания.

@Adisak Вопрос был про const по параметрам в определении функции. Первые три четверти вашего ответа посвящены const в API, то есть объявлениям функций. Есть небольшое отступление об исключении const из объявления, но затем оно уходит по касательной и говорит об исключении const только из определения (WTF?). Последний квартал посвящен тому, как создание переменной const означает, что вы не можете ее изменить, и если вам нужно, вы должны либо удалить const, либо сделать изменяемую копию. Классная история, но опять же не имеющая отношения к API или их разработчикам.

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

@Adisak Никто не предлагал использовать const в API. Ваш «более широкий ответ» просто не отвечает на вопрос.

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

@Adisak В четвертый раз ваш ответ не затрагивает «тему»; он полностью пропускает тему. Мне не нравится, как вы пытаетесь искажать мои слова. (Он «охватывает» совершенно другую тему, но не очень хорошо и глубоко; это много повторений и эмоционально заряженных слов (беспорядок, фильм плохой парень, глупый, ложь, ужасная вещь, ужасная ложь, бельмо на глазу, ...), но очень поверхностный техническое содержание.)

@melpomene Вы читали тот же текст, что и я? Кажется, вы ограничиваете следующий текст API только там, где, кажется, задается что-то более широкое: Как далеко вы зашли с const? Вы просто делаете функции константными, когда это необходимо, или вы делаете все возможное и используете его везде? Лично я предпочитаю широко использовать его, включая параметры, но в этом случае мне интересно, стоит ли оно того? - и мой ответ - используйте const столько, сколько вам нужно, но не тогда, когда это не нужно или вводит в заблуждение

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

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

Решение "лишних констант" #define CDa const* #define CP *const #define CPD const * const * указатель на CONSTANT DATA * CONSTANT POINTER на данные * CONSTANT указатель на CONSTANT данные *** void mungerum(char CP buffer, char CPD mask, CN int count); vs void mungerum(char * const buffer, const char * const mask, const int count); Также устраняет путаницу с использованием const перед типом и после типа и обеспечивает меньшую многословность.

На мой взгляд, это лучший ответ, и в этом случае руководство по стилю Google также соглашается с ним: google.github.io/styleguide/cppguide.html#Use_of_const: «Для параметра функции, переданного по значению, const не влияет на вызывающую программу, поэтому не рекомендуется в объявлениях функций. См. TotW # 109.»

Я решил также добавить свой собственный ответ, который добавляет мои собственные слова, поддерживает @ Adisak, answer и цитирует Руководство по стилю Google C++ по этому вопросу: stackoverflow.com/questions/117293/….

Для первой части вашего ответа см. stackoverflow.com/questions/1143262/…, чтобы понять, почему реализация 1 не работает, но 2 можно скомпилировать. Но это все еще проблема реализации, а не API.

Я бы немедленно проверил ссылку на приоритет операторов, когда я собираюсь смешать вместе такое количество операторов (если я еще не знаю 100%), так что IMO это не проблема.

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

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

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

@anatolyg, так лучше?

По крайней мере, теперь я понимаю, что вы пытаетесь сказать! Но я не согласен: и int smfID, и const int smfID означают «передачу по значению» в C++, а int& smfID означает «передачу по ссылке».

@anatolyg В файле .h нет символа «&», и эти параметры, похоже, взаимозаменяемы для ByRef / ByVal. Единственный способ узнать это - либо поискать в документации .CHM-файла, либо подождать, пока моя программа не выйдет из строя с ошибкой «System.AccessViolationException», и попытаться выяснить, какой это параметр. Конкретная dll, которую я сейчас использую, имеет ~ 100 общедоступных методов, и я хотел бы автоматизировать создание «функций объявления».

«То, что достаточно хорошо для стандартной библиотеки, хорошо для меня» - не всегда верно. Например, стандартная библиотека постоянно использует уродливые имена переменных вроде _Tmp - вам это не нужно (на самом деле вам не разрешено их использовать).

@anatolyg это деталь реализации

Хорошо, и имена переменных, и типы с указанием const в списках аргументов являются деталями реализации. Я хочу сказать, что реализация стандартной библиотеки иногда бывает плохой. Иногда вы можете (и должны) добиться большего. Когда был написан код стандартной библиотеки - 10 лет назад? 5 лет назад (какие-то новейшие его части)? Сегодня мы можем писать лучший код.