Implementing library algorithms

[roberts.noah]

Besides being ugly, of no technical consequence and thus misleading, and
more to read and write, it's a C'ism, and so a second reason for not
using it is the general one of avoiding C'isms. For the habit of coding
C style in C++ can have adverse consequences. And the more C'isms are
used, the easier it is to slip into a C mindset.

It seems like a really minor issue to me. Reading/writing more is an
argument I often hear against C++ casting. IMHO that argument stems
just from lazyness and has no technical merrit. About it being
confusing I don't think so; there is nothing in (void) that is
confusing; its meaning is rather obvious. Uglyness is a point of
preference and so technically an invalid argument. So really the only
thing against it is that it is meaningless.

The C'isms argument has some small amount of validity, and is the only
way you used to show harm, but I don't believe it is as aweful as you
are asserting...you aren't going to "slip into the C mindset" because
you use (void) in your function declarations and definitions. In all
honesty though the whole () thing isn't used much in C anymore anyway,
because it is horrible, and people often, wrongly, interchange the
meaning of the two. In other words as a "C'ism" it is a pretty weak
one.

In all honesty I was expecting a bit more to back something as
assertive as "abomination". I also think you are misinterpreting the
quote, which is stating that () in C is an abomination, not that (void)
is; the *necessity* for void in a parameter list is what is wrong with
C. I would tend to agree with that statement for the same reason why
someone might put void in their parameter list to assert that this
function can have no parameters...leaving no room for doubt.

Another reason might be that () doesn't look as nice as (void).

 

[Alf P. Steinbach]

* (e-mail address removed) -> Alf P. Steinbach:

In all honesty I was expecting a bit more to back something as
assertive as "abomination".

Perhaps ask Bjarne, Dennis or Doug about why they call it that?

I also think you are misinterpreting the quote, which is stating that
() in C is an abomination, not that (void) is;

"Dennis and Doug called the f(void) style declaration an abomination"

I think perhaps we should defer discussion of reasons until we have
finished the discussion of whether the literal words mean what the
literal words literally say, or should be interpreted as something else.

Cheers,

- Alf

 

[roberts.noah]

I think perhaps we should defer discussion of reasons until we have
finished the discussion of whether the literal words mean what the
literal words literally say, or should be interpreted as something else.

Obviously you can't discuss this trivial matter without getting rude
and personal.

And just so you know..."literal words" that have no context literally
have no literal meaning.

"Cheers"

 

[Alf P. Steinbach]

* (e-mail address removed):

* Alf P. Steinbach:

Obviously you can't discuss this trivial matter without getting rude
and personal.

I failed to understand how you could interpret C++ "f(void)" in the
quote from Bjarne, as really meaning C "f()" -- seemingly reading
something else than written also there -- or secondly, how you could
further resolve the the difference between your mind's view and the
reality by thinking the literal text I quoted was my interpretation,
i.e. that your mismatch with reality was my fault. Now I don't quite as
much fail to understand how you could, thirdly, interpret something I
wrote as rude or personal, even though no such thing was there, as far
as I can see. Happily, since it's quoted above (I've taken the liberty
of reinserting some context) anyone can judge that for themselves.

And just so you know..."literal words" that have no context literally
have no literal meaning.

If six paragraphs isn't enough context for one sentence, simply check
out the complete interview -- Google is your friend.

Cheers,

- Alf

 

[Alan Johnson]

> One day they may even implement main in C++ to be

int main( const std::vector< std::string > argList )

In the meantime you can accomplish much the same with by starting your
programs with:

#include <vector>
#include <string>

int main(int argc, char* argv[])
{
std::vector<std::string> args(argv, argv+argc) ;



-Alan

 

[Earl Purple]

# include <iostream>
# include <algorithm>
# include <map>
# include <vector>
// more stuff
#endif

// Later:
// foo.h
# include "common_header.h"

Well it's true that the cost is low for headers that are never going to
change, i.e. standard ones. That's if we assume that they really will
never change. In an evolving world, who is certain that anything will
remain forever? Maybe one day iostream will be replaced with a better
standard library and <iostream> will be as deprecated as <iostream.h>
is now.

Certainly including any non-standard headers (i.e. your own) where not
required will lead to major headaches if you ever wish to change one -
the maintenance cost is enormous.

I guess it depends which guru you follow. Herb Sutter even recommends
including <iosfwd> rather than <iostream> in headers and often I wish
there were <strfwd> and <vecfwd> etc headers too.

I'm one of those who, when compiling in Visual C++, turns off
precompiled header (Mostly because they annoy me by forcing me to
stick a "stdafx.h" include in all my files, and you can't even
statically link in a library that isn't using your precompiled header.
Plus the .pch file occupies loads of disk space, but I'm going off
topic here).

 

[Alf P. Steinbach]

* Earl Purple:

Maybe one day iostream will be replaced with a better standard
library and <iostream> will be as deprecated as <iostream.h>
is now.

<iostream.h> is not deprecated.

<iostream.h> is not and has never been part of the C++ standard, and is
therefore not available with all compilers -- code using it won't
compile with e.g. newer versions of MSVC.

 

[Daniel T.]

I'm still having problems with implementing transform().

template< class In, class Out >
bool myTransform( In b, const In e, In dest, Out (*f)(Out arg) );

'dest' doesn't necessarily have to be the same type as 'b' and 'e', and
the fourth parameter isn't necessarily going to be a pointer to a
function, it could be a functor instead. Also, why are you returning a
bool? 'transform' should return the 3rd parameter...

Try this:

namespace my_stl {

template < typename In, typename Out, typename Op >
Out transform( In begin, In end, Out result, Op operation ) {
// implement here...
return result;
}

}