google "top coder" contest = stacked against C++ coders

[Jonathan Turkanis]

I'm saying that I don't think something should should do what I want it to
do, just because it is valid code, ergo, which was precisely the case I was
making before you stepped in and now the meaning is completely lost on you.
The irony.

The realy irony is that the irony is lost on me, too.

Jonathan

P.S. This is my lst post in this thread

 

[Archer]

I think the STL is a wonderful tools and will shorten you developing time!

 

[Owen Jacobson]

On Sat, 18 Sep 2004 04:47:35 +0300, assaarpa wrote:

(Attributions mangled by parent.)

It does not suffer at all, except for the fact that took pains to lead
you by hand to explain what the trouble was.

Let me outline what he's getting at, just in case you've missed it. You
said "Use std containers to pass objects across dll boundaries and you
crash and burn so beautifully", which implies that this is true in all
cases. As a matter of fact, it's not true in all cases. Therefore, your
generalization was incorrect by virtue of being false in some cases, which
in turn damages your credibility.

I thought it is very clear that there is no substitute for knowing what you
are doing: you can take fully legal c++ code, put it into context and have
it fail miserably.

This is not a failing of the C++ programming language, but of the
environment (in this case, the linker and the OS's shared library
mechanism). Windows' DLL semantics were designed and written in an age
when C++ was barely a drunken urge, as it were.

All of this is secondary, though: the restrictions that, you feel, make
the STL "useless" are not restricted to the C++ standard library. As has
been pointed out repeatedly, you'll have the same problem with any code
under Windows that allocates memory in one heap and tries to free it while
using a different heap. The C++ standard library happens to do a lot of
memory management, as a consequence of containing a lot of container
classes.

In short, fix your environment. The language and the library work fine.

Good, then you example earlier is obviously not related to the ongoing
argument. I mean, if you DO return std::string across DLL boundary, it is
lotto if it works or not. Isn't it? If you encapsulate it inside object
which invokes the destructor where the constructor was invoked there is no
problem, precisely example of what you might do when you know what the
problem is. Using Standard Library is tricky business in the real world, it
is not as idealistic as it is in textbooks: you just use it happily and
things "just work", in real world that is not the case is it?

Correction: using the standard library (or, indeed, anything which may do
memory allocation behind the scenes) is tricky in environments
brain-damaged enough to run library code against a different heap than the
caller. This is not a failing of the standard library -- it's a failure
in the environment to have sane memory semantics.

Aha, you , quote, "specify (the) ownership model". Now you are stepping
outside of the small box that the Standard defines and are virtually
agreeing that it doesn't guarantee that the code is "reusable", you have to
engineer the code to fit the circumastances, isn't that so?

I don't see how engineering the code to certain specifications, whether
provided as part of the language or as part of the project, in any way
impacts reusability. Any code which respects the described ownership
model will be able to use code implementing that ownership model.

ok

 

[Nicolas Pavlidis]

I think the STL is a wonderful tools and will shorten you developing time!

Thats true, if you know it.

Kind regards,
Nicolas

P.S. Please don't top post

 

[Jerry Coffin]

I recently tried out the Google "top coder" contest, as a C++
coder. I noticed immediately that they expected me to know STL.
To which I say, what the ****?!

I may be missing something, but at what point when learning C++
was I supposed to have picked up STL?

The exact point at which you "picked it up" is more or less
irrelevant. For some of us living fossils, learning about the
containers, iterators, etc. had to wait until they existed, by which
time we knew a lot of other parts of C++ pretty well. For somebody
starting today, those parts should (IMO) be learned right from the
beginning right along with the other parts of the language.

I ask because at every
job I've had, and every job interview for that matter, whenever
STL comes up it's not I, but a manager who says effectively
yuck, we don't use that crap.

To which I say good, I never learned that crap.

So you're an igorant programmer who gravitates toward ignorant
companies. What of it?

[ ... ]

Google clearly has stacked their contest against C++ programmers,
which means that it is not about "top coders" after all.

Nonsense. Learning all the major parts of a language is the bare
minimum requirement before anybody can even aspire to becoming a top
coder in that language.

Right now, you've chosen (through what sounds like sheer laziness) to
remain ignorant of a significant part of a language. You are, however,
apparently not satisified with remaining ignorant yourself, and now
ask that the rest of the world remain (or act as it if has remained)
ignorant as well.

Laziness can be a useful trait in a programmer -- in fact, probably a
nearly necessary one. To be useful, however, it has to be
intelligently applied: if you ever even hope to become a "top coder"
(or even just a fairly decent one) you need to learn to think in the
longer term, being willing to put some extra effort into learning new
things now because they'll save you work in the long run.

Likewise with arrogance: a programmer has to be arrogant enough to
believe he can solve problems that others have tried and failed. He
has to be arrogant enough to be certain he can learn something, even
when he runs into long, nearly incomprehensible error messages -- or
worse, no error messages at all, but code that doesn't do what it's
supposed to. In many cases, people seem to become good programmers
largely because having decided to do so, they were simply too proud
and arrogant to ever admit defeat. Becoming a top coder requires (at
least) two things in large quantities: curiousity that drives you to
learn about new things, and tenacity that keeps you from quitting
until you've really learned them -- and if that tenacity derives from
arrogance, so be it.

If you know enough C++ to write programs that make you and/or your
boss happy, more power to you -- but until you learn the rest of the
language, you won't be a top coder, and asking Google (or anybody
else) to act as if it were otherwise is simply foolish.

 

[assaarpa]

All of this is secondary, though: the restrictions that, you feel, make

the STL "useless" are not restricted to the C++ standard library. As has
been pointed out repeatedly, you'll have the same problem with any code
under Windows that allocates memory in one heap and tries to free it while
using a different heap. The C++ standard library happens to do a lot of
memory management, as a consequence of containing a lot of container
classes.

In short, fix your environment.

The language and the library work fine.

In that case I am not very impressed by the language or the library. I think
the definition of "working fine" is what what we don't agree on. Your
definition is that if it is supposed to work, but doesn't, everything is
fine. Mine is the opinion that when I write portable code, I expect it to
work on all weathers and doesn't rely on horoscope.

You ARE right: the environment is bent. But in the real world developers job
is to write applications for Windows, we must take this reality into
consideration when we say that code is reusable and portable. This is
general programming vs. c++ pedantism ("if it is correct according to the
standard it is portable" -- while the reality doesn't agree with that
assesment at all!

Since this is comp.lang.c++, it is easier to Yield to the Ivory Tower
idealistic view of the world, even if the reality disagrees. In practical
level, however, I will NEVER write code that is correct ONLY according to
the Standard document but also I know myself that it works on all of the
platforms I am compiling the sourcecode FOR -- THAT is conflict with your
view of what is correct and what is not. Afteral, the goal is NOT to write
software or code that works in THEORY on all platforms, but fails on
platforms we NEED it to work.

Yet you suggest that I don't "grasp" what you are saying, no, you are wrong
at all levels. I do, unfortunately, it would be easier to be ignorant of the
whole issue but not very professional.

Thank you.

 

[Paul]

The exact point at which you "picked it up" is more or less
irrelevant. For some of us living fossils, learning about the
containers, iterators, etc. had to wait until they existed, by which
time we knew a lot of other parts of C++ pretty well. For somebody
starting today, those parts should (IMO) be learned right from the
beginning right along with the other parts of the language.

I disagree. I think learning STL is more difficult than learning C++.
What with traits and policies etc, I think this is best left to
specialists.

So you're an igorant programmer who gravitates toward ignorant
companies. What of it?

I don't think he is ignorant, I find his POV quite interesting and I
believe he is speaking with a true sense of reality.

[ ... ]

Google clearly has stacked their contest against C++ programmers,
which means that it is not about "top coders" after all.

Nonsense. Learning all the major parts of a language is the bare
minimum requirement before anybody can even aspire to becoming a top
coder in that language.

STL should be a standard extension to the language and not an integral
part of the language.
Templates is the part of the language we need to acknowledge here.

Right now, you've chosen (through what sounds like sheer laziness) to
remain ignorant of a significant part of a language. You are, however,
apparently not satisified with remaining ignorant yourself, and now
ask that the rest of the world remain (or act as it if has remained)
ignorant as well.

I consider arrays to be a more significant part of the language than
vectors, plenty around here disagree , you seem to be one of the STL
fans.
I definately look upon STL and 'the language' as 2 different things,
as the OP seems to do.
Your leaning heavilly on this 'ignorance' thing you've made up here, I
think your out of order. I'm not ignorant.

Laziness can be a useful trait in a programmer -- in fact, probably a
nearly necessary one. To be useful, however, it has to be
intelligently applied: if you ever even hope to become a "top coder"
(or even just a fairly decent one) you need to learn to think in the
longer term, being willing to put some extra effort into learning new
things now because they'll save you work in the long run.

After calling the guy lazy and ignorant, what makes you think you have
the right to preech about what does or doesn't make a good programmer?

Likewise with arrogance: a programmer has to be arrogant enough to
believe he can solve problems that others have tried and failed. He
has to be arrogant enough to be certain he can learn something, even
when he runs into long, nearly incomprehensible error messages -- or
worse, no error messages at all, but code that doesn't do what it's
supposed to. In many cases, people seem to become good programmers
largely because having decided to do so, they were simply too proud
and arrogant to ever admit defeat. Becoming a top coder requires (at
least) two things in large quantities: curiousity that drives you to
learn about new things, and tenacity that keeps you from quitting
until you've really learned them -- and if that tenacity derives from
arrogance, so be it.

What happened to creativity?
You do not seem to understand 'The will to succeed' and what drives
women/men, it certainly doesn't derive from arrogance.

If you know enough C++ to write programs that make you and/or your
boss happy, more power to you -- but until you learn the rest of the
language, you won't be a top coder, and asking Google (or anybody
else) to act as if it were otherwise is simply foolish.

Paul.

 

[Arthur J. O'Dwyer]

(e-mail address removed) (Jerry Coffin) wrote...

(e-mail address removed) (ziliath) wrote...

I recently tried out the Google "top coder" contest, as a C++
coder. I noticed immediately that they expected me to know STL.
To which I say, what the f***?!

I may be missing something, but at what point when learning C++
was I supposed to have picked up STL?

[...] For somebody starting today, those parts should (IMO) be learned
right from the beginning right along with the other parts of the language.

I disagree. I think learning STL is more difficult than learning C++.
What with traits and policies etc, I think this is best left to
specialists.

Nope. It's very hard to write high-level C++ code without std::vector,
std::map, and/or std::list. Believe me, I've tried. "Traits" and
"policies" (???) may be things to leave to the specialists, but the STL
definitely isn't. Ditto any other standard library for any other
language. You can't "know" C without knowing the standard headers.
You can't "know" Java, or SML, or OCaml, without knowing the standard
libraries for those languages. In fact, I can't think of a single modern
language that doesn't come with a large library codebase---the only
no-frills languages coming to mind are APL, Pascal, and BASIC, and
I'm not even sure about Pascal.

Right now, you've chosen (through what sounds like sheer laziness) to
remain ignorant of a significant part of a language. You are, however,
apparently not satisfied with remaining ignorant yourself, and now
ask that the rest of the world remain (or act as it if has remained)
ignorant as well.

I consider arrays to be a more significant part of the language than
vectors[;] plenty around here disagree[;] you seem to be one of the STL
fans. I definitely look upon STL and 'the language' as 2 different
things, as the OP seems to do.

Well, you're trivially wrong. The standard C++ library /is/ part
of C++, and the template classes are part of the standard C++ library.

Your leaning heavilly on this 'ignorance' thing you've made up here, I
think your out of order. I'm not ignorant.

Ignorant of the difference between "your" and "you're", certainly. :-/

After calling the guy lazy and ignorant, what makes you think you have
the right to [preach] about what does or doesn't make a good programmer?

The First Amendment. Seriously, though, Jerry is absolutely on
the right track. The idea isn't original with him, either.
http://c2.com/cgi/wiki?LazinessImpatienceHubris

What happened to creativity?
You do not seem to understand 'The will to succeed' and what drives
women/men, it certainly doesn't derive from arrogance.

Oh, what, like /you/ know what drives people to succeed? (I bet
it's irony. It is irony, isn't it?)

Seconded.

-Arthur

 

[Greg Comeau]

I disagree. I think learning STL is more difficult than learning C++.
What with traits and policies etc, I think this is best left to
specialists.

Not sure if we have equal meaning of "STL", but if you mean that
learning the whole C++ Standard Library is not easy, involves
lots of info, is even complex in areas, etc, then I doubt you'd
find many people to disagree with you. But saying users of the
C++ SL (or even just those of the so-called STL part) should only
be left to specialists seems to be an overstatement.
If novices of C++ can use the core language of C++ (as novices),
then they surely can user its standard library (as novices).
And so one for those between the extremes. We also need to
acknowledge that not every programmer should be responsible
for every aspect of every program, and that often even that
whole mentality is a mistake (I'm not saying you're offering
that mentality, just speaking further on the issue).

 

[Edd]

Not sure if we have equal meaning of "STL", but if you mean that
learning the whole C++ Standard Library is not easy, involves
lots of info, is even complex in areas, etc, then I doubt you'd
find many people to disagree with you. But saying users of the
C++ SL (or even just those of the so-called STL part) should only
be left to specialists seems to be an overstatement.

To add some weight to this argument (for what it's worth): I've only been
using C++ for about a month, but STL containers and algorithms find their
way into almost every bit of code I write. I'm glad they're there. Of
course, I don't know the whole of STL or it's intricacies yet, but I can say
that there's no reason (in my mind at least) that newbies shouldn't learn it
from the start. It's just too useful, even at a basic level.

Edd

 

[Paul]

Let's assume you are correct, and that the STL is crap.
Given that, let me ask you then:

I also think the STL should not be considered part of the language so
let me answer them.

1) Define what you mean by STL? (Just to be sure that when you
say STL we're talking about the same thing)

Standard Template Library (speaks for itself)

2) What do you use when you want a linked list?

A linked list. Either pre written or written specifically for the
project.

3) What do you use when you want to sort something?

Well it depends what you want to sort and how you want to sort it.
If there are no appropriate sorting algorithms in whatever library you
happen to be using then you write one, that's why your a programmer.

4) What do you do when you want to have a linked list
of ints and a linked list of strings?

You have two linked lists, if possible to use templits feel free to do
so.

5) What do you do when you want these same things across projects?
Across companies?

Do the same as you did the last time, additionally, if code is
portable to the new project then use it.

6) I find it hard to believe that these are conceptually foreign
questions for a C++ programmer to have to be concerned about,
so since the STL is crap, what do you do that is so much better?

Let me clear up some facts:
You cannot effectively program a computer without first understanding
the computer system you are going to program, this newsgroup tries
very hard to keep away from implementation specifics, but it's always
gonna crop up.
The OP was discussing portability issues with dll's. A dll is a piece
of software so this is a software portability issue, not source code
portability.
The problem with STL is that it uses compile time computing and as all
templates are deduced at compile time they are not always goin to be
suitable.

Some people are falsely misled into thinking they can write source
code which is portable to any computer system, they call this portable
code. This is a completely ludicrous idea. Software is not portable,
the word portable does not really belong in computer software
development. However in the area of dll's and other areas the word
portable does fit a little.
So there is a division between those who think portability means
a) Portable Software
b) Portable source code.

As I already explained I think the idea of portable source code is
astoundingly stupid. And I choose option a).

So who conceived this stupid idea of portable source code?
Let me explain:
It's a big marketting gimmick. It's a "buzz word".
Punters think portable code is great because they don't have to
understand how the processors and underlying systems work. So how many
billions have been made from the standardisation of C++? Who profits?
a) standardisation comittee
b) market leaders in development software.
c) governments
d) other small subsiduary sofware developers

So everyone gains,cool.
Now going back to before STL was part of the standard what would be
the benefits of including STL in the language?
a) more work therefore more money for all of the above.

what are the pitfalls?
a) none of the above give a **** they've got more money


And that's how it seems to be going. Do you think they care about
technical correctness? lol perhaps some do but they probably care more
about their bank accounts.

Paul.

 

[Greg Comeau]

I also think the STL should not be considered part of the language so
let me answer them.

Standard Template Library (speaks for itself)

Then define what you mean by Standard Template Library.
Different people *do* have different definitions for what it is,
though they often overlap.

A linked list. Either pre written or written specifically for the
project.

"STL" provides a pre-written linked list.
So STL would appear to be one approach to satify your response.

Well it depends what you want to sort and how you want to sort it.
If there are no appropriate sorting algorithms in whatever library you
happen to be using then you write one, that's why your a programmer.

"STL" is a library which can provide an appropriate sorting algorithm
in many cases. So again, STL would appear to be one approach to satify
your response.

You have two linked lists, if possible to use templits feel free to do
so.

"STL" does provide a linked list template.
So again, STL would appear to be one approach to satify such a possibility.

Do the same as you did the last time,

Which may be that you used "STL".

additionally, if code is
portable to the new project then use it.

Which may mean you're using "STL".

Let me clear up some facts:
You cannot effectively program a computer without first understanding
the computer system you are going to program, this newsgroup tries
very hard to keep away from implementation specifics, but it's always
gonna crop up.

Completely ignoring platform specifics surely has problems.
But so does only considering the platform. As always, a balance
must be struck. Using the STL is one way to do so. As with
any compromise, there will be pros and cons, misuses, and places
where it doesn't work.

The OP was discussing portability issues with dll's. A dll is a piece
of software so this is a software portability issue, not source code
portability.
The problem with STL is that it uses compile time computing and as all
templates are deduced at compile time they are not always goin to be
suitable.

Some people are falsely misled into thinking they can write source
code which is portable to any computer system, they call this portable
code. This is a completely ludicrous idea. Software is not portable,
the word portable does not really belong in computer software
development. However in the area of dll's and other areas the word
portable does fit a little.
So there is a division between those who think portability means
a) Portable Software
b) Portable source code.

As I already explained I think the idea of portable source code is
astoundingly stupid. And I choose option a).

I prefer to be open minded, and hence prefer to think that
portabilty can apply to many areas. And I agree that 100%
portability can sometimes be hard to achieve, even with option a,
whatever it means. As with the compromises mentioned above,
instead of dealing with perfection, I prefer to think we're
dealing with something relative, since it too will have its
pros and cons, etc. Same things can be said of efficiency
and many other things. So to me, whatever it is that we're
talking about that can be portable, we wanna strive for it
the right dynamics of adapability, extensibililty, design,
API, etc etc. realizing there will be cases where it might break,
need an alternative, whatever.

So who conceived this stupid idea of portable source code?
Let me explain:
It's a big marketting gimmick. It's a "buzz word".
Punters think portable code is great because they don't have to
understand how the processors and underlying systems work. So how many
billions have been made from the standardisation of C++? Who profits?
a) standardisation comittee
b) market leaders in development software.
c) governments
d) other small subsiduary sofware developers

So everyone gains,cool.

If that's right, then that's great.

Now going back to before STL was part of the standard what would be
the benefits of including STL in the language?
a) more work therefore more money for all of the above.

what are the pitfalls?
a) none of the above give a **** they've got more money

If I understand you, this is circularly illogical,
because if it's so, then whether STL exists or not,
there have always been people touting portability,
and if it's this big conspiracy you're point out,
then it's always been, is now, and will always be,
so whoever is winning continue to win and whoever is
loosing continues to loose.

And that's how it seems to be going. Do you think they care about
technical correctness? lol perhaps some do but they probably care more
about their bank accounts.

If this is true, then it's still true whether STL exists or not.

 

[Tabrez Iqbal]

In that case I am not very impressed by the language or the library. I think
the definition of "working fine" is what what we don't agree on. Your
definition is that if it is supposed to work, but doesn't, everything is
fine. Mine is the opinion that when I write portable code, I expect it to
work on all weathers and doesn't rely on horoscope.

give me one example which "works on all weathers".

You ARE right: the environment is bent. But in the real world developers job
is to write applications for Windows, we must take this reality into
consideration when we say that code is reusable and portable. This is
general programming vs. c++ pedantism ("if it is correct according to the
standard it is portable" -- while the reality doesn't agree with that
assesment at all!

Since this is comp.lang.c++, it is easier to Yield to the Ivory Tower
idealistic view of the world, even if the reality disagrees. In practical
level, however, I will NEVER write code that is correct ONLY according to
the Standard document but also I know myself that it works on all of the
platforms I am compiling the sourcecode FOR -- THAT is conflict with your
view of what is correct and what is not. Afteral, the goal is NOT to write
software or code that works in THEORY on all platforms, but fails on
platforms we NEED it to work.

Yet you suggest that I don't "grasp" what you are saying, no, you are wrong
at all levels. I do, unfortunately, it would be easier to be ignorant of the
whole issue but not very professional.

Thank you.

tabrez

 

[Jyrki Alakuijala]

#undef add
#undef a
#undef b

#undef int

You never know if int has been redefined into something
that does not have operator + or even a public constructor.

#undef return

Return might have been defined into something else if
a comity of PHBs has decided that it is not good to
return values.

 

[Tabrez Iqbal]

Ignorant of the difference between "your" and "you're", certainly. :-/

perhaps not every one on the group is a native speaker of English?

[snip]

tabrez

 

[assaarpa]

give me one example which "works on all weathers".

It would be more practical to give examples of what don't, but I shall humor
your strange request.

int add(int a, int b)
{
return a + b;
}

Oops! This cannot be guaranteed to work, someone might have..

#define add +

... somewhere! Seems I cannot guarantee shit and neither can you or anyone
else, unless you can hand-pick every library and every line of code that
goes into the software you are developing. Good luck with that in the real
world.

 

[assaarpa]

The realy irony is that the irony is lost on me, too.

I will explain. He wrote, quote:

"You think just because something is valid code it will do what you want it
to???"

After I just exhaustively explained that code can be valid according to the
standard, and fail, so much for portability. He said same thing as I did, in
different words, as argument against what I have written earlier. That is
the irony. It was lost on you, okay, fine.

 

[Paul Mensonides]

It would be more practical to give examples of what don't, but I shall humor
your strange request.

int add(int a, int b)
{
return a + b;
}

Oops! This cannot be guaranteed to work, someone might have..

#define add +

#undef add
#undef a
#undef b

int add(int a, int b)
{
return a + b;
}

Regards,
Paul Mensonides

 

[Paul Mensonides]

#undef int

You never know if int has been redefined into something
that does not have operator + or even a public constructor.

Yes, I forgot those. However, the translation unit cannot include any standard
headers if either 'int' or 'return' is defined and still be well-formed. In any
case, it's irrelevant. A program is a collection of code that is together
well-formed. You cannot take independent pieces and pretend that they have no
effect on the system as a whole or that the system as a whole does not have an
effect on individual pieces. This is the case in any language.

// snippet #1
extern int a;

// snippet #2
extern double a;

Both snippets are fine until they are combined--at which point the system
breaks.

The original problem is rooted in multiple definitions of standard library
functions introduced by the environment when compiling with the wrong
options--which is a violation of the ODR and is instantly non-portable.

Regards,
Paul Mensonides

 

[Owen Jacobson]

It would be more practical to give examples of what don't, but I shall humor
your strange request.

int add(int a, int b)
{
return a + b;
}

Oops! This cannot be guaranteed to work, someone might have..

...passed values such that the sum of them is larger than the most-positive
integer that can be stored in an int. Signed overflow is undefined.