2004年OOPSLA的Boost研讨会 [英] Boost Workshop at OOPSLA 2004
问题描述
致电论文/参与
C ++，Boost和C ++图书馆的未来
OOPSLA研讨会
10月24-28,2004
加拿大不列颠哥伦比亚省温哥华
http ：//tinyurl.com/4n5pf
提交
每位参与者都需要制定一份立场文件
描述当前C ++标准库和Boost中缺少的特定库或库类别。参与者
应解释为什么库或库会推进
C ++编程的状态。理想情况下，论文应该草拟建议的库
界面和概念。这将是一个批评
和审查图书馆提案的独特机会。或者，参与者可能会描述现有图书馆的优点和缺点，以及如何修改它们以满足需求。
提交的形式
提交的文件应包含3-10页的论文，该文件至少给出了b / b
提案的动机和非正式描述。这个
可以通过建议的
库的来源或其他文档进行扩充（如果有的话）。提交的首选形式是PDF文件。
重要日期
？提前注册的截止日期：2004年9月10日
？提前通知选择：2004年9月15日
？ OOPSLA提前报名截止日期：2004年9月16日
？ OOPSLA会议：2004年10月24日至28日
联系委员会 oo **** ****@crystalclearsoftware.com
计划委员会
Jeff Garland
Nicolai Josuttis
Kevlin Henney
Jeremy Siek
[见 http://www.gotw.ca/resources/clcm.htm 有关的信息]
[comp.lang.c ++。主持。第一次海报：做到这一点！ ]
CALL FOR PAPERS/PARTICIPATION
C++, Boost, and the Future of C++ Libraries
Workshop at OOPSLA
October 24-28, 2004
Vancouver, British Columbia, Canada
http://tinyurl.com/4n5pf
Submissions
Each participant will be expected to develop a position paper
describing a particular library or category of libraries that is
lacking in the current C++ standard library and Boost. The participant
should explain why the library or libraries would advance the state of
C++ programming. Ideally, the paper should sketch the proposed library
interface and concepts. This will be a unique opportunity to critique
and review library proposals. Alternatively, a participant might
describe the strengths and weaknesses of existing libraries and how
they might be modified to fill the need.
Form of Submissions
Submissions should consist of a 3-10 page paper that gives at least
the motivation for and an informal description of the proposal. This
may be augmented by source or other documentation of the proposed
libraries, if available. Preferred form of submission is a PDF file.
Important Dates
? Submission deadline for early registration: September 10, 2004
? Early Notification of selection: September 15, 2004
? OOPSLA early registration deadline: September 16, 2004
? OOPSLA conference: October 24-28, 2004
Contact committee oo********@crystalclearsoftware.com
Program Committee
Jeff Garland
Nicolai Josuttis
Kevlin Henney
Jeremy Siek
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
推荐答案
" Jeremy Siek" < JE ********* @ gmail.com>在消息中写道
news：21 ************************** @ posting.google.c om ...
"Jeremy Siek" <je*********@gmail.com> wrote in message
news:21**************************@posting.google.c om...
致电论文/参与
C ++，Boost和C ++图书馆的未来
OOPSLA研讨会
2004年10月24日至28日/>加拿大不列颠哥伦比亚省温哥华
http://tinyurl.com/4n5pf
[snip]
我想知道提交者是否遵循这篇文章的路径或者我应该发送电子邮件
他们......无论如何，这里去了。
我不确定我是否会到处写作，所以我说我会发布
想法在这里，也许有人会追求它。简而言之，我认为建议用一个替换C ++的预处理器的方法，我认为是受欢迎的。
今天Boost使用预处理器库，反过来（请纠正我
，如果我的理解是错误的）依赖于一个程序来生成一些大的
宏，直到固定的最大值 ;克服预处理器无法处理可变数量的论点。
另外，如果我错了，请纠正我（因为我没有我真的很深入了吗？但是我的理解是，Boost周围的人看到PP
库是一个必不可少但令人不快的气味的东西br />
周围也有臭味。 [让我想起了罗马尼亚人的故事：有一个男人叫做Pepelea（发音为Peh-Peh-leah），他很穷但继承了一个漂亮的房子。一个有钱人想要买它，Pepelea卖了一个
条件：Pepelea在客厅的墙上有一个钉子，在那里他可以
可以挂任何他想要的东西。现在当有钱人正在招待客人的时候，Pepelea便会匆匆忙忙地挂上一件脏兮兮的旧外套。
当然最后有钱人变得如此恼怒，以至于他免费给了Pepelea
房子。从那个故事开始，Pepelea的指甲被称为
就像...类似于预处理器对C ++语言的影响。]
这就是创建新C ++的原因之一预处理。 （当我说
" new，'那'不像'另一个标准的C ++预处理器'时。我已经很高兴看到我了关于Boost邮件列表的建议接着是
WAVE预处理器是使用Boost自己的解析器生成器库构建的，
Spirit。）我现在所说的是 ;一个向后兼容的C ++预处理器
旨在永远取代现有的预处理器并将其替换为
a更好的一个。
如果得到大型Boost社区的支持，新的预处理器可以很容易地获得普及，并用于新项目而不是旧项目。为了避免
继承过去的错误，新的预处理器不需要与旧的预处理器以任何方式与语法兼容，但只有
功能兼容，因为它可以完成所有可以用现有的预处理器完成的工作，只是它有新的方法来做更安全的事情和
更好。
我认为那会很棒。因为我们都停止编码一秒钟而且想到它，C ++脸上最丑陋的是什么 - Pepelea的指甲是什么？
也许是出口这是如此破碎，如此无用，如此侮辱，以至于它的实施者在漫长的岁月里发展了斯德哥尔摩综合症，这是他们实施的吗？也许设计得如此糟糕的命名空间，你会认为它们是从C继承的吗？我会说他们是很好的竞争者
互相对抗，但没有一个对预处理器持蜡烛。
所以，一个提议新的预处理器会很棒。这是一个简短的愿望
列表：
*现有的是什么（虽然其中一些编码模式
将被推荐）;
*支持一次性文件包含和多个文件包含，而不需要
需要警卫（是的，有相关的细微问题）那个...让我们在
最少处理明确定义的案例子集）;
*允许定义卫生宏 - 扩展为相同文本的宏
独立于扩展它们的上下文;
*允许定义范围宏 - 宏只在宏内可见当前
范围;
*有递归和可能的迭代;
*有一个简单明了的扩展模型（负面例子比比皆是 - 不喜欢
m4，不喜欢tex ...：o））
*支持可变数量的参数。我不会想到
更酷的支持计划或Java Extender宏的dylan。
Andrei
[见 http://www.gotw.ca/resources/clcm.htm 有关的信息]
[comp.lang.c ++。审核。第一次海报：做到这一点！ ]
[snip]
I wonder if the submitters follow this post''s trail or I should email
them... anyway, here goes.
I am not sure if I''ll ever get around to writing it, so I said I''d post the
idea here, maybe someone will pursue it. In short, I think a proposal for a
replacement of C++''s preprocessor would be, I think, welcome.
Today Boost uses a "preprocessor library", which in turn (please correct me
if my understanding is wrong) relies on a program to generate some many big
macros up to a fixed "maximum" to overcome preprocessor''s incapability to
deal with variable number of arguments.
Also, please correct me if I''m wrong (because I haven''t really looked deep
into it), but my understanding is that people around Boost see the PP
library as a necessary but unpleasantly-smelling beast that makes things
around it smelly as well. [Reminds me of the Romanian story: there was a guy
called Pepelea (pronounced Peh-Peh-leah) who was poor but had inherited a
beautiful house. A rich man wanted to buy it, and Pepelea sold it on one
condition: that Pepelea owns a nail in the living room''s wall, in which he
can hang whatever he wanted. Now when the rich man was having guests and
whatnot, Pepelea would drop by and embarraisingly hang a dirty old coat. Of
course in the end the rich man got so exasperated that he gave Pepelea the
house back for free. Ever since that story, "Pepelea''s nail" is referred to
as something like... like what the preprocessor is to the C++ language.]
That would be reason one to create a new C++ preprocessor. (And when I say
"new," that''s not like in "yet another standard C++ preprocessor". I have
been happy to see my suggestion on the Boost mailing list followed in that
the WAVE preprocessor was built using Boost''s own parser generator library,
Spirit.) What I am talking now is "a backwards-INcompatible C++ preprocessor
aimed at displacing the existing preprocessor forever and replacing it with
a better one".
If backed by the large Boost community, the new preprocessor could easily
gain popularity and be used in new projects instead of the old one. To avoid
inheriting past''s mistakes, the new preprocessor doesn''t need to be
syntax-compatible in any way with the old preprocessor, but only
functionally compatible, in that it can do all that can be done with the
existing preprocessor, only that it has new means to do things safer and
better.
I think that would be great. Because it we all stop coding for a second and
think of it, what''s the ugliest scar on C++''s face - what is Pepelea''s nail?
Maybe "export" which is so broken and so useless and so abusive that its
implementers have developed Stockholm syndrome during the long years that
took them to implement it? Maybe namespaces that are so badly designed,
you''d think they are inherited from C? I''d say they are good contenders
against each other, but none of them holds a candle to the preprocessor.
So, a proposal for a new preprocessor would be great. Here''s a short wish
list:
* Does what the existing one does (although some of those coding patterns
will be unrecommended);
* Supports one-time file inclusion and multiple file inclusion, without the
need for guards (yes, there are subtle issues related to that... let''s at
least handle a well-defined subset of the cases);
* Allows defining "hygienic" macros - macros that expand to the same text
independent on the context in which they are expanded;
* Allows defining scoped macros - macros visible only within the current
scope;
* Has recursion and possibly iteration;
* Has a simple, clear expansion model (negative examples abound - NOT like
m4, NOT like tex... :o))
* Supports variable number of arguments. I won''t venture into thinking of
more cool support a la scheme or dylan ofr Java Extender macros.
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
" Andrei Alexandrescu \（参见Email \网站）"
"Andrei Alexandrescu \(See Website for Email\)"
替换C ++的预处理器...
replacement of C++''s preprocessor...
如果你打算建立一个更好的文本替换层，或者甚至是一个
真的Lisp-ish宏系统（虽然一个被限制为
编译时），为什么不进一步通过
这个新的解析器来清理更多的语言？如何使用更好的模板系统来拥抱和简化模板
元编程，这是一个真正的
编译时功能语言本身无限制
递归，清除错误信息等。事实上，有可能将这个新的超级宏系统和模板统一起来
扩展/元编程语法。
* C ++改进：敢于梦想，但穿石棉内裤只需
以防万一。
[见 http://www.gotw.ca/resources/clcm.htm 有关的信息]
[comp.lang.c ++。moderated。第一次海报：做到这一点！ ]
If you''re going to build a better text-substitution layer, or even a
true Lisp-ish macro system (although one which was restricted to
compile-time), why not go further and cleanup more of the language via
this new parser? How about embracing and simplifying template
meta-programming with a better template system that is a true
compile-time functional language in its own right with unlimited
recursion, clear error messages, etc. In fact, it may be possible to
unify both this new uber macro system and the template
expansion/met-programming syntax.
* C++ improvements: Dare to dream, but wear asbestos underpants just
in case.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
" Andrei Alexandrescu \（参见Email for\\网站）" <硒**************** @ moderncppdesign.com>写道：
"Andrei Alexandrescu \(See Website for Email\)" <Se****************@moderncppdesign.com> writes:
" Jeremy Siek" < JE ********* @ gmail.com>在消息中写道
新闻：21 ************************** @ posting.google.c om ...
"Jeremy Siek" <je*********@gmail.com> wrote in message
news:21**************************@posting.google.c om...
>致电论文/参与
>
> C ++，Boost和C ++库的未来
> OOPSLA研讨会
> 2004年10月24日至28日
>加拿大不列颠哥伦比亚省温哥华
> http://tinyurl.com/4n5pf [snip]
我想知道提交者是否遵循这篇文章的路径或者我应该发送电子邮件给他们......无论如何，这里也是。
我不确定我是否会到处走写它，所以我说我会在这里发布
想法，也许有人会追求它。简而言之，我认为，对于替换C ++预处理器的提议，我认为是受欢迎的。
> CALL FOR PAPERS/PARTICIPATION
>
> C++, Boost, and the Future of C++ Libraries
> Workshop at OOPSLA
> October 24-28, 2004
> Vancouver, British Columbia, Canada
> http://tinyurl.com/4n5pf [snip]
I wonder if the submitters follow this post''s trail or I should email
them... anyway, here goes.
I am not sure if I''ll ever get around to writing it, so I said I''d post the
idea here, maybe someone will pursue it. In short, I think a proposal for a
replacement of C++''s preprocessor would be, I think, welcome.
很难看出这是怎么回事关于C ++库，但是我会跟随它们。
今天Boost使用一个预处理器库，反过来（请
如果我的理解是错误的，请纠正我）依赖于程序来生成一些大的宏，直到固定的最大值。克服
预处理器无法处理可变数量的争论。
这种情况非常混乱。
预处理器库是一个包含头文件和宏的库，允许
您可以通过编写由宏
调用构建的程序来生成C / C ++代码。您可以在
http：//www.boost-consulting中查看示例附录。 .com / mplbook 相当温和
介绍。
在预处理器库'_implementation_中，有很多
样板程序生成的宏，但这是一个实现
的详细信息'只需要这么多，因为很多预处理器严重不符合
不合格。事实上，图书馆的维护者Paul Mensonides，
有一个更优雅实施的PP库
（ http://sourceforge.net/projects/chaos-pp/ ）几乎没有
样板，但它只适用于少数编译器（其中包括GCC）。
没有办法克服 PP无法处理
可变数量的参数，而不是使用PP数据结构作为
中描述的 http://boost-consulting.com/mplbook/preprocessor.html
通过多个项目作为单个宏参数，或者通过扩展PP
来支持变量宏a la C99，正如委员会准备做的那样。
PP库是_often_用于克服C ++无法支持具有可变数量参数的
类型安全函数（模板），
编写生成重载函数的PP程序（模板）s。
另外，如果我错了，请纠正我（因为我并没有真正深入了解它），但我的理解是周围的人<提升看到PP库是一种必要但令人不快的气味，它会让它周围的东西发臭。
我不是那么看，虽然我希望有一些方法可以避免在某些更常见的情况下使用它来获得
（可变参数模板）。也许
其他人确实这样看。
[让我想起罗马尼亚的故事：有一个名叫Pepelea的人
（发音为Peh-Peh-leah） ）谁是穷人，但继承了一个美丽的房子。一个富翁想要买它，Pepelea就把它卖掉了一个条件：Pepelea在客厅的墙上钉了一个钉子，
他可以挂任何他想要的东西。现在，当有钱人带着客人和诸如此类的东西时，Pepelea便会匆匆忙忙地挂上一件肮脏的旧外套。当然最后这位有钱人感到非常愤怒，以至于他把Pepelea的房子免费送回了。从那个故事开始，Pepelea的指甲就像预期处理器对C ++语言的含义一样......。
可爱。
这就是理由一个用于创建新的C ++预处理器。 （并且当我说新的时，它不像是另一个标准的C ++
预处理器。我很高兴看到我对Boost的建议
邮件列表后面是WAVE预处理器是使用
Boost自己的解析器生成器库Spirit构建的。）我现在所说的是一个向后兼容的C ++预处理器，旨在取代
现有的预处理器永远用一个更好的一个替换它。
Bjarne的计划是通过在核心中引入功能逐渐使现有PP的功能多余化
语言...然后，最后，弃用它。
如果得到大型Boost社区的支持，新的预处理器可以轻松获得普及并用于新项目而不是老一点。
我怀疑即使Boost支持整个社区可能很容易接受将其他工具集成到其构建过程中。
C ++ PP的一大优势在于它是内置的...而且这是* _ b $ b PP _lib_更适合我的目的的最大原因之一
比我过去编写/使用过的任何特殊代码生成器。
为了避免继承过去的错误，新的预处理器
不会不需要使用旧的
预处理器以任何方式与语法兼容，但只能在功能上兼容，因为它可以完成所有可以使用现有预处理器完成的任务，只需要它/>有新的方法来做更安全和更好的事情。
我认为Bjarne的方法是做出那种替换b
的最好方法。只要PP'的功能真的被一个文本预处理器取代（或者我们今天有一个令人敬意的，因为我们今天有b $ b），它就会发生遭受许多同样的问题。这些
工作中的大部分工作应该由更强大的元编程系统填充，该系统完全集成到语言中而不仅仅是处理阶段。
我认为那会很棒。因为我们都停止了第二次编码并想到它，C ++脸上最丑陋的是什么 - Pepelea的指甲是什么？也许是出口这是如此破碎，如此无用
如此侮辱，以至于其实施者在漫长的岁月中发展出斯德哥尔摩综合症，并将其付诸实施？
那是'诽谤; - >。例如，导出可用于优化模板
元程序（将模板编译为可执行代码
进行实例化）。这可能不是一个好主意，但是那些通过实施它而遭受损失的人现在认为它有一些潜在的实用价值。
也许命名空间设计得那么糟糕，你会认为它们是从C继承的吗？
哇，我印象深刻;那将会惹恼C&C的硬核C _and_
$
我从来没有看到过更好的名称空间的提议，其他比
http://boost-consulting.com/writing/qn .html ，似乎一般都被忽略了。你有什么想法吗？
我会说他们是相互竞争的好伙伴，但没有一个人对预处理器持蜡烛。
所以，一个新的预处理器的建议会很棒。
Hard to see how this is going to be about C++ libraries, but I''ll
follow along.
Today Boost uses a "preprocessor library", which in turn (please
correct me if my understanding is wrong) relies on a program to
generate some many big macros up to a fixed "maximum" to overcome
preprocessor''s incapability to deal with variable number of
arguments.
That''s a pretty jumbled understanding of the situation.
The preprocessor library is a library of headers and macros that allow
you to generate C/C++ code by writing programs built out of macro
invocations. You can see the sample appendix at
http://www.boost-consulting.com/mplbook for a reasonably gentle
introduction.
In the preprocessor library''s _implementation_, there are lots of
boilerplate program-generated macros, but that''s an implementation
detail that''s only needed because so many preprocessors are badly
nonconforming. In fact, the library''s maintainer, Paul Mensonides,
has a _much_ more elegantly-implemented PP library
(http://sourceforge.net/projects/chaos-pp/) that has almost no
boilerplate, but it only works on a few compilers (GCC among them).
There is no way to "overcome" the PP''s incapability to deal with
variable number of arguments other than by using PP data structures as
described in http://boost-consulting.com/mplbook/preprocessor.html to
pass multiple items as a single macro argument, or by extending the PP
to support variadic macros a la C99, as the committee is poised to do.
The PP library is _often_ used to overcome C++''s inability to support
typesafe function (template)s with variable numbers of arguments, by
writing PP programs that generate overloaded function (template)s.
Also, please correct me if I''m wrong (because I haven''t really
looked deep into it), but my understanding is that people around
Boost see the PP library as a necessary but unpleasantly-smelling
beast that makes things around it smelly as well.
I don''t see it that way, although I wish there were ways to avoid
using it in some of the more common cases (variadic template). Maybe
some others do see it like that.
[Reminds me of the Romanian story: there was a guy called Pepelea
(pronounced Peh-Peh-leah) who was poor but had inherited a beautiful
house. A rich man wanted to buy it, and Pepelea sold it on one
condition: that Pepelea owns a nail in the living room''s wall, in
which he can hang whatever he wanted. Now when the rich man was
having guests and whatnot, Pepelea would drop by and embarraisingly
hang a dirty old coat. Of course in the end the rich man got so
exasperated that he gave Pepelea the house back for free. Ever since
that story, "Pepelea''s nail" is referred to as something
like... like what the preprocessor is to the C++ language.]
cute.
That would be reason one to create a new C++ preprocessor. (And when
I say "new," that''s not like in "yet another standard C++
preprocessor". I have been happy to see my suggestion on the Boost
mailing list followed in that the WAVE preprocessor was built using
Boost''s own parser generator library, Spirit.) What I am talking now
is "a backwards-INcompatible C++ preprocessor aimed at displacing
the existing preprocessor forever and replacing it with a better
one".
Bjarne''s plan for that is to gradually make the capabilities of the
existing PP redundant by introducing features in the core
language... and then, finally, deprecate it.
If backed by the large Boost community, the new preprocessor could
easily gain popularity and be used in new projects instead of the
old one.
I doubt even with Boost backing that the community at large is likely
to easily accept integrating another tool into its build processes.
The big advantage of the C++ PP is that it''s built-in... and that''s
one of the biggest reasons that the PP _lib_ is better for my purposes
than any of the ad hoc code generators I''ve written/used in the past.
To avoid inheriting past''s mistakes, the new preprocessor
doesn''t need to be syntax-compatible in any way with the old
preprocessor, but only functionally compatible, in that it can do
all that can be done with the existing preprocessor, only that it
has new means to do things safer and better.
I think Bjarne''s approach is the best way to do that sort of
replacement. As long as the PP''s functionality is really being
replaced by a textual preprocessor (or a token-wise one as we have
today) it''s going to suffer many of the same problems. Much of those
jobs should be filled by a more robust metaprogramming system that''s
fully integrated into the language and not just a processing phase.
I think that would be great. Because it we all stop coding for a
second and think of it, what''s the ugliest scar on C++''s face - what
is Pepelea''s nail? Maybe "export" which is so broken and so useless
and so abusive that its implementers have developed Stockholm
syndrome during the long years that took them to implement it?
That''s slander ;->. Export could be used to optimize template
metaprograms, for example (compile the templates to executable code
that does instantiations). It may not have been a good idea, but
those who suffered through implementing it now think it has some
potential utility.
Maybe namespaces that are so badly designed, you''d think they are
inherited from C?
Wow, I''m impressed; that''s going to piss off both the hardcore C _and_
C++ people!
I''ve never seen a serious proposal for better namespaces, other than
http://boost-consulting.com/writing/qn.html, which seems to have been
generally ignored. Have you got any ideas?
I''d say they are good contenders against each other, but none of
them holds a candle to the preprocessor.
So, a proposal for a new preprocessor would be great.
如果这是你的观点，我认为这是一个有趣的，但不知怎的，我
仍然没有得到如何适合C ++的工作坊
库。
-
Dave Abrahams
Boost Consulting
http ：//www.boost-consulting.com
[见 http://www.gotw.ca/resources/clcm.htm 有关的信息]
[comp.lang.c ++。moderated。第一次海报：做到这一点！ ]
If that''s your point, I think it''s an interesting one, but somehow I
still don''t get how it could be appropriate for a workshop on C++
libraries.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
这篇关于2004年OOPSLA的Boost研讨会的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
