青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

Windreamer Is Not a DREAMER
main(){main(puts("Hello,stranger!"));}
發(fā)件人: Andrei Alexandrescu (See Website For Email) ?
日期: 2006年3月18日(星期六) 下午12時13分
電子郵件: "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEm...@erdani.org>
論壇: comp.lang.c++.moderated

The recent thread "Can GC be beneficial" was quite beneficial :o) - to
me at least. I've reached a number of conclusions that allow me to
better place the conciliation between garbage collection and
deterministic finalization in the language design space - in C++ and in
general.

The following discussion focuses on C++-centric considerations, with
occasional escapes into "the right thing to do if we could break away
with the past.

Basic Tenets, Constraints, and Desiderata
=========================================

Garbage collection is desirable because:

(1) It automates a routine and error-prone task

(2) Reduces client code

(3) Improves type safety

(3) Can improve performance, particularly in multithreaded environments

On the other hand, C++ idioms based on constructors and destructors,
including, but not limited to, scoped resource management, have shown to
be highly useful. The large applicability of such idioms might actually
be the single most important reason for which C++ programmers shy away
from migrating to a garbage-collected C++ environment.

It follows that a set of principled methods that reconcile C++-style
programming based on object lifetime, with garbage collection, would be
highly desirable for fully exploiting garbage collection's advantages
within C++. This article discusses the challenges and to suggests
possible designs to address the challenges.

The constraints include compatibility with existing C++ code and styles
of coding, a preference for type safety at least when it doesn't
adversely incur a performance hit, and the functioning of today's
garbage collection algorithms.

A Causal Design
===============

Claim #1: The lifetime management of objects of a class is a decision of
the class implementer, not of the class user.

In support of this claim we come with the following examples:

a) A class such as complex<double> is oblivious to destruction
timeliness because it does not allocate scarce resource that need timely
release;

b) A class such as string doesn't need to worry about destruction
timeliness within a GC (Garbage Collected) environment;

c) A class such as temporary_file does need to worry about destruction
timeliness because it allocates scarce resources that transcend both the
lifetime of the object (a file handle) and the lifetime of the program
(the file on disk that presumably temporary_file needs to delete after
usage).

In all of these examples, the context in which the objects are used is
largely irrelevant (barring ill-designed types that employ logical
coupling to do entirely different actions depending on their state).
There is, therefore, a strong argument that the implementer of a class
decides entirely what the destruction regime of the class shall be. This
claim will guide design considerations below.

We'll therefore assume a C++ extension that allows a class definition to
include its destruction regime:

?

// ?garbage?collected??
?
class?[collected]?Widget?{...};?
//?deterministically?destroyed??
?
class?[deterministic]?Midget?{...};?


?

These two possible choices could be naturally complemented by the other
allowed storage classes of a class:

?

// ?garbage?collected?or?on?stack??
??
class?[collected,?auto]?Widget?{...};?
//?deterministically?destroyed,?stack,?or?static?storage??
??
class?[deterministic,?auto,?static]?Midget?{...};?

It is illegal, however, that a class specifies both collected and
deterministic regime:

?

// ?illegal??
??
class?[collected,?deterministic]?Wrong?{...};?


?

Claim #2: Collected types cannot define a destruction-time action.

This proposal makes this claim in wake of negative experience with
Java's finalizers.

Claim #3: Collected types can transitively only embed fields of
collected types (or pointers thereof of any depth), and can only derive
from such types.

If a collected type would have a field of a non-collected type, that
type could not be destroyed (as per Claim #2).

If a collected type would have a field of pointer to a non-collected
type, one of two things happens:

a) A dangling pointer access might occur;

b) The resource is kept alive indeterminately and as such cannot be
destroyed (as per claim #2).

If a collected type would have a field of pointer to pointer to (notice
the double indirection) deterministic type, inevitably that pointer's
destination would have to be somehow accessible to the garbage-collected
object. This implies that at the some place in the points-to chain, a
"jump" must exist from the collected realm to the uncollected realm (be
it automatic, static, or deterministic) that would trigger either
post-destruction access, or would prevent the destructor to be called.

Design fork #1: Weak pointers could be supported. A collected type could
hold fields of type weak pointer to non-collected types. The weak
pointers are tracked and are zeroed automatically during destruction of
the resource that they point to. Further dereference attempts accesses
from the collected realm become hard errors.

Claim #4: Deterministic types must track all pointers to their
respective objects (via a precise mechanism such as reference counting
or reference linking).

If deterministic types did allow untracked pointer copying, then
post-destruction access via dangling pointers might occur. The recent
discussion in the thread "Can GC be beneficial" has shown that it is
undesirable to define post-destruction access, and it's best to leave it
as a hard run-time error.

Design branch #2: For type safety reasons, disallow type-erasing
conversions from/to pointers to deterministic types:

?

???
???class?[deterministic]?Widget?{...};?
???Widget?
*?p?=?new?Widget;?
???void?*?p1?=?p;?//?error??
???
p?=?static_cast<Widget?*>(p1);?//?error,?too?

Or: For compatibility reasons, allow type-erasing conversion and incur
the risk of dangling pointer access.

Design branch #3: For purpose of having a type that stands in as a
pointer to any deterministic type (a sort of "deterministic void*"), all
deterministic classes could be thought as (or required to) inherit a
class std::deterministic.

Design branch #3.1: std::deterministic may or may not define virtuals,
and as such confines or not all deterministic classes to have virtuals
(and be suitable for dynamic_cast among other things).

Claim #5: When an object of deterministic type is constructed in
automatic or static storage, its destructor will automatically issue a
hard error if there are any outstanding pointers to it (e.g., the
reference count is greater than one).

If that didn't happen, dangling accesses to expired stack variables
might occur:

?

?class?[deterministic]?Widget?{...};?
?Widget?
*?p;?
int?Fun()?{?
????Widget?w;?
????p?
=?&w;?
????
//?hard?runtime?error?upon?exiting?this?scope?



}
?



?

Discussion of the basic design
==============================

The desiderata set up and the constraints of the current C++ language
created a causal chain that narrowly guided the possible design of an
integrated garbage collection + deterministic destruction in C++:

* The class author decides whether the class is deterministic or garbage
collected

* As a natural extension, the class author can decide whether objects of
that type are allowed to sit on the stack or in static storage. (The
regime of automatic and static storage will be discussed below.)

* Depending on whether a type is deterministic versus collected, the
compiler generates different code for copying pointers to the object.
Basically the compiler automates usage of smart pointers, a
widely-followed semiautomatic discipline in C++.

* The heap is conceptually segregated into two realms. You can hold
unrestricted pointers to objects in the garbage-collected realm, but the
garbage-collected realm cannot hold pointers outside of itself.

* The operations allowed on pointers to deterministic objects are
restricted.

Regime of Automatic Storage
===========================

Claim 6: Pointers to either deterministic or collected objects that are
actually stack allocated should not escape the scope in which their
pointee object exists.

This obvious claim prompts a search in look for an efficient solution to
a class of problems. Here is an example:

?

?class?[auto,?collected]?Widget?{...};?
void?Midgetize(Widget?&?obj)?{?
????obj.Midgetize();?


}
?


void?Foo()?{?
????Widget?giantWidget;?
????Midgetize(giantWidget);?


}
?



?

To make the example above work, Foo is forced to heap-allocate the
Widget object even though the Midgetize function works on it
transitorily and stack allocation would suffice.

To address this problem a pointer/reference modifier, "auto", can be
defined. Its semantics allow only "downward copying": an
pointer/reference to auto can only be copied to lesser scope, never to
object of larger scope. Examples:

?

void?foo()?{?
????Widget?w;?
????Widget?
*auto?p1?=?&w1;?//?fine,?p1?has?lesser?scope?
????{?
??????Widget?
*auto?p2?=?&w;?//?fine?
??????p2?=?p1;?//?fine?
??????p1?=?p2;?//?error!?Escaping?assignment!?
????}
?



}
?



?

Then the example above can be made modularly typesafe and efficient like
this:

?

?class?[auto,?collected]?Widget?{...};?
void?Midgetize(Widget?&auto?obj)?{?
????obj.Midgetize();?


}
?


void?Foo()?{?
????Widget?giantWidget;?
????Midgetize(giantWidget);??
//?fine?


}
?


?

Claim #6: "auto"-modified pointers cannot be initialized or assigned
from heap-allocated deterministic objects.

If "auto"-modified pointers manipulated the reference count, their
efficiency advantage would be lost. If they didn't, a type-unsafe
situation can easily occur.

Does operator delete still exist?
=================================

For collected objects, delete is inoperant, as is for static or
automatic objects. On a heap-allocated deterministic object, delete can
simply check if the reference count is 1, and if so, reassign zero to
the pointer. If the reference count is greater than one, issue a hard ?
error.

Note that this makes delete entirely secure. There is no way to have a
working program that issues a dangling access after delete has been ?
invoked.

Regime of Static Storage
========================

Static storage has the peculiarity that it can easily engender
post-destruction access. This is because the order of module
initialization is not defined, and therefore cross-module dependencies
among objects of static duration are problematic.

This article delays discussion of the regime of static storage.
Hopefully with help from the community, a workable solution to the
cross-module initialization would ensue.

Templates
=========

Claim #7: The collection regime of any type must be accessible during
compilation to templated code.

Here's a simple question: is vector<T> deterministic or collected?

If it were collected, it couldn't hold deterministic types (because at
the end of the day vector<T> must embed a T*). If it were deterministic,
collected types couldn't hold vectors of pointers to collected types,
which would be a major and gratuitous restriction.

So the right answer is: vector<T> has the same regime as T.

?

template?<class?T,?class?A>?
class?[T::collection_regime]?vector?{?//?or?some?other?syntax?
???...?

}
;?


?

The New World: How Does it Look Like?
=====================================

After this design almost happening as a natural consequence of an
initial set of constraints, the natural question arises: how would
programs look like in a C++ with these amenities?

Below are some considerations:

* Pointer arithmetic, unions, and casts must be reconsidered (a source
of unsafety not thoroughly discussed)

* Most types would be [collected]. Only a minority of types, those that
manage non-memory resources, would live in the deterministic realm.

* Efficiency of the system will not degrade compared to today's C++. The
reduced need for reference-counted resources would allow free and fast
pointer copying for many objects; the minority that need care in
lifetime management will stay tracked by the compiler, the way they
likely were manipulated (by hand) anyway.

* Given that the compiler can apply advanced analysis to eliminate
reference count manipulation in many cases, it is likely that the
quality of built-in reference counting would be superior to
manually-implemented reference counting, and on a par with advanced
manual careful manipulation of a mix of raw and smart pointers.

----------------------

Whew! Please send any comments you have to this group. Thanks!

Andrei

? ? ? [ See http://www.gotw.ca/resources/clcm.htm for info about ]
? ? ? [ comp.lang.c++.moderated. ? ?First time posters: Do this! ]

posted on 2006-03-21 10:01 Windreamer Is Not DREAMER 閱讀(622) 評論(1)  編輯 收藏 引用
Comments
  • # re: [ZZ]Reconciling Garbage Collection with Deterministic Finalization
    Francis Arcanum
    Posted @ 2006-10-28 01:33
    萬年不更新的家伙,悄悄bs一下^_^  回復  更多評論   
 
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            亚洲人成在线播放| 黑人极品videos精品欧美裸| 欧美日韩在线播| 欧美日韩日本视频| 欧美视频在线视频| 国产精品白丝av嫩草影院| 欧美亚韩一区| 国产视频在线观看一区| 黄色一区二区三区四区| 亚洲国内自拍| 一区二区三区欧美在线| 亚洲欧美日韩一区二区在线| 久久不见久久见免费视频1| 久久看片网站| 亚洲国产成人高清精品| 亚洲精品久久久久久久久久久久久| 日韩亚洲视频在线| 亚洲免费在线电影| 久久一区二区视频| 欧美日韩国内| 国产欧美日韩麻豆91| 尹人成人综合网| 99re8这里有精品热视频免费| 亚洲中字在线| 久久人人看视频| 亚洲国产日韩一区二区| 亚洲小说欧美另类社区| 久久久久国产精品一区二区| 欧美激情精品久久久久久黑人| 国产精品美女久久久久久久 | 亚洲国产导航| 亚洲天堂成人在线观看| 久久久无码精品亚洲日韩按摩| 欧美另类变人与禽xxxxx| 国产欧美va欧美va香蕉在| 亚洲国产精品久久久久久女王| 亚洲一区在线免费观看| 毛片一区二区| 一区二区三区视频免费在线观看| 久久se精品一区二区| 欧美久久视频| 狠狠色丁香婷婷综合久久片| 一区二区日韩精品| 久久综合999| 亚洲视频国产视频| 蜜臀久久99精品久久久画质超高清| 国产精品a久久久久| 亚洲国产精品尤物yw在线观看| 午夜精品久久久久久99热| 欧美成人自拍| 性欧美videos另类喷潮| 欧美日韩视频第一区| 伊人精品成人久久综合软件| 亚洲欧美一区二区三区久久 | 在线日韩av| 香蕉国产精品偷在线观看不卡| 亚洲国产成人av好男人在线观看| 欧美一区=区| 欧美日韩直播| 最新国产拍偷乱拍精品| 久久久久欧美精品| 国产精品99久久久久久宅男| 欧美成人在线免费观看| 激情久久久久| 午夜视频在线观看一区二区三区| 亚洲欧洲三级| 免费成人av| 激情五月综合色婷婷一区二区| 欧美一区二区高清在线观看| 日韩午夜激情电影| 欧美精品二区三区四区免费看视频| 在线观看91精品国产麻豆| 久久精品最新地址| 亚洲免费在线播放| 国产精品久久久久99| 在线中文字幕不卡| 91久久精品国产91性色tv| 久久综合国产精品| 一区二区三区自拍| 久久久一本精品99久久精品66| 亚洲欧美电影在线观看| 国产精品视频一二三| 亚洲一区二区不卡免费| 亚洲精品午夜| 欧美日韩美女在线| 亚洲视频一二| 日韩午夜激情电影| 欧美性猛交99久久久久99按摩 | 亚洲人体1000| 欧美精品七区| 一本色道久久综合狠狠躁篇怎么玩| 亚洲国产精品热久久| 欧美寡妇偷汉性猛交| 亚洲美女性视频| 亚洲精品日韩精品| 欧美日韩国产影片| 亚洲午夜激情| 99精品福利视频| 国产精品第2页| 午夜日韩激情| 欧美一区免费| 亚洲成人在线视频播放| 欧美成人精品激情在线观看| 女人天堂亚洲aⅴ在线观看| 亚洲日本视频| 亚洲精品中文字幕女同| 欧美四级在线观看| 午夜精品一区二区三区在线| 性亚洲最疯狂xxxx高清| 国内一区二区三区| 欧美激情视频在线播放 | 久久国产精品网站| 亚洲高清激情| 日韩午夜三级在线| 国产精品美女主播| 久久久久九九九| 久久网站热最新地址| 亚洲美女免费精品视频在线观看| 日韩一区二区久久| 国产亚洲一区二区三区| 欧美不卡视频一区| 欧美日韩三级一区二区| 欧美一区=区| 久久综合九色九九| 亚洲视频你懂的| 羞羞色国产精品| 亚洲国产精品综合| 国产精品99久久久久久久女警| 国语自产在线不卡| 亚洲精品久久久久久久久久久久久| 国产精品一区在线观看| 欧美成人免费全部| 欧美三级网页| 久久综合久久综合久久| 欧美国产日韩一区二区| 午夜在线精品偷拍| 久久综合久久综合九色| 亚洲一区二区三区高清不卡| 久久精品在线| 宅男在线国产精品| 久久精品人人| 亚洲午夜精品福利| 久久久久久久一区二区三区| 亚洲特级毛片| 久久亚洲春色中文字幕久久久| 亚洲伊人一本大道中文字幕| 久久综合狠狠综合久久综青草 | 欧美四级在线观看| 免费亚洲一区| 国产精品腿扒开做爽爽爽挤奶网站| 欧美成人蜜桃| 国产日韩亚洲欧美| 亚洲美女诱惑| 在线欧美日韩国产| 亚洲欧美伊人| 亚洲少妇在线| 女同一区二区| 久久一区中文字幕| 国产精品久久999| 亚洲国产天堂久久综合| 国内精品模特av私拍在线观看| 99re热这里只有精品视频| 在线免费观看日韩欧美| 亚洲男人的天堂在线观看| 99视频热这里只有精品免费| 老司机午夜精品| 久久经典综合| 国产精品久久一级| 亚洲三级国产| 亚洲经典三级| 久久精品视频在线播放| 欧美中文在线视频| 欧美系列精品| 亚洲美女在线视频| 亚洲免费观看高清在线观看| 久久久www成人免费无遮挡大片| 亚洲欧美另类综合偷拍| 欧美日韩在线一区二区| 亚洲国产一区二区三区在线播| 揄拍成人国产精品视频| 久久超碰97人人做人人爱| 午夜精品久久久久久久久久久| 欧美日韩精品欧美日韩精品 | 欧美国产欧美亚洲国产日韩mv天天看完整| 久久久精品一区| 国产日韩一区| 亚洲欧美在线一区二区| 香蕉久久一区二区不卡无毒影院 | 欧美激情一区二区在线| 欧美激情在线| 亚洲国产影院| 欧美高清视频一二三区| 亚洲第一区在线观看| 亚洲国产精品v| 毛片精品免费在线观看| 欧美多人爱爱视频网站| 亚洲电影观看| 免费欧美日韩国产三级电影| 亚洲成人在线视频网站| 亚洲精品国产精品国自产观看|