On Wed, Apr 17, 2013 at 8:51 AM, Mike Small <sma...@panix.com> wrote:
> Ben Tilly <bti...@gmail.com> writes:
>
>> On Wed, Apr 17, 2013 at 7:29 AM, Greg London <em...@greglondon.com> wrote:
>>> Why use macros when you can write a function?
>>
>> Lisp weenie answer: because the arguments to functions may produce
>> side effects, while with macros you can control that.  Of course the
>> Lisp answer is inapplicable in other languages because their macros
>> are less reliable.
>>
>> C/C++ answer: because with a macro you can choose whether to try to
>> call functions that might or might not exist on your platform, and
>> would make the compiler miserable if it saw it.
>
> I haven't really gone there myself (the words template metaprogramming
> and SFINAE still make me squirm a bit), but I gather you can do most or
> all of this using templates these days. It's an improvement I think, if
> nothing else because you're not calling what you're making a macro with
> whatever expectations that might give a Lisp programmer. Besides, the
> support for this (e.g. avoiding the monstrous error messages or the
> weirdly hackish nature of the techniques) is something they look to
> improve in newer standards, so maybe someday the code to do it will be
> more natural to people who don't know templates top to bottom.

I have done some template metaprogramming, but I'm much more of a
consumer than a user.  I do not know the full capabilities.  However
while we're on that topic, I have a respect/hate relationship with the
STL.  I respect it, but hate using it.  As an example of a beef,
consider iterators.

If I have a vector of type Foo, then an iterator over it has type
std::vector< Foo >::iterator.

If I have a map from Foo to Bar, then an iterator over it has type
std::map< Foo, Bar >::iterator.

If I have a set of things of type Foo, then an iterator over it has
type std::set< Foo >::iterator.

What's wrong with this?  As a programmer I don't care what data type
they came from, I care what I am getting out of them.  Therefore I
would prefer the data types std::iterator< Foo >, std::iterator<
std::pair< Foo, Bar > >, and std::iterator< Foo >.  For the use cases
currently supported by the STL, the compiler should be able to trace
through the data, and replace with what you currently have to write,
and then do something efficient.  But it can fall back on a "slow"
generic implementation.  (Slow in quotes because other languages do
not even blink at what is required.)

What would you gain from this?  Well read
http://perl.plover.com/Stream/stream.html and it is easy to translate
those examples into easy abstractions over the types that I wish the
STL provided.  But none of it can be easily done in C++ today.  (Well,
I can write the slow generic implementation and make it work, but not
so easily.)

_______________________________________________
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm

Reply via email to