In-Reply-To: <d4j89a$cd7$1@sea.gmane.org> gennadiy.rozental@thomson.com (Gennadiy Rozental) wrote (abridged):
BOOST_FOREACH
By the way, is there a rationale for the name? I'd have expected BOOST_FOR_EACH, with a word separator between FOR and EACH because, well they are separate words. This also matches the precedent of std::for_each. Word separators are especially important for names that are all in capitals. Is there a compelling reason to omit the second underline? -- Dave Harris, Nottingham, UK.
Dave Harris wrote:
In-Reply-To: <d4j89a$cd7$1@sea.gmane.org> gennadiy.rozental@thomson.com (Gennadiy Rozental) wrote (abridged):
BOOST_FOREACH
By the way, is there a rationale for the name? I'd have expected BOOST_FOR_EACH, with a word separator between FOR and EACH because, well they are separate words. This also matches the precedent of std::for_each. Word separators are especially important for names that are all in capitals.
Is there a compelling reason to omit the second underline?
I don't think there's a /compelling/ reason, but here's my thought process: * This isn't an algorithm, so I don't want to evoke std::for_each. * It's like a new keyword, and some other languages have "foreach" as a keyword. Anyway, I'm not married to the name, and I'd gladly change it if people preferred to type an extra underscore. :-) -- Eric Niebler Boost Consulting www.boost-consulting.com
"Eric Niebler" wrote:
BOOST_FOR_EACH ... Is there a compelling reason to omit the second underline?
I don't think there's a /compelling/ reason, but here's my thought process:
* This isn't an algorithm, so I don't want to evoke std::for_each. * It's like a new keyword, and some other languages have "foreach" as a keyword.
Anyway, I'm not married to the name, and I'd gladly change it if people preferred to type an extra underscore. :-)
No, please. I'd rather like to know whether I can do a #define FOREACH(...) BOOST_FOREACH(...) in my code. /Pavel
Pavel Vozenilek wrote:
I'd rather like to know whether I can do a #define FOREACH(...) BOOST_FOREACH(...) in my code.
This can be problematic if the arguments are macros itself. This would result in an additional expansion of these macros. But you may want to write: #define FOREACH BOOST_FOREACH which is save in this regard. Regards Hartmut
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:reply-to:to:subject:date:mime-version:content-type:content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index:from:message-id; b=WTqy2ZzElSjVOko42hSMlVaGVYsNJkgfjuf/gEgdKQQNFzgJGphTKVFQKgrzQwSxRKwi6CjXwWKE69dbn4KZkg2HZ/Trr3llzJvLMt/fUWsK6/6CVByrUGiPwlskzE6+/xMIUZKwAKpM6IXTz+59/QaOOjg0Qo+E4qPR5JQ8VvU= From: Hartmut Kaiser <hartmut.kaiser@gmail.com> Pavel Vozenilek wrote:
I'd rather like to know whether I can do a #define FOREACH(...) BOOST_FOREACH(...) in my code.
This can be problematic if the arguments are macros itself. This would result in an additional expansion of these macros. But you may want to write:
#define FOREACH BOOST_FOREACH
which is save in this regard.
Pavel, that can be spelled this way too: #define FOREAcH BOOST_FOR_EACH IOW, if you want it spelled FOREACH, then Eric's macro's name doesn't matter. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Eric Niebler wrote:
Dave Harris wrote:
Is there a compelling reason to omit the second underline?
I don't think there's a /compelling/ reason, but here's my thought process:
* This isn't an algorithm, so I don't want to evoke std::for_each. * It's like a new keyword, and some other languages have "foreach" as a keyword.
Anyway, I'm not married to the name, and I'd gladly change it if people preferred to type an extra underscore. :-)
I prefer as few underscores as possible without inventing new abbreviations. Since "foreach" is an established keyword, I prefer BOOST_FOREACH to BOOST_FOR_EACH. For people who really want the second underscore, you can assure them that it is added automatically behind the scenes to save them the extra typing ;-) Jonathan
participants (6)
-
brangdon＠cix.compulink.co.uk -
Eric Niebler -
Hartmut Kaiser -
Jonathan Turkanis -
Pavel Vozenilek -
Rob Stewart