[trolling] Part of why I hate iostreams... <g>

[Alf P. Steinbach]

It's Easter, so I'm flinging an egg in the direction of this newsgroup.


<code language="C++">
// In other languages a simple task!
// The question is, could this be obfuscated even more, plus perhaps made even
// less efficient, by suitable (under-documented) standard library requirements?

#include <iostream>
#include <limits>
#include <locale>

namespace std
{
// This overload of the endl function template can't formally be in 'std',
// that is, extensions such as this are not supported.
template< typename CharT, typename Traits >
basic_istream<CharT, Traits>& endl( basic_istream<CharT, Traits>& is )
{
is.ignore(
numeric_limits<streamsize>::max(), // Incorrectly documented C++98.
Traits::to_int_type( use_facet< ctype<CharT> >( is.getloc()
).widen( '\n' ) )
);
return is;
}
}

int main()
{
using namespace std;

cout << "Press return, please: ";
cin >> endl;
}
</code>


Cheers,

- Alf

 

[Bo Persson]

It's Easter, so I'm flinging an egg in the direction of this
newsgroup.

<code language="C++">
// In other languages a simple task!
// The question is, could this be obfuscated even more, plus
perhaps made even // less efficient, by suitable (under-documented)
standard library requirements?
#include <iostream>
#include <limits>
#include <locale>

namespace std
{
// This overload of the endl function template can't formally
be in 'std', // that is, extensions such as this are not
supported. template< typename CharT, typename Traits >
basic_istream<CharT, Traits>& endl( basic_istream<CharT,
Traits>& is ) {
is.ignore(
numeric_limits<streamsize>::max(), // Incorrectly
documented C++98. Traits::to_int_type( use_facet<
ctype<CharT> >( is.getloc() ).widen( '\n' ) )
);
return is;
}
}

int main()
{
using namespace std;

cout << "Press return, please: ";
cin >> endl;
}
</code>


Cheers,

- Alf

You have a long way to the Obfuscated C Contest, but not too bad.

The real question is of course why you would want an endl manipulator
for cin, in the first place? What's wrong with just calling
cin.ignore(large_value)?

The odds of finding both a char_traits and a locale for anything other
that char and wchar_t is so close to zero (0.0L), that you would need
extended precision to compute it.


Do you have a Part II?


Bo Persson

 

[coal]

It's Easter, so I'm flinging an egg in the direction of this newsgroup.

<code language="C++">
// In other languages a simple task!
// The question is, could this be obfuscated even more, plus perhaps made even
// less efficient, by suitable (under-documented) standard library requirements?

There was some work going on within Boost to replace iostreams
a few years ago. The work was separate from the Boost IOStreams
library. I haven't heard anything about that work recently
though. In the meantime, I recommend minimizing use of the
standard iostreams library.

Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[gw7rib]

It's Easter, so I'm flinging an egg in the direction of this newsgroup.

     cin >> endl;}

I once considered writing a class to do parsing, one feature of which
would have used endl, eg

par >> "Number" >> ' ' >> n >> endl

would check that there was an end of line after the number. I then
read through the (draft) standard, and discovered that endl isn't a
char, it isn't an int, it's Something Truly Horrible.

The rest of the parser works, however, and I may expand it to include

par >> "Number" >> ' ' >> n >> '\n'

or possibly

par >> "Number" >> ' ' >> n >> EOF

instead.

 

[James Kanze]

It's Easter, so I'm flinging an egg in the direction of this
newsgroup.

A rotten egg, in fact.

<code language="C++">
// In other languages a simple task!

What is a simple task? Obfuscation? (C++ is actually one of
the best languages for that, too, if that's your goal.)

// The question is, could this be obfuscated even more, plus perhaps made even
// less efficient, by suitable (under-documented) standard library requirements?

The question is: what is "this"? What is this code supposed to
do?

#include <iostream>
#include <limits>
#include <locale>

namespace std
{
// This overload of the endl function template can't formally be in 'std',
// that is, extensions such as this are not supported.

You don't want to overload std::endl. Everyone knows what it
does (or should); overloading it can only cause confusion in the
reader's mind.

template< typename CharT, typename Traits >
basic_istream<CharT, Traits>& endl( basic_istream<CharT, Traits>& is )
{
is.ignore(
numeric_limits<streamsize>::max(), // Incorrectly documented C++98.
Traits::to_int_type( use_facet< ctype<CharT> >( is.getloc()
).widen( '\n' ) )
);
return is;
}
}

Is the goal is to create a manipulator which reads up to and
including the next '\n', ignoring the input. That's certainly
not what I'd expect from std::endl.

The easiest solution is:

namespace MyLib { // Because it's not standard!
template< typename CharT, typename Traits >
// But IMHO, the template is
// superfluous, and a waste of
// productive effort.
std::basic_istream< CharT, Traits >&
toNextLine(
std::basic_istream< CharT, Traits >&
source )
{
std::string dummy ;
std::getline( source, dummy ) ;
return source ;
}
}

Obviously, that's going to encounter a few problems if you have
files with linelengths in the gigabyte range, but is that really
a problem in practice?

In practice, I'd make it even simpler by ignoring the template
business. (The committee did screw up there, and the best thing
you can say about the templates in iostream is that you can
successfully ignore them. And since you're comparing with other
languages---what other language would allow the templated
solution to begin with?) In that case,

int ch = source.get() ;
while ( ch != EOF && ch != '\n' ) {
ch = source.get() ;
}

works just fine in the function, and avoids the expense of
constructing the string. (Of course, this is what
istream::ignore does to begin with.)