C++ Scandal?!

[Noah Roberts]

That technique is documented somewhere, possibly under "Lean on the
Compiler". You only make such a change as you know will cleanly break, then
compile and run. When an error reports, your editor can instantly navigate
to it. This is often faster than browsing code.

Hmmm...it was documented "somewhere" so we have to buy into it?

Grep or find are great tools. Use them.

 

[Noah Roberts]

Yes, but my believe is that "typeless" entitities are much more common
in Objective-C. If I remember well, Obj-C collections store "Objects",
so once something gets into the collection, type information is lost...

Same can be said of polymorphic entities in C++.

There are several tools available at your disposal to solve this
"issue" in Objective-C. You can ask any object what it is, what
interfaces it implements, and what messages it repsonds to. Static
typing is not necissary for robust code.

That said, tell me how you would implement a container in C++ that can
hold anything. You have the STL at your disposal but think about it
for a second. Once you specialize, which you have to do, you can no
longer place anything into that container. The closest I can think of
is a container of void*.

 

[Mirek Fidler]

Mirek Fidler wrote:




Same can be said of polymorphic entities in C++.

Yes, but the difference is that polymotphic entities in C++ are much
less common and define just necessary interfaces.

There are several tools available at your disposal to solve this
"issue" in Objective-C. You can ask any object what it is, what
interfaces it implements, and what messages it repsonds to.

Yes, in runtime. Not compile time.

Static
typing is not necissary for robust code.

But of course. Careful programmer and rigid testing is what is needed in
any case.

However, in my experience, strong static typing is an advantage.

That said, tell me how you would implement a container in C++ that can
hold anything.

Vector<Any> x;

(Just because you ask)

You have the STL at your disposal but think about it
for a second.

I ignore STL for good.

Once you specialize, which you have to do, you can no
longer place anything into that container. The closest I can think of
is a container of void*.

If "anything" has any meaningful Interface, i can also go for

Array<Interface> x;

with all goodnes of static type checking still on.

BTW, putting "anything" to container WITHOUT common interface is quite
rare thing to happen.... (there is one Vector<Any> per half milion of
C++ lines in my codebase...)

BTW, important thing to note: Of course, there are many situation when
you have to drop type info in C++ in favor of genericity, implementation
etc... The advantage of C++ is that you do not have to drop it
PREMATURELY as in dynamicaly typed languages.

Mirek

 

[Noah Roberts]

Vector<Any> x;

c:\src\Playground\Playground\Playground.cpp(41) : error C2065: 'Any' :
undeclared identifier

Guess you have to define "Any" as something...

At any rate, I'll just leave you to your language biggotry and be done.
I prefer to use tools as appropriate and find I can do anything in any
language. Guess your milage is different. Ta ta.

 

[I V]

c:\src\Playground\Playground\Playground.cpp(41) : error C2065: 'Any' :
undeclared identifier

Guess you have to define "Any" as something...

Mirek could have said

std::vector<boost::any> x;

The implementation of which you can find at
http://boost.org/doc/html/any.html

 

[Phlip]

Mirek could have said

std::vector<boost::any> x;

The implementation of which you can find at
http://boost.org/doc/html/any.html

Ah, but Mirek instead said "I ignore STL for good."

Advice to the newbies: STL is part of C++. Don't put C++ on your resume
unless you are ready to support a project with STL, as with any of C++'s
other features.

 

[Noah Roberts]

Mirek could have said

std::vector<boost::any> x;

The implementation of which you can find at
http://boost.org/doc/html/any.html

This still skirts the question at any rate. The question was how would
you implement a container that can contain anything. The point of
which was to point out the complexity of such a thing in C++. As I
already pointed out it is certainly possible, since you can do anything
in any language, and boost provides tools to use that make it easy on
the end developer, but what is underneath boost::any, how much of the
static type safety remains while using it, and can it truely hold
anything or are there limits?

Simply pointing to someone else's implementation neither answers the
question nor shows any insight or knowledge of the underlying issues
whatsoever. It must also be pointed out that the container isn't
containing any value of any type...it is containing objects of type
boost::any, which can hold various unrelated types. This in itself
points out the added complexity necissary to create such containers in
a statically typed environment.

There are benefits and issues either way. Saying one is better or that
you can do X in only one or the other is just ignorance.

 

[Mirek Fidler]

The implementation of which you can find at

Ah, but Mirek instead said "I ignore STL for good."

Advice to the newbies: STL is part of C++. Don't put C++ on your resume
unless you are ready to support a project with STL, as with any of C++'s
other features.

I can support that. Never dissmiss a widely accepted tool before finding
out all its strenghts and weeknesses.

OTOH, we are here coming full circle. STL drives you to programming
style that annoys C++ critics so much - and quite often for valid reasons.

Mirek

 

[Phlip]

I can support that. Never dissmiss a widely accepted tool before finding
out all its strenghts and weeknesses.

Thanks, but that's not the reason. STL is part of C++. Thou shalt learn it,
even if it were a piece of crap (which it isn't).

OTOH, we are here coming full circle. STL drives you to programming
style that annoys C++ critics so much - and quite often for valid reasons.

Yet STL is the best style that C++ generics have to offer. If you bust on
it, then you must bust on C++. I can support that!

This still skirts the question at any rate.  The question was how would
you implement a container that can contain anything.

You shouldn't want to. A container should only contain things with something
in common. This question is subtly different from that of _enforcing_
strict static typing, everywhere.

 

[Mirek Fidler]

Mirek Fidler wrote:




Thanks, but that's not the reason.

Reason? Do you see any reasoning on my reply?

STL is part of C++. Thou shalt learn it,
even if it were a piece of crap (which it isn't).

Have I said otherwise?

You shouldn't want to. A container should only contain things with something
in common.
Exactly.

This question is subtly different from that of _enforcing_
strict static typing, everywhere.

What is "enforcing"? You can avoid strict typing in C++, everywhere. But
you are not required to, that is the point. Compare to dynamic typing,
where you are _enforced_ to _drop_ type info, almost everywhere.

Mirek

 

[Noah Roberts]

Reason? Do you see any reasoning on my reply?

Not a whole lot, no.

 

[Phlip]

Not a whole lot, no.

Mr. Manners reminds the Gentle Poster not to take cheap shots at those who
write English as a second language.

 

[I V]

This still skirts the question at any rate. The question was how would
you implement a container that can contain anything. The point of
which was to point out the complexity of such a thing in C++. As I
already pointed out it is certainly possible, since you can do anything
in any language, and boost provides tools to use that make it easy on
the end developer, but what is underneath boost::any, how much of the
static type safety remains while using it, and can it truely hold
anything or are there limits?

Right, I was misled by your comment that "The closest I can think of
is a container of void*." I thought you were saying that the _best_ one
could do in C++ was a container of void* (which would mean losing
dynamic type information as well). Having implemented an 'any' type
object myself, which was much less slick than boost::any and still
plenty complex, I agree that static type checking makes this kind of
thing highly complicated.

There are benefits and issues either way. Saying one is better or that
you can do X in only one or the other is just ignorance.

I agree completely.

 

[persenaama]

So you think C++ is doomed then?

Ofcourse it is. Just like you and me with the exception that it'll
probably outlive both of us.

 

[Mirek Fidler]

Noah Roberts wrote:




Mr. Manners reminds the Gentle Poster not to take cheap shots at those who
write English as a second language.

Never mind, at least I will now remember the meaning of "reasoning"

Mirek

 

[Noah Roberts]

Mr. Manners reminds the Gentle Poster not to take cheap shots at those who
write English as a second language.

I only have so much self control. When someone walks into it like that
I just can't help myself.

 

[Phlip]

Never mind, at least I will now remember the meaning of "reasoning"

I think the best word would have been "rationale", which newsgroup posts
should indeed use sparingly.

For example, I like to write code "XYZ" because it makes me feel good. No
rationale for it.

USENET would be a better place with fewer false-rationales zinging around.
You were correct to imply you were not promoting a rationale.

I only have so much self control.  When someone walks into it like that
I just can't help myself.

Mr. Manners /certainly/ _never_ has *that* problem!!

 

[Mirek Fidler]

I only have so much self control. When someone walks into it like that
I just can't help myself.

Well, despite Mr. Manners, not a bad way how to learn english. Feeling
stupid for a while is a strong motivation (Always helped me to both
learn and teach programming).

Mirek

 

[Diego Martins]

I agree:
C++ -> RAII -> automatic resource management (few try/catch)
Java -> no RAII -> manual resource management (many try/catch/finally)

Roland Pibinger

but a try/catch/finally in C++ would be fine

it is good to have more options. we can only emulate try/finally with
RAII. this leads to many boring local classes

 

[Phlip]

but a try/catch/finally in C++ would be fine

You can catch(...) { cleanup; throw; }

But you must also call cleanup at normal function exit. However...

it is good to have more options. we can only emulate try/finally with
RAII. this leads to many boring local classes

If I have class Q that requires Q::cleanup(), then all methods that use Q
must call cleanup(). That couples Q's internal state (the fact that it
isn't clean yet) to the control flow of all its methods. That is wasteful.