Implementing library algorithms

[Alf P. Steinbach]

Re: Implementing library algorithms

* Default User:[color=blue]
> Alf P. Steinbach wrote:
>[color=green]
> > * Default User:[/color]
>[color=green][color=darkred]
> > > I think this is dumb advice. What the OP has is in no way
> > > incorrect or non-standard. Find real things to complain about
> > > rather than this bizarre hobbyhorse of yours.[/color]
> >
> > We who provide the help in this corner of Usenet unfortunately have to
> > put up with complaints and fabrications such as yours.[/color]
>
> Nonsense. You're dispensing stylistic preference. There's nothing AT
> ALL wrong with returning 0 from main(). You just don't happen to like
> it, so you chide newbies about it. That isn't help.[/color]

That is fabrication.

I wrote

"Unnecessar y. If you do provide an explicit return from main, consider
using the constants EXIT_SUCCESS and EXIT_FAILURE. Saying what you're
doing."

Perhaps it's "dumb" (as you write) for newbies to know, perhaps it's
dumb to even consider using the features of the language and standard
library, perhaps it's chiding to mention that these things exist, but I
don't see it that way: I think especially newbies are helped by being
given information, and in no way helped by having purely informative
statements being given person-oriented, negative spins such as yours, so
that the newbie must doubt both the information and the source.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Default User]

Re: Implementing library algorithms

Alf P. Steinbach wrote:

[color=blue]
> I wrote
>
> "Unnecessar y. If you do provide an explicit return from main,
> consider using the constants EXIT_SUCCESS and EXIT_FAILURE. Saying
> what you're doing."[/color]

Perhaps I was a bit strong in my criticism. Let me just say that I feel
leaving out the return is bad policy, even though the language allows
it. It's a maintenance problem because it's not clear whether the
programmer intended to do that or just forgot.

Additionally, I think "return 0" is prefectly idiomatic and well
understood in this context. Obviously, if someone uses non-standard
forms like "return -1" or something similar, it is a problem. I
certainly would never object to someone who wanted to use EXIT_SUCCESS,
but it isn't necessary.



Brian

[Alf P. Steinbach]

Re: Implementing library algorithms

* roberts.noah@gm ail.com:[color=blue]
>
> Alf P. Steinbach wrote:
>[color=green]
> > But there are reasons why so many expert programmers, including the
> > language creators, have ended up with the same bias on ["void" argument lists].[/color]
>
> Like?[/color]

See my earlier posting in this thread (including the FAQ link I provided
there, and the link from that FAQ item to Bjarne Stroustrup's writings).

Bjarne Stroustrup said this in an interview with Dr. Dobbs Journal:

<quote>
Dennis Ritchie and Doug McIlroy famously gave me courage to break with
ANSI C in the issue of the declaration of a function with an empty
argument list. To preserve compatibility with K&R C, I had invented the

int f(void);

notation for C with Classes. Initially, I retained the old meaning of

int f();

as "f()" can accept any arguments that happens to be compatible with
f()'s (unseen) definition". Dennis and Doug called the f(void) style
declaration an abomination, so in C++

int f();

now has the obviuos meaning: "f() takes no arguments." Unfortunately,
ANSI C adopted f(void) so I had to introduce f(void) into C++ for ANSI C
compatibility.
</quote>

I.e., 'T f(void)' only exists in C++ for compatibility with C which
adopted this kludge from C++ before C++ evolved to a cleaner declaration
syntax where it wasn't needed -- except for (now) C compatibility.. .

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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[JustBoo]

Re: Implementing library algorithms

On Mon, 16 Jan 2006 15:04:30 GMT, alfps@start.no (Alf P. Steinbach)
wrote:[color=blue][color=green][color=darkred]
>> >> return 0;
>> >
>> > Unnecessary. If you do provide an explicit return from main, consider
>> > using the constants EXIT_SUCCESS and EXIT_FAILURE. Saying what you're
>> > doing.[/color][/color][/color]

From the FAQ that is said to be the official FAQ of this ng.

http://www.parashift.com/c++-faq-lite/newbie.html

Section [29.3]:

<quote>
int main() // GOOD
{
...
}
As to the specific return value, if you don't know what else to
return just say return 0;
</quote>

"If you have ten thousand regulations you destroy
all respect for the law." - Winston Churchill

[Alf P. Steinbach]

Re: Implementing library algorithms

* JustBoo:[color=blue]
> On Mon, 16 Jan 2006 15:04:30 GMT, alfps@start.no (Alf P. Steinbach)
> wrote:[color=green][color=darkred]
> >> >> return 0;
> >> >
> >> > Unnecessary. If you do provide an explicit return from main, consider
> >> > using the constants EXIT_SUCCESS and EXIT_FAILURE. Saying what you're
> >> > doing.[/color][/color]
>
> From the FAQ that is said to be the official FAQ of this ng.
>
> http://www.parashift.com/c++-faq-lite/newbie.html
> Section [29.3]:
>
> <quote>
> int main() // GOOD
> {
> ...
> }
> As to the specific return value, if you don't know what else to
> return just say return 0;
> </quote>[/color]

Yes. Unfortunately the FAQ doesn't discuss EXIT_SUCCESS and
EXIT_FAILURE. And mostly it teaches the common way to write a main
function by example: 1 example contains a "return 0", and the rest,
about ten or twenty main functions, simply end with "}".

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[roberts.noah@gmail.com]

Re: Implementing library algorithms


Alf P. Steinbach wrote:
[color=blue]
> 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.[/color]

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 "abominatio n". 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...le aving no room for doubt.

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

[Alf P. Steinbach]

Re: Implementing library algorithms

* roberts.noah@gm ail.com -> Alf P. Steinbach:[color=blue]
>
> In all honesty I was expecting a bit more to back something as
> assertive as "abominatio n".[/color]

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

[color=blue]
> I also think you are misinterpreting the quote, which is stating that
> () in C is an abomination, not that (void) is;[/color]

"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

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[roberts.noah@gmail.com]

Re: Implementing library algorithms


Alf P. Steinbach wrote:
[color=blue]
> 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.[/color]

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]

Re: Implementing library algorithms

* roberts.noah@gm ail.com:[color=blue]
> * Alf P. Steinbach:[color=green]
> > * roberts.noah@gm ail.com:[color=darkred]
> > >
> > > I also think you are misinterpreting the quote, which is stating
> > > that () in C is an abomination, not that (void) is;[/color]
> >
> > "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.[/color]
>
> Obviously you can't discuss this trivial matter without getting rude
> and personal.[/color]

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.

[color=blue]
> And just so you know..."literal words" that have no context literally
> have no literal meaning.[/color]

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

Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Alan Johnson]

Re: Implementing library algorithms

Earl Purple wrote:[color=blue]
> One day they may even implement main in C++ to be
>
> int main( const std::vector< std::string > argList )[/color]

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]

Re: Implementing library algorithms

>[color=blue]
> # include <iostream>
> # include <algorithm>
> # include <map>
> # include <vector>
> // more stuff
> #endif
>
> // Later:
> // foo.h
> # include "common_header. h"
>[/color]

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]

Re: Implementing library algorithms

* Earl Purple:[color=blue]
> Maybe one day iostream will be replaced with a better standard
> library and <iostream> will be as deprecated as <iostream.h>
> is now.[/color]

<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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Daniel T.]

Re: Implementing library algorithms

In article <43cbc3ca@usene t.zapto.org>, Peter <nospam@nospam. org>
wrote:
[color=blue]
> 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) );[/color]

'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;
}

}