Re: [Boost-users] Is it a good style about boost::format( format-string ) % arg1 % arg2 % ... % argN

From: William Xue (william.xue_at_[hidden])
Date: 2006-10-12 23:31:42

Thanks for your reply.

On Fri, 13 Oct 2006 01:03:33 +0800, loufoque  
<mathias.gaunard_at_[hidden]> wrote:

> William Xue wrote:
>
>> Thank you very much! Your explanation is very clear. I am agree with  
>> you,
>> it's nasty.
>
> He said variable arguments were nasty. This is not the case of this
> type-safe chaining.

Maybe, But I think what we talked about is 'boost::format( format-string )  
% arg1 % arg2 % ... % argN',
And 'Not only that, but the ...'.

>  From what you're saying, it seems you understood it the other way
> around. Excuse me if I am the one who understood you wrong.
>
>
>> Though C/C++ is very flexible, I do not like to broke the regular rules  
>> of
>> them.
>
> C and C++ are different languages.
> Variable arguments, a feature from C, has a lot of problems and
> shouldn't be used at all in C++ since you can build better alternatives.
>
> Using that kind of chaining is not "breaking the regular rules". It's an

I agreed with "a chain is not 'breaking the regular rules'". But use a  
chain as a argument
of a function (maybe not on syntactical, but it is on using), AND the  
argument what is out
of the function's argument declaration list, this is 'breaking the regular  
rules'.

> usage of the generic paradigm from C++, which is what makes boost what
> it is.
>

C++ is powerful, another example, gun is also. We can use it in this way,  
use it in that way,
But we should always use it in a right way. Just a figure of speech.

>
>> Micrisoft have done something like this in their sample codes:
>> ---8<--------------------------------------------->8---
>> #define PURE =0
>> ...
>> interface xxx
>> {
>> ...
>> int foo(...) PURE;
>> ...
>> };
>> ---8<--------------------------------------------->8---
>>
>> I can not to find out any wisdom in doing things like this.
>
> Usually you don't use the define PURE or a fake interface keyword, but
> it is a very usual concept : it's an abstract base class.
> It's only used in polymorphic designs though, which are unrelated to
> boost.format.
>

It's just a example. Could you tell me why they use a macro to declare a  
abstract base class,
instead of dircetly using '=0' ?
I don't conceal what I have thought, they define the macro is only for  
design, overengineering,
Just like "format" here.

For, if I did not know this MACRO, it's hard to understand what's the  
meaning of 'int foo(...) PURE;',
but it's very clear of 'int foo(...) = 0;', even if I am a beginner of  
C++, isn't it?

PURE is only one of examples in codes of, as you said, polymorphic design.  
It's hard to understand,
hard to study those technologies when there are a large number of these  
MACROs, essentially,
they can be a little easier.

Well, this is another topic.

>
>> As a C/C++ user, I am very glad to see someone to extend the features of
>> them,
>> But IMHO, C/C++ is C/C++, do not go far away from the regular way.
>
> C/C++ is nothing. It is a term usually used by people who code C++ using
> C techniques.

Maybe I really mis-understood something, I always use C/C++ as C and C++,
or C or C++.

> There is C, and there is C++. Each one has its way of doing things. C
> not having the features from C++, the C way is probably more dangerous
> and less flexible.
>

I should say something about this.
I never thought any language is really 'dangerous', maybe you means  
libraries for C?

IMHO, Only carelessness is dangerous. Of cause, a type safe or a strict  
type checking
language is much easy to get safe.

> The C way is to use variable arguments, which aren't type safe (which
> probably leads to tons of problems) and only work for PODs.
> The C++ way could be to use variadic templates, which aren't in the
> standard yet, or to use operator overloading and do chaining (just like
> the standard iostreams).
>
> And also, if we didn't use a few tricks you may consider "not the
> regular way", generic programming in C++ and therefore boost itself
> would be very limited.
>

IMHO, Whatever you used in internal implemention, the "INTERFACE" should  
be kept simple and easy
(in the regular way) to read for any user of C++, Especially for beginners  
like me.:)

> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- 
Sincerely yours,
William