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

[Richard Herring]

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.



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.

 

[wana]

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.

 

[ziliath]

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.

 

[Tom Widmer]

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

 

[Jonathan Turkanis]

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

 

[Greg Comeau]

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

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.

 

[assaarpa]

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.

 

[assaarpa]

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!

 

[assaarpa]

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!

 

[assaarpa]

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.

 

[David Hilsee]

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.

 

[Jonathan Turkanis]

to???

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

You've lost me here.

There is no substitute (such as "STL does it for U") for being competent,
agreed.


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

 

[assaarpa]

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.

 

[assaarpa]

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

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.

 

[assaarpa]

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.

 

[Richard Herring]

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.

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.

 

[Tom Widmer]

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

 

[bla abla]

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

 

[assaarpa]

The credibility goes down the toiler the moment you mention STL iterator
and

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.