soft and program: 25 new messages in 9 topics

comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en

comp.lang.c++@googlegroups.com

Today's topics:

* cout vs std::cout - 13 messages, 5 authors
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/4f48acdaa9e16cee?hl=en
* How to make non-blocking call to cin? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/0ab112b61c8dc29e?hl=en
* CopyConstructible requirement for standard library containers - 1 messages,
1 author
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/f8121f7c614c7949?hl=en
* Trying to apply SFINAE - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/2d8ff4d0d6e8c793?hl=en
* comp.lang.c++ / C++ user community - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/505c05e0a15936dc?hl=en
* static/nonstatic data member declaration/definition - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/43a61151cda6482c?hl=en
* new multicore programming docs for GCC and Visual Studio - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/721c9d1676786578?hl=en
* std:sort predicate function optional arguments - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/919bd84768c51f2e?hl=en
* site map 1 - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/a2011ee5c425f644?hl=en

==============================================================================
TOPIC: cout vs std::cout
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/4f48acdaa9e16cee?hl=en
==============================================================================

== 1 of 13 ==
Date: Mon, Sep 29 2008 8:04 am
From: Matthias Buelow

Yannick Tremblay wrote:

> using namespace std; // or remove std:: altogether
> using namespace DoraTheExplorer;

...^ here

> int main()
> {
> map theMap; // should this compile or error
> // due to missing template arguments?

It should wail about symbol collision...^

Dunno if it does (too lazy^Wbusy to check now), b0rk3d as C++ is, it
probably doesn't.

== 2 of 13 ==
Date: Mon, Sep 29 2008 8:38 am
From: ytrembla@nyx.nyx.net (Yannick Tremblay)

In article <6kc939F76g72U1@mid.dfncis.de>,
Matthias Buelow <mkb@incubus.de> wrote:
>Yannick Tremblay wrote:
>
>> using namespace std; // or remove std:: altogether
>> using namespace DoraTheExplorer;
>
>...^ here
>
>> int main()
>> {
>> map theMap; // should this compile or error
>> // due to missing template arguments?
>
>It should wail about symbol collision...^
>
>Dunno if it does (too lazy^Wbusy to check now), b0rk3d as C++ is, it
>probably doesn't.

Either of the three possible outcomes are undesirable.

I like to write my code the way it feels natural. Words like "find"
"sort" "map" "list" "pair", etc are likely to be used. Widening the
range of reserved identifiers/symbols to everything contained in the
C++ standard library steal from me a lot of possible identifiers I
might have liked to use and force me to use less natural words for
these which might make the code less clear, less readable, more bug
prone and harder to maintain. Worse: I might not even know that a
word is reserved by the standard library. I am pretty much able to
remember not to use the C++ reserved keywords (albeit I keep trying to
use "default":-( but pulling the whole standard library in the global
namespace hugely increases the list of reserved words that I am not
allowed to use. I don't want it.

If I write "using namespace std;" at the top of a file, I know that I
am pulling all that in the global namespace but the key is that I
choose to do it. I am perfectly allowed to use "map" for my own
purpose if I don't do "using namespace std;"

So personally, I do not find the std:: namespace a clutter but a very
useful tool.

Yan

== 3 of 13 ==
Date: Mon, Sep 29 2008 8:43 am
From: ytrembla@nyx.nyx.net (Yannick Tremblay)

In article <gbqqk9$v30$1@cb.generation-online.de>,
Hendrik Schober <spamtrap@gmx.de> wrote:
>Yannick Tremblay wrote:
>> In article <gbonpf$2ve$1@cb.generation-online.de>,
>> Hendrik Schober <spamtrap@gmx.de> wrote:
>>> Mark Casternoff wrote:
>>> OTOH, I have used #2 for about a decade now and worked on projects
>>> where it was required that /all/ identifiers have to be within some
>>> namespaces and that /all/ identifiers are to be addressed with their
>>> fully qualified name. So I /know/ that it isn't hard to read code
>>> which fully qualifies all identifiers after a short while of looking
>>> at such code (that's a "short" as in "weeks" or "months"). And this
>>> isn't only my personal POV. Most of the time I worked under the rule
>>> that using declarations (and even using directives!) where allowed
>>> within any local scopes not bigger than a function, but this was
>>> rarely ever used by anyone (with "rarely" meaning "far less than 1%
>>> of the project's code"). I suppose that was because, after a short
>>> while, people who really tried to work that way liked code better
>>> that used fully qualified identifiers. (I abhor code that uses a
>>> naked 'list' beside a naked 'cout', as I have no idea whether that
>>> is 'std::list' or some other identifier.)
>>>
>>> What I've learned, though, is to avoid creating namespaces which are
>>> long and hard to type right even after weeks ('StringUtility') of
>>> usage. :)
>>
>> So essentially, the virtual ban on "using" coupled with the compulsory
>> namespace for everything leads to the creation of crytic namespace
>> identifiers?
>> [Ridiculous example deleted]
>
> No. The next project introduced its string utilities
> in a namespace 'Strings'.

But the point remains that "Strings" is less clear than "StringUtility".

In this particular case, the loss of clarity is probably acceptable
but that virtual ban on namespaces is IMO a bad thing because I
think it encourages bad naming.

Yannick

== 4 of 13 ==
Date: Mon, Sep 29 2008 9:22 am
From: Hendrik Schober

Yannick Tremblay wrote:
> In article <gbqqk9$v30$1@cb.generation-online.de>,
> Hendrik Schober <spamtrap@gmx.de> wrote:
>> Yannick Tremblay wrote:
>>> [Ridiculous example deleted]
>> No. The next project introduced its string utilities
>> in a namespace 'Strings'.
>
> But the point remains that "Strings" is less clear than "StringUtility".
>
> In this particular case, the loss of clarity is probably acceptable
> but that virtual ban on namespaces is IMO a bad thing because I
> think it encourages bad naming.

Which ban?

> Yannick

Schobi

== 5 of 13 ==
Date: Mon, Sep 29 2008 9:25 am
From: Hendrik Schober

Rolf Magnus wrote:
> [...]
> A disadvantage of explicitly qualifying with ::std or even with std is that
> it makes it hard to create your own cout and replace all uses of the
> standard cout with this one. If you have a
>
> using std::cout;
>
> cout << "Hello world\n";

What about
std::ostream& mine = std::cout;
then? This allows to redefine 'mine' later and doesn't
need to have 'std::' removed from 'cout'. Or am I missing
something?

> [...]

Schobi

== 6 of 13 ==
Date: Mon, Sep 29 2008 9:48 am
From: Hendrik Schober

Matthias Buelow wrote:
> Mark Casternoff wrote:
>
>> I've seen both methods in code, but I'm seeing #2 a lot more frequently.
>
> It's because many C++ programmers prefer long-winded bureaucracy over
> conciseness or even (shock!) simplicity. :) Why do you think the STL is
> like it is?

The STL is like /what/?

> I've never heard a good reason why one shouldn't do a "using namespace
> std;" at the beginning of every compilation unit.

You mean except for the fact that it might silently make your
code fail at run-time?

> Maybe there're some
> special cases where it might cause problems but usually not using that
> is rather nonsensical, imho. The std:: is just clutter and that's
> usually bad in a program.

So are static types. Let's get rid of them.

Schobi

== 7 of 13 ==
Date: Mon, Sep 29 2008 9:59 am
From: Matthias Buelow

Hendrik Schober wrote:

> So are static types. Let's get rid of them.

Yes, please.

== 8 of 13 ==
Date: Mon, Sep 29 2008 10:29 am
From: Juha Nieminen

Matthias Buelow wrote:
> It's because many C++ programmers prefer long-winded bureaucracy over
> conciseness or even (shock!) simplicity. :)

Some programmers prefer clarity over conciseness. The simplicity of
the code is not changed either way.

I really don't understand the obsession some people (especially
beginners) have about writing code which is as short as possible. Of
course this doesn't mean you should prefer the opposite either, but too
concise == obfuscated.

Do you name all your variables with one single character, and when you
run out of the a-zA-Z characters do you start using to-character
variables? Or do you prefer naming your variables *descriptively*
regardless of how long they become? This is a perfect example where
concise code only leads to obfuscated code which is hard to read and
understand.

When you use the "std::" prefix you are self-documenting the code: You
are telling the reader what kind of function/type that is (a standard
one) and where its definition can be found (in the standard libraries).
For example, if I see this in some random code:

generate(v.begin(), v.end(), foo);

it's not immediately obvious what this "generate" function is. Is it a
function defined in the same program somewhere? However, if I see this:

std::generate(v.begin(), v.end(), foo);

then there just is absolutely no confusion at all. I *immediately* see
that this is a function from the C++ standard library. Even if I had
never even heard of the "std::generate" function, I would still
immediately know where to look for it.

In this case the "std::" prefix made a remarkable difference in
clarity and readability: It made it enormously easier to understand
what's going on (ie. a standard C++ library function is being called,
rather than some program-specific function defined somewhere).

As an added bonus you might avoid name collisions better by leaving
namespaces as they are.

> The std:: is just clutter and that's usually bad in a program.

"Just clutter" which makes the code more readable and easier to
understand. Yeah, sure.

I prefer this "clutter" any day over concise code which nobody but the
author can read fluently (and even him only for a couple of weeks after
he wrote it).

== 9 of 13 ==
Date: Mon, Sep 29 2008 10:36 am
From: Juha Nieminen

Mark Casternoff wrote:
> 1) using std::cout;
> cout << "This is a test";
>
> 2) std::cout << "This is a test";

Let me ask you a question: What did you gain in #1 that made it worth
the "using" line?

Did you gain in code clarity? Is #1 clearer code than #2? Would you
have a harder time understanding #2 than #1?

In fact, I would argue that #2 results in clearer and easier to
understand code. I already posted this example in this thread, but let
me repeat it here. If you see this line in a random piece of long code:

generate(v.begin(), v.end(), foo);

what does that tell you? Is this "generate" function some function
defined elsewhere in the code? Or is it a standard function? Maybe it's
both? How can you know? You can't know unless you examine large amounts
of the program source code or documentation (although some interactive
compilers might make this task easier).

However, assume you instead see this:

std::generate(v.begin(), v.end(), foo);

Now there's absolutely no confusion: "generate" is a function in the
standard C++ library. Even if you have never even heard about this
function, you immediately know where to look for it. You don't have to
try to guess anything.

In this case the "std::" prefix made the code a lot more easier to
understand. Why some people consider this a bad thing is something I
will never understand.

== 10 of 13 ==
Date: Mon, Sep 29 2008 11:00 am
From: Matthias Buelow

Juha Nieminen wrote:

> In this case the "std::" prefix made the code a lot more easier to
> understand. Why some people consider this a bad thing is something I
> will never understand.

The problem exists on a different abstraction layer. Do you want having
to specially mark everything that isn't in the user program space in
fear of collision? I certainly don't since that turns programs really
ugly for little to no gain.

== 11 of 13 ==
Date: Mon, Sep 29 2008 11:20 am
From: Juha Nieminen

Matthias Buelow wrote:
> Juha Nieminen wrote:
>
>> In this case the "std::" prefix made the code a lot more easier to
>> understand. Why some people consider this a bad thing is something I
>> will never understand.
>
> The problem exists on a different abstraction layer. Do you want having
> to specially mark everything that isn't in the user program space in
> fear of collision? I certainly don't since that turns programs really
> ugly for little to no gain.

I never use the "using" keyword to get rid of a namespace, and I have
never found the program becoming "ugly". On the contrary, when you get
used to reading the namespace prefixes, the effect is the opposite: The
program becomes clearer and easier to read.

Exactly what do you find "ugly" in the namespace prefixes? The two ':'
symbols? Come on, please.

== 12 of 13 ==
Date: Mon, Sep 29 2008 11:30 am
From: Matthias Buelow

Juha Nieminen wrote:

> Exactly what do you find "ugly" in the namespace prefixes? The two ':'
> symbols? Come on, please.

The entire prefix is visually unappealing (although not really that much
of an eye-catcher in a C++ program) but more important is the fact that
I have to provide more detail than necessary, which is especially
obtrusive in a local context.

== 13 of 13 ==
Date: Mon, Sep 29 2008 11:36 am
From: Rolf Magnus

Hendrik Schober wrote:

> Rolf Magnus wrote:
>> [...]
>> A disadvantage of explicitly qualifying with ::std or even with std is
>> that it makes it hard to create your own cout and replace all uses of the
>> standard cout with this one. If you have a
>>
>> using std::cout;
>>
>> cout << "Hello world\n";
>
> What about
> std::ostream& mine = std::cout;
> then?
> This allows to redefine 'mine' later and doesn't
> need to have 'std::' removed from 'cout'. Or am I missing
> something?

That would work, too - if you wrote your whole program with that in mind and
only use libraries where this is done too.

==============================================================================
TOPIC: How to make non-blocking call to cin?
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/0ab112b61c8dc29e?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Sep 29 2008 8:18 am
From: ytrembla@nyx.nyx.net (Yannick Tremblay)

In article <f1ea726e-49a0-440b-bad9-1c8ca1637b11@a70g2000hsh.googlegroups.com>,
puzzlecracker <ironsel2000@gmail.com> wrote:
>is it even possible or/and there is a better alternative to accept
>input in a nonblocking manner?

I'd avoid the problem altogether:

I'd simply create a cin reader thread whose job would be to read input
safely from a blocking cin. It could also be charged with validating
this input if desirable.

I'd put a thread safe FIFO communication mechanism between the two
threads (e.g. mutex protected std::queue) and the main process thread
would peek if there is a message on the queue for it, if so, read and
process it, if not, continue with its other tasks.

To me, that sounds simpler than trying to turn cin as non-blocking.
plus anyway, non-blocking cin would think that there is data to be
read if only one character was present in the buffer but you may wish
to get input as complete words (lines?) and not interrupt normal
processing until a complete word is available. This would be trivial
to do with the input thread model but much more difficult with a
non-blocking cin or stdin.

Yannick
P.S.: Obviously, I'd use Boost Thread for that...
http://www.boost.org/doc/libs/1_36_0/doc/html/thread.html

==============================================================================
TOPIC: CopyConstructible requirement for standard library containers
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/f8121f7c614c7949?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Sep 29 2008 9:07 am
From: James Kanze

On Sep 29, 5:00 pm, "subramanian10...@yahoo.com, India"
<subramanian10...@yahoo.com> wrote:
> Suppose 'Test' is a class.

> In order to use 'Test' as element type for a standard library
> container, say, vector, 'Test' class must be CopyConstructible and
> Assignable.

> Does CopyConstructible mean that the class must support both
> direct- initialization and copy-initialization ?

No. It means that if t is an object of type T (or T const), the
expression T(t) is legal, and results in a new object which is
equivalent to t.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

==============================================================================
TOPIC: Trying to apply SFINAE
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/2d8ff4d0d6e8c793?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Sep 29 2008 9:20 am
From: Hendrik Schober

Hi,

I'm having two overloaded function templates,

#include <iterator>

template< typename T >
void test( T /*a1*/, T /*a2*/ ) {}

template< typename Iter >
void test( Iter /*b*/, Iter /*e*/ ) {}

which I need to call. (In reality, these are constructors,
in case that matters.) Unfortunately, the compiler isn't
as clever and can't tell 'T' from 'Iter', so I have to
give it a hint whether what gets passed is an iterator.
But my attempt to use SFINAE for this

template< typename Iter, class ItTr >
void test( Iter /*b*/, Iter /*e*/
, ItTr = std::iterator_traits<Iter>() ) {}

doesn't work, since this completely removed the iterator
overload from the set the compiler considered. Or that's
what I figured because this

#include <iterator>

//template< typename T >
//void test( T /*a1*/, T /*a2*/ ) {}

template< typename Iter, class ItTr >
void test( Iter /*b*/, Iter /*e*/
, ItTr = std::iterator_traits<Iter>() ) {}

int main()
{
const int fa[] = { 255, 255, 255, 255 };

//test(0,1);
test(fa, fa+4);

return 0;
}

doesn't compile.
Now I'm stumped. I thought I had done this before, so I am
probably making something stupid here. (It's already passed
6pm here...)

Anyone out there?

TIA,

Schobi

== 2 of 2 ==
Date: Mon, Sep 29 2008 10:39 am
From: Victor Bazarov

Hendrik Schober wrote:
> [..]
> #include <iterator>
>
> //template< typename T >
> //void test( T /*a1*/, T /*a2*/ ) {}
>
> template< typename Iter, class ItTr >
> void test( Iter /*b*/, Iter /*e*/
> , ItTr = std::iterator_traits<Iter>() ) {}
>
> int main()
> {
> const int fa[] = { 255, 255, 255, 255 };
>
> //test(0,1);
> test(fa, fa+4);
>
> return 0;
> }
>
> doesn't compile.
> [..]

Well, the compiler cannot deduce the type from a default argument, I
vaguely recall that it's a non-deducible context. That's why putting
the traits there won't cut it. Consider

#include <iterator>

template<typename Iter>
void test(Iter, Iter, std::iterator_traits<Iter> const* = 0);

int main ()
{
const int fa[] = { 1,2,3,4 };
test(fa, fa+4);
}

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

==============================================================================
TOPIC: comp.lang.c++ / C++ user community
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/505c05e0a15936dc?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Sep 29 2008 10:19 am
From: Zeppe

James Kanze wrote:

> Well, I do practically the opposite: I provide toString and
> fromString functions. Generated automatically, of course; no
> point it writing this all out by hand yourself.

Ah! Now everything's clear! I though you were suggesting scripts that
acted as a sort of pre-preprocessor of the code, rather than a one-shot
utility to copy and paste automatically generated code into your source
files. Right then, I agree with your approach!

On whether to automate operator<< or toString, I'd say no much
difference is involved. Maybe providing operator<< you may have more
freedom while using custom streambuffers or things like that, and avoid
a double conversion when using formatted output.

Best wishes,

Zeppe

==============================================================================
TOPIC: static/nonstatic data member declaration/definition
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/43a61151cda6482c?hl=en
==============================================================================

== 1 of 4 ==
Date: Mon, Sep 29 2008 10:41 am
From: Juha Nieminen

James Kanze wrote:
> Mainly historical reasons, I suspect, but of course, if there is
> an initializer (as there usually should be), you usually don't
> want it in a header.

Aren't static variables always initialized to 0 (or null), even
without a specific initialization?

== 2 of 4 ==
Date: Mon, Sep 29 2008 10:43 am
From: Juha Nieminen

Jeff Schwab wrote:
>> Because you only want the definition to be in one translation unit, or
>> you'll get link errors. The declarations, on the other hand, should
>> be in every translation unit that needs access to them.
>
> Btw, there's a loop-hole for class templates. Static member variables
> of class templates (not including explicit specializations) can live
> right up in the header file, along with the rest of the corresponding
> template definition.

Personally I see no reason why this should be supported for templates
and *not* for non-templates. What would be the reason for the latter?

Btw, the next standard will allow specifying initial values for member
variables in the variable definitions (so that you don't have to
initialize them explicitly in the constructor), ie:

class A
{
int i = 5, j = 10;
};

Will this extend to static member variables as well?

== 3 of 4 ==
Date: Mon, Sep 29 2008 11:04 am
From: Andrey Tarasevich

Jeffrey wrote:
> My understanding is that if you write
>
> class X {
> int y;
> static int z;
> };
>
> then you've defined (and declared) X

Yes.

> and y,

No. You only _declared_ 'y' as a member of class 'X'. Non-static data
members of classes don't get [independently] _defined_ in C++ at all.
The notion is simply not applicable here.

From the less formal point of view, the purpose of defining a data
entity is to associate a storage location with it. For non-static data
members the storage is assigned when (and where) the complete object is
defined.

> but you have only declared
> (and not defined) z.

Same as with 'y' or any other data member.

> If you'd like to actually define z, you also
> need to add
>
> int X::z;

Yes. And you have to do it in one and only one translation unit.

> Can anybody tell me the reason that the language was designed to be
> like this?

When you define something that has a location in storage, the compiler
normally wants to know which translation unit this definition should be
associated with. The responsibility of choosing the translation unit is
delegated to you. This is what really hides behind the need to define it.

> It seems it would be simpler if z were defined in the same
> way as y, so presumably there's some good reason.

Firstly, you assumption that 'y' is "defined" by class definition alone
is incorrect. It isn't.

Secondly, the "definition" if 'y' (in the "storage allocation" sense)
can happen the way it happens specifically because it is a non-static
data member of the class. It can't apply to 'z'.

--
Best regards,
Andrey Tarasevich

== 4 of 4 ==
Date: Mon, Sep 29 2008 12:34 pm
From: Jeff Schwab

Juha Nieminen wrote:
> Jeff Schwab wrote:
>>> Because you only want the definition to be in one translation unit, or
>>> you'll get link errors. The declarations, on the other hand, should
>>> be in every translation unit that needs access to them.
>> Btw, there's a loop-hole for class templates. Static member variables
>> of class templates (not including explicit specializations) can live
>> right up in the header file, along with the rest of the corresponding
>> template definition.
>
> Personally I see no reason why this should be supported for templates
> and *not* for non-templates. What would be the reason for the latter?
>
> Btw, the next standard will allow specifying initial values for member
> variables in the variable definitions (so that you don't have to
> initialize them explicitly in the constructor), ie:
>
> class A
> {
> int i = 5, j = 10;
> };
>
> Will this extend to static member variables as well?

I don't believe so. The point of the in-class member initialization (I
would guess) is to let multiple constructors leverage common
member-initialization code, rather than all defining
similar-but-different initializer lists. The same reasoning doesn't
really apply to static members, which aren't initialized in
constructors' initializer lists at all.

AFAIK, this is the latest version of the proposal:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2712.html

==============================================================================
TOPIC: new multicore programming docs for GCC and Visual Studio
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/721c9d1676786578?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Sep 29 2008 10:43 am
From: Jean-Marc Desperrier

Chris M. Thomasson wrote:
> [comp.lang.c++ added...
>
> http://groups.google.com/group/comp.programming.threads/browse_frm/thread/e753228b20889a11
>
> ]

And why not remove fr.comp.lang.c++ ?

Please everyone posting to this thread !

==============================================================================
TOPIC: std:sort predicate function optional arguments
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/919bd84768c51f2e?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Sep 29 2008 10:45 am
From: Juha Nieminen

Xiaobin Huang wrote:
> you can provide your own predicate.
>
> class cmp {
> public:
> cmp(...) {
> // init thePoint_
> }
> bool operator() (point const& lh, point const& rh) {
> // ...
> }
> private:
> point thePoint_;
> };

Nitpicking, but isn't that called a comparator? If is it *also* a
predicate?

==============================================================================
TOPIC: site map 1
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/a2011ee5c425f644?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Sep 29 2008 12:21 pm
From: jamo