By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,835 Members | 1,454 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,835 IT Pros & Developers. It's quick & easy.

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

P: n/a
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 fuck?!

I may be missing something, but at what point when learning C++
was I supposed to have picked up STL? 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.

Not that I haven't tried using it. The error messages that any
newbie-to-STL is bound to get were 100+ lines long. Really useful!

Google clearly has stacked their contest against C++ programmers,
which means that it is not about "top coders" after all.
Jul 22 '05 #1
Share this Question
Share on Google+
87 Replies


P: n/a
who
The STL is part of the standard C++ language right? Then that's part of C++
isn't it? So, if an exam of some type contains a series of questions
regarding C++ programming it will have questions relating to the language
right?

The STL is taught at any introductory university course on C++ programming.
Pickup an introductory C++ book these days and you'll be hard pressed to
find one without details of it. It greatly simpilfies certain things in the
language, but can be complex to some beginners. I'd rather be coding apps
and libraries using the STL rather than reimplementing a hell of a lot of
code that it already offers. It's not difficult to understand the basics.

There are many companies where programmers use the STL, just because you
haven't worked in one doesn't mean that they don't exist - right? =:-)

Regards,

M
Jul 22 '05 #2

P: n/a
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 fuck?!

I may be missing something, but at what point when learning C++
was I supposed to have picked up STL? 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.

Not that I haven't tried using it. The error messages that any
newbie-to-STL is bound to get were 100+ lines long. Really useful!

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


The standard library included with any language is as valuable as the
language itself. You can say that the C library is not technically part
of the C language, so you needn't learn all that printf stuff, but you'd
just be fooling yourself.

I've learned to love the STL, and I use it occasionally, when the
appropriate opportunity arises. But if you never learn it, you'd never
know when it'll come in handy!
Jul 22 '05 #3

P: n/a

"ziliath" <zi*****@myway.com> wrote in message
news:6b**************************@posting.google.c om...

[snip]


Most C++ programmers know the STL. The contest is not stacked against C++
programmers (as your misleading title says), but against any programmer that
does not know the basics of the system library of the language they will be
using.

The probable reason for this is that you are not allowed to include any
nonstandard headers. Should you be surprised? With non-standard headers,
you can gain an advantage that others don't have. To prevent this, they
level the playing field. You can try it without the STL, but good luck on
actually doing anything productive. How are you even going to get input
from the user?

James
Jul 22 '05 #4

P: n/a

"ziliath" <zi*****@myway.com> wrote in message
news:6b**************************@posting.google.c om...
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 fuck?!
I don't get it .... OH! you mean WTF. I've never seen it spelled out fully.
I may be missing something, but at what point when learning C++
was I supposed to have picked up STL? 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.

Not that I haven't tried using it. The error messages that any
newbie-to-STL is bound to get were 100+ lines long. Really useful!


I guess you don't care about extensibility, reusability or genericity, and
neither do any of your managers. Maybe you should get a new job.

Jonathan
Jul 22 '05 #5

P: n/a
"ziliath" <zi*****@myway.com> wrote in message
news:6b**************************@posting.google.c om...
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 fuck?!
Er, why? The STL is a part of C++.
I may be missing something, but at what point when learning C++
was I supposed to have picked up STL?
Preferably in Lesson 1.
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.
That's a bit difficult to understand, since the STL makes it very easy to do
many useful things. Perhaps those managers would have been more truthful if
they'd said, "We could never be bothered learning that crap, so we really
wouldn't have a clue if it's crap or not." I suggest that the most competent
C++ programmers would be less than impressed with such an attitude from a
manager, and look elsewhere. Besides, you should never let managers near
your code. :-)
To which I say good, I never learned that crap.
Then you missed a very important part of C++ when you learned it.
Not that I haven't tried using it. The error messages that any
newbie-to-STL is bound to get were 100+ lines long. Really useful!
Yes, error message technology has fallen behind compiler technology, but
with a bit of experimentation you can usually figure out what's wrong.
Google clearly has stacked their contest against C++ programmers,
which means that it is not about "top coders" after all.


Sounds to me like they've stacked their contest in _favour_ of C++
programmers.

DW

Jul 22 '05 #6

P: n/a
> I guess you don't care about extensibility, reusability or genericity, and
neither do any of your managers. Maybe you should get a new job.


A common misconception.

First, I acknowledge that the c++ does not know about dll's or Windows - but
the Real World does! Use std containers to pass objects across dll
boundaries and you crash and burn so beautifully.

The work around is not to pass std containers across dll boundaries, and
guess what? That means the reusability and genericity is thrown right out
the door, you cannot just take c++ code someone written using std containers
and plug it in (=reuse). Nope. What you have to do is fix this c++ God's
mistakes and with that HE had taken that new job..
Jul 22 '05 #7

P: n/a

"assaarpa" <re***********@fap.net> wrote in message
news:ci**********@phys-news1.kolumbus.fi...
I guess you don't care about extensibility, reusability or genericity, and
neither do any of your managers. Maybe you should get a new job.


A common misconception.

First, I acknowledge that the c++ does not know about dll's or Windows - but
the Real World does! Use std containers to pass objects across dll
boundaries and you crash and burn so beautifully.


Passing objects between dll's is a general problem which doesn't have anything
to do with STL.

Jonathan
Jul 22 '05 #8

P: n/a
"assaarpa" <re***********@fap.net> wrote in message
news:ci**********@phys-news1.kolumbus.fi...
I guess you don't care about extensibility, reusability or genericity, and neither do any of your managers. Maybe you should get a new job.
A common misconception.

First, I acknowledge that the c++ does not know about dll's or Windows -

but the Real World does! Use std containers to pass objects across dll
boundaries and you crash and burn so beautifully.

The work around is not to pass std containers across dll boundaries, and
guess what? That means the reusability and genericity is thrown right out
the door, you cannot just take c++ code someone written using std containers and plug it in (=reuse). Nope. What you have to do is fix this c++ God's
mistakes and with that HE had taken that new job..

<snip>

First, let me point out that DLLs are platform-specific and off-topic. Now,
having said that, I doubt that standard containers cause a huge headache
when it comes to DLL boundaries. In the worst case (which I guess happens
when a container cannot be passed across any interface for some odd reason),
I would expect that there might be a need to convert the container into
another type and then later convert it back into the container. That means
that you have to write a function that transforms the container into
something like an array or a linked list, and then you have to write a
function that transforms it back. That's no big deal. Granted, if there is
an issue, it helps to be aware of it before encountering it, but that's true
of any problem. I don't think that means that reusability is "thrown right
out the door."

--
David Hilsee
Jul 22 '05 #9

P: n/a
"ziliath" <zi*****@myway.com> wrote in message
news:6b**************************@posting.google.c om...
| 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 fuck?!

after all, this must be the biggest breakthrough in programming of the
previsous decade.

| I may be missing something, but at what point when learning C++
| was I supposed to have picked up STL? 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.

clearly someone who didn't learned it either.

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

he he, bad for you. If you can't even use std::sort(), I guess you're in
truoble.

| Not that I haven't tried using it. The error messages that any
| newbie-to-STL is bound to get were 100+ lines long. Really useful!

This is often a mixture of compiler QoI and STL implementation. You also
want to use an IDE that jumps to the line where the error is detected. And
then
you might want to check out STLfilt: http://www.bdsoft.com/tools/stlfilt.html

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

most programmers learn both languages and quickly discovers that Java is for
toy programs.

br

Thorsten
Jul 22 '05 #10

P: n/a
zi*****@myway.com (ziliath) wrote in message news:<6b**************************@posting.google. com>...
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 fuck?!

I may be missing something, but at what point when learning C++
was I supposed to have picked up STL? 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.

Not that I haven't tried using it. The error messages that any
newbie-to-STL is bound to get were 100+ lines long. Really useful!

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


i don't think STL part of the Standard C++ is such a beast which
should be avoided as long as possible. In fact you are much better
startinf using it from your very first programs. Look what Stroustrup
suggests as a sample program:

http://www.research.att.com/~bs/bs_f...simple-program

it uses both containers and algorithms.

the people who say that they never learned the "crap" are using a very
outdated version of C++ and run the risk of soon becoming "out-dated"
themselves. You better follow other examples. I wonder which book(s)
you followed while learning C++.

tabrez
Jul 22 '05 #11

P: n/a
ziliath posted:
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 fuck?!

I may be missing something, but at what point when learning C++ was I supposed to have picked up STL? 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.

Not that I haven't tried using it. The error messages that any newbie-to-STL is bound to get were 100+ lines long. Really useful!
Google clearly has stacked their contest against C++ programmers, which means that it is not about "top coders" after all.


The STL is dead handy.

Would you prefer spending an hour or so messing with
strings, or just do:

std::string blah = "hello" + something + " -" + otherstuff;

I always use the STL in conjunction with Win32API.

When I'm done messing with the string I simply:

FindFirstFileEx( blah.c_str() );
-JKop
Jul 22 '05 #12

P: n/a
The STL is dead handy.

Would you prefer spending an hour or so messing with
strings, or just do:

std::string blah = "hello" + something + " -" + otherstuff;

I always use the STL in conjunction with Win32API.

When I'm done messing with the string I simply:

FindFirstFileEx( blah.c_str() );


Unfortunately I jumped into C++ programming using MFC. Now my code is
full of CArray, CString and CFile. Great, MS. Now I have to rewrite
piece by piece if I want to have it portable one day. Did you know
that none of the MFC container classes has an = operator? It was the
worst idea not to use STL by MS, and I got trapped. Don't do the same.
Use the STL, it's really really a great thing.
Jul 22 '05 #13

P: n/a
zi*****@myway.com (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 fuck?!
You seem to be a bit out of touch. This is akin to saying
"I went for a programming interview for a C job and they
expected me to know pointers. What the fuck?"
I may be missing something, but at what point when learning C++
was I supposed to have picked up STL?
The first day, I would hope.
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.
The 1980s called, they want their C-with-classes back.
Not that I haven't tried using it. The error messages that any
newbie-to-STL is bound to get were 100+ lines long. Really useful!


A poor workman blames his tools. Why don't you try learning
from a book or a tutor, rather than "trial-and-error" self-teaching?
How about if I said that foreign (spoken) languages were stupid
because when I try them out I get error messages I can't understand?
Jul 22 '05 #14

P: n/a
Gernot Frisch wrote:
Unfortunately I jumped into C++ programming using MFC. Now my code is
full of CArray, CString and CFile. Great, MS. Now I have to rewrite
piece by piece if I want to have it portable one day. Did you know
that none of the MFC container classes has an = operator? It was the
worst idea not to use STL by MS, and I got trapped.
MFC is older than the STL. When the first version of MFC was released
there was no standard library and at the time it had to be compiled on
compilers that supported little more than "C with classes". Visual C++
1.0 had no support for templates, exceptions, RTTI...etc, in fact it had
little in common with what we today consider to be C++. If you turn the
clock twelve years back, many of the choices the MFC developers made are
understandable. But from todays point of view MFC is a load of obsolete
crap.
Don't do the same.
Use the STL, it's really really a great thing.


Agreed, having been in a situation where I couldn't use the standard
library and having been forced to use alternatives solutions I can tell
that the standard library (often) makes life so much easier and more
productive.

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl
Jul 22 '05 #15

P: n/a
In article <PB******************@news-server.bigpond.net.au>, who
<so*****@somewhere.com> writes
There are many companies where programmers use the STL, just because you
haven't worked in one doesn't mean that they don't exist - right? =:-)


And with the attitude he has, he is unlikely to work for a company that
uses the Standard C++ Library.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Jul 22 '05 #16

P: n/a

"Gernot Frisch" <Me@Privacy.net> wrote in message news:2q*************@uni-berlin.de...
[snip]
Use and enjoy the STL, it's really really a great thing.


[snip]

--
Alex Vinokur
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn


Jul 22 '05 #17

P: n/a
> First, let me point out that DLLs are platform-specific and off-topic.
Now,

<snip> Let me remind that saying that someone should get a new job, because
he works in the real world and not the fantasy world here, is also
off-topic. Nuff said.

that you have to write a function that transforms the container into
something like an array or a linked list, and then you have to write a
function that transforms it back. That's no big deal. Granted, if there is an issue, it helps to be aware of it before encountering it, but that's true of any problem. I don't think that means that reusability is "thrown right out the door."


Yes, it is.

std::string foo();

If you call that method across dll boundary, you crash and burn. Bye bye
reusability. QED.
Jul 22 '05 #18

P: n/a
> Passing objects between dll's is a general problem which doesn't have
anything
to do with STL.


If you write "reusable" code with STL, it won't be reusable in that domain
but will crash and if you don't know your trade but just blindly trust the
STL to work correctly (hey, according to the standard it is valid code) it
WILL fail, so much for reusability. This means you cannot just take code
some top gun c++ programmer wrote and reuse it. Something the standard
library just isn't very good for, sorry to break the news but it isn't
perfect for everything.
Jul 22 '05 #19

P: n/a
assaarpa wrote:
of any problem. I don't think that means that reusability is "thrown
right out the door."


Yes, it is.

std::string foo();

If you call that method across dll boundary, you crash and burn. Bye bye
reusability. QED.


Funny, I'm working large scale project which does exactly that, and a
lot. It doesn't crash and burn. But I admit you do have know what you
are doing (or to be more precise what happens under the hood) to get it
right.

Anyway this problem is not related to the STL. Passing C++ objects
(including homebrew ones) across DLL boundaries is always tricky
business. And if you compile the .exe and .dll with different compilers
you can forget it, because there is no standardized ABI for C++.

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl
Jul 22 '05 #20

P: n/a
In message <ci**********@phys-news1.kolumbus.fi>, assaarpa
<re***********@fap.net> writes
First, let me point out that DLLs are platform-specific and off-topic.

Now,

<snip> Let me remind that saying that someone should get a new job, because
he works in the real world and not the fantasy world here, is also
off-topic. Nuff said.

that you have to write a function that transforms the container into
something like an array or a linked list, and then you have to write a
function that transforms it back. That's no big deal. Granted, if there

is
an issue, it helps to be aware of it before encountering it, but that's

true
of any problem. I don't think that means that reusability is "thrown

right
out the door."


Yes, it is.

std::string foo();

If you call that method
across dll boundary, you crash and burn. Bye bye
reusability. QED.

Post a real, complete, example.

I routinely pass std::strings and STL iterators across DLL boundaries
with no problems whatsoever. You must be doing something wrong.

--
Richard Herring
Jul 22 '05 #21

P: n/a
> First, I acknowledge that the c++ does not know about dll's or Windows - but
the Real World does! Use std containers to pass objects across dll
boundaries and you crash and burn so beautifully.


Can't you wrap it in a type that can pass accross the boundary safely?

STL is pretty straightforward I think and similar to concepts of many
languages. String type, stacks, maps, blah, blah, blah.
Jul 22 '05 #22

P: n/a
On Thu, 16 Sep 2004 17:32:34 +0300, "assaarpa" <re***********@fap.net>
wrote:
Yes, it is.

std::string foo();

If you call that method across dll boundary, you crash and burn. Bye bye
reusability. QED.


Apparently you don't know how to use your compiler. Try searching
msdn. (hint: DLL versions of C runtime libraries).

N.B. the same problem you are seeing applies to this as well:

char* foo();

char* s = foo(); //foo in DLL allocates using new[].
delete[] s; //boom, heaps in DLL and .exe are different.

Tom
Jul 22 '05 #23

P: n/a
"who" <so*****@somewhere.com> wrote in message
There are many companies where programmers use the STL, just because you
haven't worked in one doesn't mean that they don't exist


Certainly.

I suppose the problem is that I learned C++ mainly by self-teaching
back when STL was unheard of, i.e. when C++ first appeared, and didn't use C++
since until I began coding for Windows. In the Windows world there may be
a distaste for STL. Anyway I will take a look at it.
Jul 22 '05 #24

P: n/a

"assaarpa" <re***********@fap.net> wrote in message
news:ci**********@phys-news1.kolumbus.fi...
Passing objects between dll's is a general problem which doesn't have anything
to do with STL.


If you write "reusable" code with STL, it won't be reusable in that domain
but will crash and if you don't know your trade but just blindly trust the
STL to work correctly (hey, according to the standard it is valid code)


You think just because something is valid code it will do what you want it to???
it
WILL fail, so much for reusability. This means you cannot just take code
some top gun c++ programmer wrote and reuse it.
You have to know what your doing.
Something the standard
library just isn't very good for, sorry to break the news but it isn't
perfect for everything.


I'm not sure it's perfect for anything. But it's excellent for many things and
pretty good for a lot more.

Jonathan
Jul 22 '05 #25

P: n/a
In article <6b**************************@posting.google.com >,
ziliath <zi*****@myway.com> 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 fuck?!

I may be missing something, but at what point when learning C++
was I supposed to have picked up STL? 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.

Not that I haven't tried using it. The error messages that any
newbie-to-STL is bound to get were 100+ lines long. Really useful!

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


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

1) Define what you mean by STL? (Just to be sure that when you
say STL we're talking about the same thing)
2) What do you use when you want a linked list?
3) What do you use when you want to sort something?
4) What do you do when you want to have a linked list
of ints and a linked list of strings?
5) What do you do when you want these same things across projects?
Across companies?
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?
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Jul 22 '05 #26

P: n/a
In article <6b**************************@posting.google.com >,
ziliath <zi*****@myway.com> wrote:
"who" <so*****@somewhere.com> wrote in message
There are many companies where programmers use the STL, just because you
haven't worked in one doesn't mean that they don't exist


Certainly.

I suppose the problem is that I learned C++ mainly by self-teaching
back when STL was unheard of, i.e. when C++ first appeared, and didn't use C++
since until I began coding for Windows. In the Windows world there may be
a distaste for STL. Anyway I will take a look at it.


Which probably means that you used pre-templates C++,
used proprietary versions of similar stuff, put
it together yourself, just winged it, etc. Not that that
means it was no good, but with advances in C++ like
templates, it's hard to see how what the various parts
of the C++ Standard Library contains can be considered
not useful. Perfection is often hard to reach, and as with
many things it's not always appropriate, so nobody is saying
to the contrary. But it does usually strike a reasonable
compromise for a general purpose library and as building blocks.
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Jul 22 '05 #27

P: n/a
> I routinely pass std::strings and STL iterators across DLL boundaries

The credibility goes down the toiler the moment you mention STL iterator and
passing them across DLL boundaries.
with no problems whatsoever. You must be doing something wrong.


You have no clue what I am talking about have you? You know what a heap is?
You know what happens when memory allocated in one heap using
new/new[]/malloc is freed using a matching delete/delete[]/free in another
heap? You realize that std::string has optimization in many implementations,
including latest Dinkumware one, where short strings use memory allocated
like this for storage:

charT m_storage[30];

Where 30 is just example what the size might be, in this case heap is not
used to allocate memory for the string, and yes, it will work. Try longer
strings and pass objects are return values across DLL boundaries. You
realize that what you are doing *can* work, but *can* also fail. It's
gambling at best, not good programming practise. Thanks for sharing your
insight with us.
Jul 22 '05 #28

P: n/a
> Apparently you don't know how to use your compiler. Try searching
msdn. (hint: DLL versions of C runtime libraries).
Apparently you think you do, if you refer to multi-threaded runtime
libraries, no dice, that addresses similiar, but not closely related to,
issue. A good try.
char* s = foo(); //foo in DLL allocates using new[].
delete[] s; //boom, heaps in DLL and .exe are different.


Yes. And there is a very easy solution that remedies the situation quite
nicely, but if thinking that passing std::string's around is sound practise
I would disagree all the difference that makes!
Jul 22 '05 #29

P: n/a
> You think just because something is valid code it will do what you want it
to???

No, and that is supposed to be _my_ case. As I was saying, so much for
reusability.
You have to know what your doing.
There is no substitute (such as "STL does it for U") for being competent,
agreed.
I'm not sure it's perfect for anything. But it's excellent for many things and pretty good for a lot more.


One of the reasons why I use it, too, but atleast I am not yet delusional to
think that it is "re-usable" unless know where it fails first!
Jul 22 '05 #30

P: n/a
> Can't you wrap it in a type that can pass accross the boundary safely?

Yes, you can, but _that_ type must call the destructor where the constructor
was called. Factory design pattern is one solution, now the only job left is
to see that the destructor is invoked in the right translation unit. A good
way to do this is to to have DeleteThis(), Release(), or similiar method and
direct calls to destructor blocked, these methods would then invoke "delete
this;", where appropriate.
STL is pretty straightforward I think and similar to concepts of many
languages. String type, stacks, maps, blah, blah, blah.


Why people keep insisting on things that I agree with as-if I didn't. The
topic wasn't what Standard Library is good for but what it isn't good for,
two completely different issues. I use it fair enough, but I don't have
fever at the moment so I am not dreaming that it does everything perfectly.
It is designed around Good Enough design philosophy: not a master of any
specific field but average, solid quality on most. Good enough for me.
Jul 22 '05 #31

P: n/a
"assaarpa" <re***********@fap.net> wrote in message
news:ci**********@phys-news1.kolumbus.fi...
<snip>
Yes, it is.

std::string foo();

If you call that method across dll boundary, you crash and burn. Bye bye
reusability. QED.


Are you using an odd definion of "reusability"? Software is reusable if it
can be used in multiple contexts (and even more so if used in many vastly
different contexts), not if it can be used in every context that you could
possibly desire to use it.

--
David Hilsee
Jul 22 '05 #32

P: n/a

"assaarpa" <re***********@fap.net> wrote in message
news:ci**********@phys-news1.kolumbus.fi...
You think just because something is valid code it will do what you want it to???

No, and that is supposed to be _my_ case. As I was saying, so much for
reusability.


You've lost me here.
You have to know what your doing.


There is no substitute (such as "STL does it for U") for being competent,
agreed.
I'm not sure it's perfect for anything. But it's excellent for many things

and
pretty good for a lot more.


One of the reasons why I use it, too, but atleast I am not yet delusional to
think that it is "re-usable" unless know where it fails first!


When you use a standard library component, you're demonstrating that it's
resuable.

Jonathan
Jul 22 '05 #33

P: n/a
> When you use a standard library component, you're demonstrating that it's
resuable.


And when not using it, because it would fail, I am demonstrating that using
it would spell disaster.
Jul 22 '05 #34

P: n/a
> > > You think just because something is valid code it will do what you
want it
to???

No, and that is supposed to be _my_ case. As I was saying, so much for
reusability.


You've lost me here.


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.

Jul 22 '05 #35

P: n/a
> Are you using an odd definion of "reusability"? Software is reusable if
it
can be used in multiple contexts (and even more so if used in many vastly
different contexts), not if it can be used in every context that you could
possibly desire to use it.


So your definition of reuse is that code *might* work? I wonder which of the
definition is more strange, that the code should work always or just
sometimes.
Jul 22 '05 #36

P: n/a
In message <ci**********@phys-news1.kolumbus.fi>, assaarpa
<re***********@fap.net> writes
I routinely pass std::strings and STL iterators across DLL boundaries
The credibility goes down the toiler the moment you mention STL iterator and
passing them across DLL boundaries.


It's _your_ credibility that suffers when you make such general
statements.
with no problems whatsoever. You must be doing something wrong.
You have no clue what I am talking about have you?


Apparently not. Perhaps you're not making yourself clear.
You know what a heap is?
Yes.
You know what happens when memory allocated in one heap using
new/new[]/malloc is freed using a matching delete/delete[]/free in another
heap?
Yes. I am well aware of what can go wrong if you code this kind of thing
naively.

If you start with a clearly-specified ownership model, it's not too
difficult to ensure that matching new/delete are always on the same side
of the DLL boundary.
You realize that std::string has optimization in many implementations,
including latest Dinkumware one, where short strings use memory allocated
like this for storage:

charT m_storage[30];

Where 30 is just example what the size might be, in this case heap is not
used to allocate memory for the string, and yes, it will work. Try longer
strings and pass objects are return values across DLL boundaries.
Irrelevant here. I'm not relying on a short string optimisation.
You
realize that what you are doing *can* work, but *can* also fail. It's
gambling at best, not good programming practise.
No gambling here. I specify the ownership model. I write and compile the
DLL to enforce that model. I write and compile the client code.
Thanks for sharing your
insight with us.


Likewise, I'm sure.

--
Richard Herring
Jul 22 '05 #37

P: n/a
On Fri, 17 Sep 2004 03:41:42 +0300, "assaarpa" <re***********@fap.net>
wrote:
Apparently you don't know how to use your compiler. Try searching
msdn. (hint: DLL versions of C runtime libraries).


Apparently you think you do, if you refer to multi-threaded runtime
libraries, no dice, that addresses similiar, but not closely related to,
issue. A good try.


The point isn't that the library is multithreaded, but rather the fact
that it is the DLL version. What do you think the issue is?
char* s = foo(); //foo in DLL allocates using new[].
delete[] s; //boom, heaps in DLL and .exe are different.


Yes. And there is a very easy solution that remedies the situation quite
nicely, but if thinking that passing std::string's around is sound practise
I would disagree all the difference that makes!


A better place to discuss this is microsoft.public.vc.stl. But it is
sound practice in so far as it works. You may decide it is not very
sound due to compiler versioning problems.

Tom
Jul 22 '05 #38

P: n/a
On 15 Sep 2004 19:32:18 -0700, ziliath <zi*****@myway.com> 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 fuck?!

I may be missing something, but at what point when learning C++
was I supposed to have picked up STL? 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.


<snip>

Im still a university student, and since my first course C++ ive been
using STL in each and every project I had to do, cant imagine why I would
not use it: its relatively fast, not really hard to use and i have to
write few lines of code. Maybe in the case of dll boundary stuff other ppl
where talking about, but ive never had to do something like that, besides
im mostly using linux for programming by now. Btw there are alternative
implementations of STL like http://www.stlport.org/product.html, wich may
address some problems one could have with it.

grtz
Emile
Jul 22 '05 #39

P: n/a
> >The credibility goes down the toiler the moment you mention STL iterator
and
passing them across DLL boundaries.
It's _your_ credibility that suffers when you make such general
statements.


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

Apparently not. Perhaps you're not making yourself clear.
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.
Yes. I am well aware of what can go wrong if you code this kind of thing
naively.
Eg. using Standard Library "like it should be used" in context where it
clearly fails. QED.
Irrelevant here. I'm not relying on a short string optimisation.
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?
No gambling here. I specify the ownership model. I write and compile the
DLL to enforce that model. I write and compile the client code.
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? Your actions
speak volumes about your attitude in this: it's the same I have! You are
arguing because you find me annoying little pest, aren't you? :)
Likewise, I'm sure.


Ditto, I rest my case.
Jul 22 '05 #40

P: n/a

"assaarpa" <re***********@fap.net> wrote in message:
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
Jul 22 '05 #41

P: n/a
I think the STL is a wonderful tools and will shorten you developing time!

"ziliath" <zi*****@myway.com> дϢ
news:6b**************************@posting.google.c om...
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 fuck?!

I may be missing something, but at what point when learning C++
was I supposed to have picked up STL? 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.

Not that I haven't tried using it. The error messages that any
newbie-to-STL is bound to get were 100+ lines long. Really useful!

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

Jul 22 '05 #42

P: n/a
On Sat, 18 Sep 2004 04:47:35 +0300, assaarpa wrote:

(Attributions mangled by parent.)
The credibility goes down the toiler the moment you mention STL
iterator and passing them across DLL boundaries.
It's _your_ credibility that suffers when you make such general
statements.


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.
Apparently not. Perhaps you're not making yourself clear.


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.
No gambling here. I specify the ownership model. I write and compile the
DLL to enforce that model. I write and compile the client code.


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

--
Some say the Wired doesn't have political borders like the real world,
but there are far too many nonsense-spouting anarchists or idiots who
think that pranks are a revolution.

Jul 22 '05 #43

P: n/a
"Archer" <xy*******@126.com> writes:
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
--
| Nicolas Pavlidis | Elvis Presly: |\ |__ |
| Student of SE & KM | "Into the goto" | \|__| |
| pa****@sbox.tugraz.at | ICQ #320057056 | |
|-------------------University of Technology, Graz----------------|
Jul 22 '05 #44

P: n/a
zi*****@myway.com (ziliath) wrote in message news:<6b**************************@posting.google. com>...
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 fuck?!

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.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Jul 22 '05 #45

P: n/a
> 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.
Jul 22 '05 #46

P: n/a
jc*****@taeus.com (Jerry Coffin) wrote in message news:<b2*************************@posting.google.c om>...
zi*****@myway.com (ziliath) wrote in message news:<6b**************************@posting.google. com>...
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 fuck?!

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


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.
Jul 22 '05 #47

P: n/a

On Sat, 18 Sep 2004, Paul wrote:

jc*****@taeus.com (Jerry Coffin) wrote...
zi*****@myway.com (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?)
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.


Seconded.

-Arthur
Jul 22 '05 #48

P: n/a
In article <1f*************************@posting.google.com> ,
Paul <in***********@hotmail.com> wrote:
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).
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Jul 22 '05 #49

P: n/a
Edd
Greg Comeau wrote:
In article <1f*************************@posting.google.com> ,
Paul <in***********@hotmail.com> wrote:
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.


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

--
Edd Dawson www.nunswithguns.net | "Arthur! My moustache is
To email me, cut the crap. | touching my brain!"
ed*@nunswithcrapguns.net | - The Tick

Jul 22 '05 #50

87 Replies

This discussion thread is closed

Replies have been disabled for this discussion.