C++ Archeology: Limits of OO paradigm

[Grizlyk]

Be a man!

- hey, girl, can i ask ...
- i am not a girl!
- oh no, what is the reason to take pride?

And i am just about the beer and girls (or boys, probably, according to
sexual orientation). There are even no place where one can discuss C++
-related question, and it is distressing.

Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new

 

[Krice]

There are even no place where one can discuss C++
-related question

You are such a drama queen.

 

[Pavel Lepin]

- hey, girl, can i ask ...
- i am not a girl!
- oh no, what is the reason to take pride?

You know, idioms and cultural references do not survive
direct translation all that well. And your English is
nowhere nearly good enough for literary translations.

Which means that your insistence on trying to use
Russian-specific rhetoric devices you've grown accustomed
to, in context of a very different language, and one you're
not particularly proficient with, renders your rants even
more incomprehensible than they could've been otherwise.

If you do want to be able to reach others I would strongly
advise sticking to the basics of English until you start
feeling more comfortable with it and get up to speed on
applicable phraseology. Meanwhile your attempts at irony
produce the impression of you being a couple of bricks
short of a full load instead.

 

[Puppet_Sock]

You don't have to.  It's available as an option.  I use it
systematically in all new applications.

Um... It's not standard is it? (He asked with some
trepidation, not having the standard at hand.)
That is, this is a compiler option with some
particular vendor, right?
Socks

 

[Martin York]

[snip]

Um... It's not standard is it? (He asked with some
trepidation, not having the standard at hand.)
That is, this is a compiler option with some
particular vendor, right?
Socks

<quote>
From: ISO C++0x: Complete Public Review Draft In October 2007?
Garbage collection [N2129] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2129.pdf

A C++0x compiler must provide garbage collection, which the programmer
can use on request; "don't GC this region of code" is still the
default. This "opt-in" model leaves existing programs' semantics
unchanged, while providing real GC support for programs that want it.
It is also intended to enable garbage collection for objects allocated
and manipulated by most legacy libraries, which both makes it much
easier to convert existing code to a garbage-collected environment and
helps "repair" legacy code with deficient memory management. Of
course, any C++98/03/0x compiler is already free to garbage-collect
the whole C++ heap, and a number of current implementations do that;
but they aren't required to do so, and this change would require GC to
be available in a way that programmers can use and rely on. This work
has been primarily driven by Hans Boehm and Mike Spertus. You can find
a detailed paper here: N2128 (http://www.open-std.org/jtc1/sc22/wg21/
docs/papers/2006/n2128.pdf)
</quote>

Seems like it will be part of the next standard.

 

[peter koch]

Um... It's not standard is it? (He asked with some
trepidation, not having the standard at hand.)
That is, this is a compiler option with some
particular vendor, right?
Socks

No, its not a compiler option but an add-on library. Should work on
many of the popular compilers out there e.g. MSVC, g++ and similar.
Look for Boehm garbage collector if you cant fin it otherwise.

/Peter

 

[James Kanze]

Um... It's not standard is it? (He asked with some
trepidation, not having the standard at hand.) That is, this
is a compiler option with some particular vendor, right?

If it's an option, it's not standard, no. At least not ISO
standard. But it's readily available, and works with all of the
compilers I regularly use, on the systems I regularly work on.
(Note that installing it requires a fair bit of understanding,
as as options go, it has a lot of options itself. But I think
that there are also commercial implementations which might be
easier to install.)

 

[Grizlyk]

And your English is nowhere nearly good
enough for literary translations.

It is a kind of tragedy - my poor english. One can be sure, I have taken
the fact into account. I also agree, my literary translation is ugly by
form, but quite right by semantics. I am sure, any reader can guess what
have i said about sense of the advices about beer and girls (boys) here
and said about "reason to take pride". There is nothing "cultural" here.

Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new

 

[Grizlyk]

In the 'r-value reference' proposal,
a moveable variable is an object that
can be _moved from_ and not _moved to_.

I don't know why he wants to introduce
such a moveable datatype thing, since
it would be a nightmare to use variables
that can only be used ....

All answers for questions like these one can find in my page
http://grizlyk1.narod.ru/cpp_new , articles:
#11 - #14 (including appendixes).

In addition to my page info, i can say, that i see now, that the terms and
conditions, that are used by current C++ development process, can not
produce any excepting "r-value references". The "r-value references" was a
next drop for my patience.

The idea came up to my mind, that there are three types of operations:

- copy |
- move | both classical semantics

- forward | C++ (auto memory type) specific

Forward (forwarding) is a way to pass _value_(not reference) over static
scope boundaries, can not represent move semantic, can have valueable
overhead in comparison with parameter passed by reference (or via
pointer). Forwarding is a kind of refinment of copy semantics and
_absolutely_ unrelated to "reference" semantics (and "reference" word).

By the way, r-value is a thing, that by definition of "r-value" has no
reference.

Without explanation I would not understand ...

You, probably, represent another sort of users, who can not understand
goals and differences of declared constructions like this:

spec_type foo(const spec_type&);
spec_type foo(const spec_type);

and you should use complete description on my page befor.

Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new

 

[Grizlyk]

A C++0x compiler must provide garbage
collection, which the programmer can
use on request

The garbage collection could be, as option.

Some time ago i have beleived, that garbage collection is only way to
support OO paradigm - dynamically created objects.

Fortunatelly, exploring moveable semantics, i have realized, that the same
(support of ownership) can be done with auto memory, at compile time,
without any overhead (in comparison with garbage collection).

With moveable, any dynamically created objects will have in fact the same
performance and reliability, as ordinary statically created in auto memory
objects.

The only differences between "garbage collection" and "auto owners with
moveable semantics", that:
- with moveable, user must exlicitly declare scope, in with his object
will be alive, in other words, user must explicitly tell to compiler: does
he want to destroy the object just now or does not;
- with garbage collection user just drops object in hope, that compiler
will delete it somehow.

The "dropping" leads to valueable overhead, especially in the places,
where auto owners with moveable semantics can be successfully used.

Moveable semantics requires compile time support (a trivial kind of
metaprogramming), that temporary can be done for C++ with the help of
"compile time attributes". The better way can be "protocols (states)" -
meta properties of classes. The "protocols" requires too many changes to
C++ .

Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new