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! ]
Jul 22 '05
205  10418 
Gabriel Dos Reis wrote: I think that use of "inline" is unfortunate. I don't think that
description accurately covers what CFront did and other historical
repository-based instantiations (like in old Sun CC).
That's not relevant to the language defined by the standard.
In standard C++, either a template method is marked by export,
or it must be included in every compilation unit that would
instantiate it. That is exactly the model of inline - an inline
method must be defined in every compilation unit that calls it.
Export is the result of a compromise. A compromise between tenants of
inclusion model only and tenants of separate compilation of templates.
Every aspect of the language has interesting historical background
that is largely irrelevant to undertanding how to use it. I think
export just got a bum rap because no one bothered to implement it
because you could get along without it and there were other fish to
fry.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Walter wrote: Export was simply not needed to speed up compilation
That's fine, because that's not what it's for.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Gabriel Dos Reis" <gd*@integrable-solutions.net> wrote in message
news:m3************@uniton.integrable-solutions.net... "Andrei Alexandrescu \(See Website for Email\)"
<Se****************@moderncppdesign.com> writes:
| "Daveed Vandevoorde" <go****@vandevoorde.com> wrote in message
| news:52**************************@posting.google.c om...
| > "Andrei Alexandrescu wrote:
| > [...]
| > > 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?
| >
| > How is "export" useless and broken?
| >
| > Have you used it for any project? I find it very pleasant
| > to work with in practice.
|
| Haven't used export, and not because I didn't wanna.
Very interesting.
Well, it's very banal really. I just only had the chance to use compilers
that don't implement export.
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Hyman Rosen <hy*****@mail.com> writes:
| Gabriel Dos Reis wrote:
| > I think that use of "inline" is unfortunate. I don't think that
| > description accurately covers what CFront did and other historical
| > repository-based instantiations (like in old Sun CC).
|
| That's not relevant to the language defined by the standard.
Here is a piece that disappeared in your reply and that makes the
above statement the most relevant as a reply to your earlier message:
Because of historical reasons having to do with how templates are
implemented, template methods (and static data members) are
effectively considered inline, and so their definitions must be
included in any compilation unit which requires an instantiation.
If you believe "historical reasons" to be not relevant to the language
defined by the standard, why did you bring them in ther first place?
--
Gabriel Dos Reis gd*@integrable-solutions.net
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Andrei Alexandrescu (See Website for Email) wrote: Templates cannot be meaningfully typechecked during their compilation. They
also cause complications when instantiated in different contexts. That makes
them unsuitable for "true" separate compilation. Slapping a keyword that
makes them appear as separately compilable while the true inside the
compilation system guts is different (in terms of dependency management and
compilation speed) didn't help.
There have been environments in which the linker did whole-program
optimization, inlining routines out of object files into the call
sites. I think you are mistaken in concept when you try to peer under
the hood of the compiler to call some of its operations "true" and
some not. Step back and think of nothing but the point of view of
the user. Also consider that while extremely complex cases of
instantiation must be handled correctly by the compiler, most actual
templates that people write don't have weird name-capturing problems.
The export user sees method implementations compiled separately in an
implementation source file, and declarations included by header in
compilation units that need the methods. For the user, this appears
to work just like non-template code.
I don't think that that's a good parallel. Because the non-inline functions
can be typechecked and compiled to executable code in separation. Templates
cannot.
You are thinking of this from a compiler writer's perspective.
From a user's perspective, he submits the code to a compiler
and gets an executable out. Without export, the implementation
must be included in the places where it's called, subjecting it
to the vagaries of that environment. That's a pain.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Hyman Rosen <hy*****@mail.com> wrote in message news:<YEfVc.7145$si.4688@trndny06>... Jerry Coffin wrote: I don't believe that export, as currently defined, actually supports this though.
Why don't you believe it?
Because I see the same things you seem to want to ignore.
What is it about export that you think would prevent
a compiler vendor from doing just that? Obviously compiled templates act as
further input to the "compiler" rather than to the "linker" (assuming those
distinctions exist), but what of that?
In the end, such distinctions DO exist, and they exist for what many
people clearly consider very good reasons -- specifically that they
provide real benefits. I believe the expectation of most people was
that export would provide the same or similar benefits, but I don't
believe they do so.
Worse, your defense of export seems backward to me: you claim to be
recieving the benefits of export even with a backend that doesn't
support it. That sounds to me like the benefits don't really come from
export at all. 3. export failed miserably at being reasonably easy to implement.
I can hardly imagine how anybody could argue that one.
Who said it was supposed to be easy? Templates aren't easy, exceptions
aren't easy, manipulating vtable pointers during construction isn't easy.
The wording was "reasonably easy", not just easy.
Reasonable in this sort of usage normally implies one or both of two
things: 1) that it's roughly in line with what was expectd, and 2)
that the benefits are sufficient to justify the cost.
I'm not on the committee myself, but I've certainly conversed with a
number of committee members, and ALL of them I've talked to have
admitted that export has turned out to be substantially more difficult
to implement than was expected.
So far, few people who've really used export seem to have found
tremendous benefits to it either.
By contrast, nobody seems to have been terribly surprised by the
amount of work it has taken to implement exception handling, and most
people seem to believe that its benefits are justify the work.
The area where exception handling may have surprised some people
and/or had unjustified costs is not in its implementation, but the
burden for exception safety that's placed on the user. Though few
people seem to be aware of it (yet), export has a similar effect -- it
affects name lookup in ways most people don't seem to expect, and can
substantially increase the burden on the user.
So, if you'd prefer, I'd rephrase the question: as I recall, it's
claimed that EDG put something like three man-years of labor into
implementing export, and that's not all it takes to implement it
either. So far even if we take ALL the users into account, I've yet to
see an indication that anybody has saved three man-years of labor
because export was there. That seems to indicate that at this point,
export is a net loss.
The next obvious question would be at what point export breaks even.
At this point, the benefits are sufficiently tenuous that I'm not at
all sure anybody can really guess at the time, or even state with any
certainty that there will ever BE such a time.
--
Later,
Jerry.
The universe is a figment of its own imagination.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Hyman Rosen" <hy*****@mail.com> wrote in message
news:TWeVc.7135$si.3217@trndny06... Walter wrote: > That same design makes it *very hard* to do separate compilation for
templates, > no matter how conceptually the same we might wish them to be. Just because it's hard for compiler makers doesn't mean it's hard for
compiler users. Indeed, I find the inclusion model for templates to
be difficult and annoying and find export to be perfectly intuitive.
I find:
import foo;
to be far more natural and intuitive than:
#include "foo.h"
(and I don't even have to write a .h file), but the inclusion model is what
C++ is, and export doesn't fix that. If C++ had gone a step further than
export, and offered true modules, I suspect it would have been a lot easier
to implement.
> its advantages must outweigh the costs. The costs of export are
enormous, and the > corresponding enormous gain just isn't there.
Export imposes no cost at all on programmers. It's a simple concept and
simple to use.
Oh, the costs imposed on programmers are very high. The cost is in terms of
years of delay, deferring of the arrival of other improvements, shrinking
the number of independent C++ implementations, etc.
Compiler vendors for the most part can't be bothered to implement it,
because everyone uses the inclusion model because they have to.
The reason why is it takes 2 to 3 man years to implement. This wouldn't be
an issue at all if it were just a matter of bothering to implement it.
> Why not use a named namespace?
Because then the inclusion model would violate the ODR, unless I prepare
*another* source file with the implementation of those gloabl functions that my
template methods want to call.
I must apologize, because I'm just not getting why namespaces won't work or
what this has to do with the ODR.
Why should I jump through hoops when the standard give me a perfectly
simple way not to?
If export is the only improvement you want from existing C++ compilers,
that's fine. But I find it hard to believe there aren't other things you'd
be interested in having, like better templates, fewer bugs, better
optimization, better libraries, a lower price, better support, nicer IDE,
better debuggers, etc. What are you willing to give up to get export, and
what have you given up for it?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Hyman Rosen" <hy*****@mail.com> wrote in message
news:PafVc.7138$si.4782@trndny06... Walter wrote: > Export was simply not needed to speed up compilation
That's fine, because that's not what it's for.
I apologize, I assumed that's what you meant when you talked about
"laboring" under the inclusion model. It's repeatedly listed as one of the 3
justifications for exports, and not just by myself. Daveed Vandevoorde
listed them in his post in this thread:
---------------------------------------------------------------------
The intent of the feature was to protect template definitions from
"name leakage" (I think that's the term that was used at the time;
it refers to picking up unwanted declaration due to excessive
#inclusion). export certainly fulfills that.
export also allows code to be compiled faster. (I'm seeing gains
without even using an export-aware back end.)
export also allows the distribution of templates in compiled form
(as opposed to source form).
----------------------------------------------------------------------
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Hyman Rosen" <hy*****@mail.com> wrote in message
news:YEfVc.7145$si.4688@trndny06... 3. export failed miserably at being reasonably easy to implement.
I can hardly imagine how anybody could argue that one.
Who said it was supposed to be easy? Templates aren't easy, exceptions
aren't easy, manipulating vtable pointers during construction isn't easy.
2 to 3 man years to implement is quite another level of "easy". It's
extremely costly to implement, costly to users as well as vendors.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
On 19 Aug 2004 21:31:41 -0400, go****@vandevoorde.com (Daveed
Vandevoorde) wrote: export also allows the distribution of templates in compiled form
(as opposed to source form).
This I would love to hear about. What do compiled templates look like?
I hope commercial pressures don't prevent you from replying.
Are compiled templates easily decompiled (assuming the file format is
not obscure)? How much source information can be thrown away in
compiling them?
After EDG implemented export, Stroustrup once asked what change to
C++ might simplify its implementation without giving up on the separate
compilation aspect of it. I couldn't come up with anything other than the
very drastic notion of making the language 100% modular (i.e., every entity
can be declared in but one place).
That is exactly the same conclusion that I have reached (intuitively
rather than through experience or careful working through of the
problem); separate compilation of templates within the usual C++ TU
model pretty much leads you to two phase name lookup and export.
Tom
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
On 20 Aug 2004 06:04:04 -0400, "Andrei Alexandrescu \(See Website for
Email\)" <Se****************@moderncppdesign.com> wrote: "Jerry Coffin" <jc*****@taeus.com> wrote in message
news:b2*************************@posting.google.c om... 2. export failed horribly at doing what was initially supposed to do. I
believe what it was supposed to do was true (not "when"s and "cough"s and
"um"s) separate compilation of templates. Admittedly, gaffes in other
areas
of language design are at fault for that failure. Correct me if I'm
wrong.
I don't know how much is true gaffes, and how much the simple fact
that templates are enough different from normal code that what was
expected was simply (at least extremely close to) impossible.
Fundamentally templates are sensitive to the point where they are
instantiated, and not on the parameters alone. That's a classic PL design
mistake because it undermines modularity. The effects of such a mistake are
easily visible :o). They've been visible in a couple of early languages as
well.
The alternative is to simply not have any kind of separate compilation
of templates. So we could drop two phase name lookup, "template" and
"typename" disambiguators, and possibly some other nasty features,
basically moving to the basic template inclusion model implemented by
old Borland and Microsoft compilers (except without the bugs!)
Hmm. It was simpler back then; I think two phase name lookup is still
extremely badly understood, as are the merits and otherwise of export.
(How many people realise that point-of-instantiation lookup of
function names uses ADL only, and not ordinary lookup?)
Tom
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Andrei Alexandrescu \(See Website for Email\)" <Se****************@moderncppdesign.com> writes:
| "Gabriel Dos Reis" <gd*@integrable-solutions.net> wrote in message
| news:m3************@uniton.integrable-solutions.net...
| > "Andrei Alexandrescu \(See Website for Email\)"
| > <Se****************@moderncppdesign.com> writes:
| >
| > | "Daveed Vandevoorde" <go****@vandevoorde.com> wrote in message
| > | news:52**************************@posting.google.c om...
| > | > "Andrei Alexandrescu wrote:
| > | > [...]
| > | > > 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?
| > | >
| > | > How is "export" useless and broken?
| > | >
| > | > Have you used it for any project? I find it very pleasant
| > | > to work with in practice.
| > |
| > | Haven't used export, and not because I didn't wanna.
| >
| > Very interesting.
|
| Well, it's very banal really. I just only had the chance to use compilers
| that don't implement export.
What I found very interesting is not the fact that you used compilers
that don't implement export. What I found interesting is that you
made such strong statements based on no actual experience, as you
confessed. I'm not saying it is bad. Just very interesting.
--
Gabriel Dos Reis gd*@integrable-solutions.net
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
tom_usenet <to********@hotmail.com> writes:
[...]
| Hmm. It was simpler back then; I think two phase name lookup is still
| extremely badly understood, as are the merits and otherwise of export.
I just wanted to remind that two-phase name lookup has been being
discussed looong before "export" came into the picture.
--
Gabriel Dos Reis gd*@integrable-solutions.net
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"tom_usenet" <to********@hotmail.com> wrote in message
news:7p********************************@4ax.com... The alternative is to simply not have any kind of separate compilation
of templates. So we could drop two phase name lookup, "template" and
"typename" disambiguators, and possibly some other nasty features,
basically moving to the basic template inclusion model implemented by
old Borland and Microsoft compilers (except without the bugs!)
Hmm. It was simpler back then; I think two phase name lookup is still
extremely badly understood, as are the merits and otherwise of export.
(How many people realise that point-of-instantiation lookup of
function names uses ADL only, and not ordinary lookup?)
How it works in D is pretty simple. The template arguments are looked up in
the context of the point of instantiation. The symbols inside the template
body are looked up in the context of the point of definition. It's how you'd
intuitively expect it to work, as it works analogously to ordinary function
calls.
I say "point" of instantiation/definition, but since D symbols can be
forward referenced, it's more accurate to say "scope" of
instantiation/definition. Isn't it odd that C++ class scopes can forward
reference member symbols, but that doesn't work at file scope?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
tom_usenet wrote in news:7p********************************@4ax.com in
comp.lang.c++:
The alternative is to simply not have any kind of separate compilation
of templates.
So we could drop two phase name lookup,
2 phase lookup, allows us to write determinate code (*), I really don't
see what it has to do with seperate compilation, if anything, its a
feature that makes export harder (the exported code wouldn't need
to remeber the declaration context).
*) By this I mean code that does what the author of the code
intended and is subject to the minimum possible reinterpretation
at the point of instantiation.
"template" and
Which "template", do you mean the .template, if so this is a
parsing problem, the parser preferes < to mean "less-than" over
"template-argument-list", It could be solved with some bactraking
(I think :), but we would loose: "if ( 0 < i > 0 ) ... ".
Or do you want code that is sometimes a member template or sometimes
a non template member ?
"typename" disambiguators,
Again AIUI typename is about writing determinate code.
and possibly some other nasty features,
basically moving to the basic template inclusion model implemented by
old Borland and Microsoft compilers (except without the bugs!)
Hmm. It was simpler back then; I think two phase name lookup is still
extremely badly understood, as are the merits and otherwise of export.
It was simpler, but also very confusing, the behaviour of you code
depended on when you instantiated you templates. Everyting worked untill
it it stoped working and then things just got strange (atleast thats how
I remember it :).
(How many people realise that point-of-instantiation lookup of
function names uses ADL only, and not ordinary lookup?)
Not enough, but we haven't had meny compilers that get this right,
so I think that will change.
Rob.
-- http://www.victim-prime.dsl.pipex.com/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Walter" <wa****@digitalmars.nospamm.com> writes:
[...]
| I say "point" of instantiation/definition, but since D symbols can be
| forward referenced, it's more accurate to say "scope" of
| instantiation/definition. Isn't it odd that C++ class scopes can forward
| reference member symbols, but that doesn't work at file scope?
Why should I find that odd?
--
Gabriel Dos Reis gd*@integrable-solutions.net
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Hyman Rosen <hy*****@mail.com> writes: Andrei Alexandrescu (See Website for Email) wrote: Templates cannot be meaningfully typechecked during their compilation. They
also cause complications when instantiated in different contexts. That makes
them unsuitable for "true" separate compilation. Slapping a keyword that
makes them appear as separately compilable while the true inside the
compilation system guts is different (in terms of dependency management and
compilation speed) didn't help.
There have been environments in which the linker did whole-program
optimization, inlining routines out of object files into the call
sites. I think you are mistaken in concept when you try to peer under
the hood of the compiler to call some of its operations "true" and
some not. Step back and think of nothing but the point of view of
the user. Also consider that while extremely complex cases of
instantiation must be handled correctly by the compiler, most actual
templates that people write don't have weird name-capturing problems.
Doesn't that tend to argue that export isn't solving a real problem?
--
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! ]
"Gabriel Dos Reis" <gd*@integrable-solutions.net> wrote in message
news:m3************@uniton.integrable-solutions.net... "Walter" <wa****@digitalmars.nospamm.com> writes:
[...]
| I say "point" of instantiation/definition, but since D symbols can be
| forward referenced, it's more accurate to say "scope" of
| instantiation/definition. Isn't it odd that C++ class scopes can forward
| reference member symbols, but that doesn't work at file scope?
Why should I find that odd?
It's inconsistent. If I can do:
class Foo
{ int abc() { return x; } // fwd reference ok
int x;
}
why can't I do in C++:
int abc() { return x; } // error, x is undefined
int x;
?? (You can do that in D.) Furthermore, if forward references worked at file
scope, some of the confusing arcana of template instantiation lookup rules
would be unnecessary.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Andrei Alexandrescu (See Website for Email) wrote: Definitely. It is a wholly different language.
Not it only remains for me to convince you that that's a disadvantage
:o).
I'll rephrase slightly. The preprocessor (macro expansion in particular) is a
wholly different language. The primitives used are low-level library elements
used to implement the solution directly. It is possible to make the resulting
syntax cleaner by using higher-level constructs.
That said, along some lines I agree that having a different language is a
disadvantage. Along others I don't. A different language exercises the brain
and promotes new ways of doing things.
I disagree it's only syntactic cleanliness. Lack of syntactic
cleanliness is the CHAOS_PP_ that you need to prepend to most of your
library's symbols. But let me pull the code again:
#define REPEAT(count, macro, data) \
REPEAT_S(CHAOS_PP_STATE(), count, macro, data) \
/**/
#define REPEAT_S(s, count, macro, data) \
REPEAT_I( \
CHAOS_PP_OBSTRUCT(), CHAOS_PP_NEXT(s), \
count, macro, data \
) \
/**/
#define REPEAT_INDIRECT() REPEAT_I
#define REPEAT_I(_, s, count, macro, data) \
CHAOS_PP_WHEN _(count)( \
CHAOS_PP_EXPR_S _(s)(REPEAT_INDIRECT _()( \
CHAOS_PP_OBSTRUCT _(), CHAOS_PP_NEXT(s), \
CHAOS_PP_DEC(count), macro, data \
)) \
macro _(s, CHAOS_PP_DEC(count), data) \
) \
/**/
As far as I understand, REPEAT, REPEAT_S, REPEAT_INDIRECT, REPEAT_I,
and the out-of-sight CHAOS_PP_STATE, CHAOS_PP_OBSTRUCT,
CHAOS_PP_EXPR_S are dealing with the preprocessor alone and have zero
relevance to the task.
First, REPEAT and REPEAT_S are interfaces, one being lower-level than the other.
REPEAT_INDIRECT and REPEAT_I are implementation macros of the REPEAT interface.
REPEAT_INDIRECT isn't even necessary, I used it to be clearer. CHAOS_PP_STATE,
CHAOS_PP_OBSTRUCT, and CHAOS_PP_EXPR_S are primitives used to implement
bootstrapped recursion.
The others implement an idiom for looping that
I'm sure one can learn, but is far from familiar to a C++ programmer.
Yes, it is far from familiar--which is both good and bad.
To say that that's just a syntactic cleanliness thing is a bit of a
stretch IMHO. By the same argument, any Turing complete language will
do at the cost of "some" syntactic cleanliness.
For the most part, the difference is syntactic cleanliness. Without the
boilerplate required for recursion, the primary implementation macro becomes:
#define REPEAT_I(count, macro, data) \
CHAOS_PP_WHEN(count)( \
REPEAT_I(CHAOS_PP_DEC(count), macro, data) \
macro(CHAOS_PP_DEC(count), data) \
) \
/**/
Which is really not much different than any higher-order construct:
(defun repeat (count function data)
(unless (zerop count)
(repeat (1- count) function data)
(funcall function (1- count) data)))
; e.g.
(repeat 10
#'(lambda (count data)
(unless (zerop count)
(format t ", "))
(format t "~a~a" data count))
"class T")
But the preprocessor *is* adequate for the task. It just isn't as
syntactically
clean as you'd like it to be.
I maintain my opinion that we're talking about more than syntactic
cleanliness here. I didn't say the preprocessor is "incapable" for
the task. But I do believe (and your code strengthened my belief)
that it is "inadequate". Now I looked on www.m-w.com and I saw that
inadequate means " not adequate : INSUFFICIENT; also : not capable " and that adequate
means
"sufficient for a specific requirement" and "lawfully and reasonably
sufficient". I guess I meant it as a negation of the last meaning,
and even that is a bit too strong. Obviously the preprocessor is
"capable", because hey, there's the code, but it's not, let me
rephrase - very "fit" for the task.
The preprocessor is not designed for the task. Obviously it isn't ideal. The
difference is not just syntactic. There are also idioms that go with it. Even
so, those idioms are straightforward when you're familiar with the language and
become a relatively small amount of boilerplate and syntactic clutter.
Wouldn't it be nicer if you just had one mechanism (true recursion or
iteration) that does it all in one shot?
Yes, it would, but it isn't at the top of my list because I can already simulate
it in a plethora of ways. There are other things that I cannot do that are more
important to me.
Regards,
Paul Mensonides
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Paul Mensonides wrote: That said, along some lines I agree that having a different language is a
disadvantage. Along others I don't. A different language exercises the brain
and promotes new ways of doing things.
I'd be the first to agree with that. But isn't it preferrable to have
a good new language to start with and think up from that, instead of
having a poor new language that asks you to do little miracles to get
the most basic things done?
To say that that's just a syntactic cleanliness thing is a bit of a
stretch IMHO. By the same argument, any Turing complete language will
do at the cost of "some" syntactic cleanliness.
For the most part, the difference is syntactic cleanliness. Without the
boilerplate required for recursion, the primary implementation macro becomes:
#define REPEAT_I(count, macro, data) \
CHAOS_PP_WHEN(count)( \
REPEAT_I(CHAOS_PP_DEC(count), macro, data) \
macro(CHAOS_PP_DEC(count), data) \
) \
/**/
Well if one removes some boilerplate code, C can do virtuals and
templates. That doesn't prove a lot.
I saw only convoluted code in the URL that Dave forwarded. I asked for
a good example here on the Usenet. You gave me an example. I commented
on the example saying that it drowns in details. Now you're telling me
that "if you remove the details in which the example is drowning" it
doesn't drown in them anymore. Well ok :o).
The preprocessor is not designed for the task. Obviously it isn't ideal. The
difference is not just syntactic. There are also idioms that go with it. Even
so, those idioms are straightforward when you're familiar with the language and
become a relatively small amount of boilerplate and syntactic clutter.
Wouldn't it be nicer if you just had one mechanism (true recursion or
iteration) that does it all in one shot?
Yes, it would, but it isn't at the top of my list because I can already simulate
it in a plethora of ways. There are other things that I cannot do that are more
important to me.
That's reasonable. I just tried to give that as an example. Given that
there *are* things that you cannot do, I was hoping to increase your
(and others') motivation to look into ideas for a new preprocessor.
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] jc*****@taeus.com (Jerry Coffin) writes: Hyman Rosen <hy*****@mail.com> wrote in message news:<YEfVc.7145$si.4688@trndny06>... Jerry Coffin wrote:
[snip] I'm not on the committee myself, but I've certainly conversed with a
number of committee members, and ALL of them I've talked to have
admitted that export has turned out to be substantially more difficult
to implement than was expected.
And yet, they shot down Herb's proposal to remove it, 28 in favor of
keeping it, 8 against. (See
http://www.open-std.org/jtc1/sc22/wg...003/n1459.html)
Those in favor of keeping it included major implementors that don't
yet support it.
So far, few people who've really used export seem to have found
tremendous benefits to it either.
By contrast, nobody seems to have been terribly surprised by the
amount of work it has taken to implement exception handling, and most
people seem to believe that its benefits are justify the work.
The area where exception handling may have surprised some people
and/or had unjustified costs is not in its implementation, but the
burden for exception safety that's placed on the user. Though few
people seem to be aware of it (yet), export has a similar effect -- it
affects name lookup in ways most people don't seem to expect, and can
substantially increase the burden on the user.
I think most of those effects come not from export but from two-phase
lookup.
So, if you'd prefer, I'd rephrase the question: as I recall, it's
claimed that EDG put something like three man-years of labor into
implementing export, and that's not all it takes to implement it
either. So far even if we take ALL the users into account, I've yet to
see an indication that anybody has saved three man-years of labor
because export was there.
[snip]
If export took 1095 days to implement, and there are 10000 users of
export, each of them need only save one hour, and export is a net
win for the community.
I don't know if there are 10000 users of export, but one thing people
seem to keep ignoring in all this cost/benefit discussion is the
sheer size if the C++ community; a feature can be extrodinarily
expensive for implementors, and yet be a net win even it is only
a small savings for each individual user.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Andrei Alexandrescu (See Website for Email)"
<se****************@moderncppdesign.com> wrote in message
news:41**************@moderncppdesign.com... Paul Mensonides wrote: That said, along some lines I agree that having a different language is a
disadvantage. Along others I don't. A different language exercises the
brain and promotes new ways of doing things.
I'd be the first to agree with that. But isn't it preferrable to have
a good new language to start with and think up from that, instead of
having a poor new language that asks you to do little miracles to get
the most basic things done?
From an immediate productivity standpoint, yes. However, there are a lot of
ways that people think about code (in C++ for example) explicitly because of a
lack of direct language facility. Look at template metaprogramming for example
or SFINAE manipulation. Those things could be implemented better with direct
support from the language, but something beyond that or something completely
different won't be. Because of the kind of thinking that those existing
solutions engender, those other things may not be unreachable. Removing
boilerplate or indirect hacks by adding language features is a neverending
story. Granted, something like recursion is very basic, but then, there are
things that can be done because of the lack of recursion (e.g. I use it to
compare identifiers among other things). As I'm sure that you understand, doing
much with little is also satisfying in its own right. Besides, the "little
miracles" required can be hidden behind a library interface, as Chaos does. I
told you that that was basically doing it by hand. Here's a more high-level
variant:
#define TYPELIST(...) \
CHAOS_PP_EXPR(CHAOS_PP_TUPLE_FOLD_RIGHT( \
TYPELIST_OP, (__VA_ARGS__), Loki::NilType \
)) \
/**/
#define TYPELIST_OP(s, type, ...) \
Loki::Typelist<CHAOS_PP_DECODE(type), __VA_ARGS__> \
/**/
Though there is some, there isn't a lot of boilerplate here. Note also that
this itself is a library interface, and the ultimate boilerplate clutter is all
but gone when user's use the interface. The only relic that you have is that
you have to parenthesize types that contain open commas--which is insignificant.
TYPELIST(int, double, char)
It is also important to note the fundamental thing that is important. This
implementation, along with reusable library abstractions, regardless of
boilerplate, requires only about ten lines of code and completely replaces at
least fifty lines of really ugly repetition (i.e. the TYPELIST_x macros). Note
only does it replace it, but it expands the upper limit from fifty types to
about five thousand types--effectively removing any impact from the limit.
Well if one removes some boilerplate code, C can do virtuals and
templates. That doesn't prove a lot.
No, it doesn't, nor is it meant to. I'm merely pointing out that the
boilerplate is simple when you know what you are doing. It doesn't even get
close to "drowning in details".
I saw only convoluted code in the URL that Dave forwarded.
Which URL was that? If Boost, then the code is drowning in workarounds. If
Chaos, then much of the code you saw is doing much more advanced things than
users need to ever see or do.
I asked for
a good example here on the Usenet. You gave me an example. I commented
on the example saying that it drowns in details. Now you're telling me
that "if you remove the details in which the example is drowning" it
doesn't drown in them anymore. Well ok :o).
What I was saying is that the details in that it "drowns in", as you put it, are
nothing but boilerplate. Boilerplate is basically syntactic clutter that you
relatively easily learn to ignore when reading and writing code. The preprocessor is not designed for the task. Obviously it isn't ideal.
The difference is not just syntactic. There are also idioms that go with it.
Even so, those idioms are straightforward when you're familiar with the language
and become a relatively small amount of boilerplate and syntactic clutter.
Wouldn't it be nicer if you just had one mechanism (true recursion or
iteration) that does it all in one shot?
Yes, it would, but it isn't at the top of my list because I can already
simulate it in a plethora of ways. There are other things that I cannot do that are
more important to me.
That's reasonable. I just tried to give that as an example. Given that
there *are* things that you cannot do, I was hoping to increase your
(and others') motivation to look into ideas for a new preprocessor.
To be more accurate, there is no code that cannot be generated. It is only a
question of how clean it is and whether it is clean enough to be an acceptable
solution.
As far as a new preprocessor is concerned, I just don't think that it will
happen. I do like the idea of a new kind of macro that can be recursive. That
is the main limitation preventing your imaginary sample syntax. Lack of
backlashes or overloading is insignificant compared to that. Even so, the
ability to process tokens individually, regardless of the type of preprocessing
token, is far more important than any of those, because with that ability you
can make interpreters for any syntax that you like--including advanced
domain-specific languages. (For example, consider a parser generator that
operates directly on grammar productions rather than encoded grammar
productions.) Such an ability would promote C++ to a near intentional
environment.
Regards,
Paul Mensonides
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
On 21 Aug 2004 12:00:50 -0400, Rob Williscroft <rt*@freenet.co.uk>
wrote: tom_usenet wrote in news:7p********************************@4ax.com in
comp.lang.c++:
The alternative is to simply not have any kind of separate compilation
of templates. So we could drop two phase name lookup,
2 phase lookup, allows us to write determinate code (*), I really don't
see what it has to do with seperate compilation, if anything, its a
feature that makes export harder (the exported code wouldn't need
to remeber the declaration context).
*) By this I mean code that does what the author of the code
intended and is subject to the minimum possible reinterpretation
at the point of instantiation.
It is necessary for export though.
int helper(); //internal to definition.cpp
export template<class T>
void f()
{
helper(); //want to lookup in definition context!
}
That doesn't work without two-phase name lookup. I don't think two
phase name lookup is vital otherwise, since if the inclusion model is
used, names used in the template definitions can be made visible
simply by putting the definitions before the point of instantiation
(as is usually the case anyway).
The determinate code is a secondary issue, and I think a rare problem;
impl namespaces are generally employed to make sure internal template
gubbins won't be replaced by stuff from the point of instantiation. "template" and
Which "template", do you mean the .template, if so this is a
parsing problem, the parser preferes < to mean "less-than" over
"template-argument-list", It could be solved with some bactraking
(I think :), but we would loose: "if ( 0 < i > 0 ) ... ".
Or do you want code that is sometimes a member template or sometimes
a non template member ?
"typename" disambiguators,
Again AIUI typename is about writing determinate code.
It's also about allowing the compiler to pre-parse and syntax check
templates even if they aren't instantiated. I don't think it is a
common problem that someone passes something that evaluates to a
static member where a type was expected! template and typename are
annoying at best, and give people new to templates unnecessary (if
export isn't used) headaches. and possibly some other nasty features,
basically moving to the basic template inclusion model implemented by
old Borland and Microsoft compilers (except without the bugs!)
Hmm. It was simpler back then; I think two phase name lookup is still
extremely badly understood, as are the merits and otherwise of export.
It was simpler, but also very confusing, the behaviour of you code
depended on when you instantiated you templates. Everyting worked untill
it it stoped working and then things just got strange (atleast thats how
I remember it :).
This is the case even with two phase lookup, although I agree that
there is slightly less freedom for the template to change meaning at
instantiation time. But I really don't think that this was a common
cause of problems, compared to the errors people get through two-phase
name lookup related issues, was it?
Tom
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] jc*****@taeus.com (Jerry Coffin) writes:
[...]
| So, if you'd prefer, I'd rephrase the question: as I recall, it's
| claimed that EDG put something like three man-years of labor into
| implementing export, and that's not all it takes to implement it
| either.
But duing the period EDG implemented export, they also implemented a
complete Java front-end. It is not like when they were implementing
export, that was the only thing they were doing.
--
Gabriel Dos Reis gd*@integrable-solutions.net
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Walter" <wa****@digitalmars.nospamm.com> wrote in message
news:<UuDVc.161558$8_6.45179@attbi_s04>... "tom_usenet" <to********@hotmail.com> wrote in message
news:7p********************************@4ax.com... > The alternative is to simply not have any kind of separate
> compilation of templates. So we could drop two phase name lookup,
> "template" and "typename" disambiguators, and possibly some other
> nasty features, basically moving to the basic template inclusion
> model implemented by old Borland and Microsoft compilers (except
> without the bugs!)
> Hmm. It was simpler back then; I think two phase name lookup is
> still extremely badly understood, as are the merits and otherwise
> of export. (How many people realise that point-of-instantiation
> lookup of function names uses ADL only, and not ordinary lookup?)
How it works in D is pretty simple. The template arguments are looked
up in the context of the point of instantiation. The symbols inside
the template body are looked up in the context of the point of
definition. It's how you'd intuitively expect it to work, as it works
analogously to ordinary function calls.
I'm not sure I understand this. Do you mean that in something like:
template< typename T >
void
f( T const& t )
{
g( t ) ;
}
g will be looked up in the context of the template definition, where the
actual type of its parameter is not known? And if so, what about :
template< typename Base >
class Derived : public Base
{
public:
void f()
{
this->g() ;
}
} ;
?
I'd say that templates must have the concept of dependent names, which
are looked up at the point of instantiation.
When people argue against two-phase lookup in C++, they are saying first
of all that all names should be considered dependent. And of course,
that dependent name lookup should work exactly like any other name
lookup, and not use special rules.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
llewelly <ll*********@xmission.dot.com> wrote in message news:<86************@Zorthluthik.local.bar>...
[ ... ] > I'm not on the committee myself, but I've certainly conversed with a
> number of committee members, and ALL of them I've talked to have
> admitted that export has turned out to be substantially more difficult
> to implement than was expected.
And yet, they shot down Herb's proposal to remove it, 28 in favor of
keeping it, 8 against.
That's not too surprising, at least to me. First of all, removing a
keyword, feature, etc., from a language is a major step, and the
majority of the committee would have to be convinced that there was a
_major_ benefit from doing so before it would pass.
The reality is that most of them clearly consider the current
situation perectly acceptable: the standard requires export, but
virtually everybody ignores the requirement.
Those in favor of keeping it included major implementors that don't
yet support it.
That's not a major surprise, at least to me. It appears to me that
compiler vendors mostly fall into two camps: those who have already
implemented export, and those who have no plan to do so.
Those who've already implemented export are obviously motivated to
keep it.
Those who haven't mostly don't seem to care and have no plans to
implement it anyway.
The only vendors to whom it would be a major issue would be those who
have not implemented it, but figure they'll have to do so if it
remains in the standard. The vote more or less confirms my opinion
that this group is quite small.
The cost isn't primarily to the vendors -- it's to the users. The big
problem is that export is just the beginning of the proverbial
slippery slope. If full compliance appears achievable, most vendors
will try to achieve it, even if it means implementing a few things
don't really value.
If full compliance appears unachievable, or at least totally
unrealistic, then they're left to their own judgement about what
features to leave out. In this case, those last few features they'd
have implemented for full compliance are likely to be left out.
The result is that for most people, not only is export itself
unusable, but (if they care at all about portability) quite a few
other features are rendered unusable as well.
[ ... ]
> The area where exception handling may have surprised some people
> and/or had unjustified costs is not in its implementation, but the
> burden for exception safety that's placed on the user. Though few
> people seem to be aware of it (yet), export has a similar effect -- it
> affects name lookup in ways most people don't seem to expect, and can
> substantially increase the burden on the user.
I think most of those effects come not from export but from two-phase
lookup.
I'd agree, to some extent -- it just happens that in an inclusion
model, the effects of two-phase name lookup seem relatively natural,
but in an export model they start to seem quite unnatural.
[ ... ]
If export took 1095 days to implement, and there are 10000 users of
export, each of them need only save one hour, and export is a net
win for the community.
First of all, I think this model of the cost is wrong to start with
(about which, see below). Second, even if the model was correct, the
numbers would still almost certainly be wrong: it assumes that the
people who write C++ compilers (specifically those who implement
export) are merely average C++ programmers.
I suspect only a small number of the very best programmers are capable
of implementing export at all. This means considerably _more_ time
needs to be saved than expended to reach the break-even point.
I don't know if there are 10000 users of export, but one thing people
seem to keep ignoring in all this cost/benefit discussion is the
sheer size if the C++ community; a feature can be extrodinarily
expensive for implementors, and yet be a net win even it is only
a small savings for each individual user.
Not really -- to the user, the real cost of export isn't directly
measured in the number of hours it took to implement. The real cost is
the other features that could have been implemented with the same
effort.
As such, for export to work out as a net benefit to the user, we have
to assume that the compiler is close enough to perfect otherwise that
implementing export is the single most efficient use of the
implementors' time.
I doubt that's the case right now, and I don't think I can predict
that it will ever be the case either.
--
Later,
Jerry.
The universe is a figment of its own imagination.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"llewelly" <ll*********@xmission.dot.com> wrote in message
news:86************@Zorthluthik.local.bar... I don't know if there are 10000 users of export, but one thing people
seem to keep ignoring in all this cost/benefit discussion is the
sheer size if the C++ community; a feature can be extrodinarily
expensive for implementors, and yet be a net win even it is only
a small savings for each individual user.
In determining the benefit to users, one must also consider the improvements
to the compiler that are *not done* because of the heavy diversion of
resources to implementing export. A 2 to 3 man-year of implementation effort
should realistically result in a killer feature to be worth it.
Is export really the only improvement you want out of your existing C++
compiler?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Paul Mensonides" <le******@comcast.net> wrote in message
news:Fe********************@comcast.com...
[snip closing points that I agree with]
In an attempt to try to lure you into a discussion on would-be nice
features, here's a snippet from an email exchanged with a friend. It has to
do with the preprocessor distinguishing among tokens and more complex
expressions:
In my vision, a good macro system understands not only tokens, but also
other grammar nonterminals (identifiers, expressions, if-statements,
function-call-expressions, ...)
For example, let's think of writing a nice "min" macro. It should avoid
double evaluation by distinguishing atomic tokens (identifiers or integral
constants) from other expressions:
$define min(token a, token b) {
(a < b ? a : b)
}
$define min(a, b) {
min_fun(a, b)
}
Next we think, how about accepting any number of arguments. So we write:
$define min(token a, b $rest c) {
min(b, min(a, c))
}
$define min(a, b $rest c) {
min(a, min(b, c))
}
The code tries to find the most clever combination of inline operators ?:
and function calls to accomodate any number of arguments. In doing so, it
occasionally moves an identifier around in hope to catch as many identifier
pairs as possible. That's an example of a nice syntactic transformation.
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Walter wrote: In determining the benefit to users, one must also consider the improvements
to the compiler that are *not done* because of the heavy diversion of
resources to implementing export.
Ans pray tell what massive improvements did we see from the vendors who
didn't implement export?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
* Gabriel Dos Reis: "Andrei Alexandrescu \(See Website for Email\)" <Se****************@moderncppdesign.com> writes:
| "Gabriel Dos Reis" <gd*@integrable-solutions.net> wrote in message
| news:m3************@uniton.integrable-solutions.net...
| > "Andrei Alexandrescu \(See Website for Email\)"
| > <Se****************@moderncppdesign.com> writes:
| >
| > | "Daveed Vandevoorde" <go****@vandevoorde.com> wrote in message
| > | news:52**************************@posting.google.c om...
| > | > "Andrei Alexandrescu wrote:
| > | > [...]
| > | > > 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?
| > | >
| > | > How is "export" useless and broken?
| > | >
| > | > Have you used it for any project? I find it very pleasant
| > | > to work with in practice.
| > |
| > | Haven't used export, and not because I didn't wanna.
| >
| > Very interesting.
|
| Well, it's very banal really. I just only had the chance to use compilers
| that don't implement export.
What I found very interesting is not the fact that you used compilers
that don't implement export. What I found interesting is that you
made such strong statements based on no actual experience, as you
confessed. I'm not saying it is bad. Just very interesting.
In this case the "no actual experience" is very relevant; it says that no
compilers available to Andrei A. for project work, implement the feature.
So for all practical purposes the feature must be useless to him.
It certainly is 100% useless to me and anybody I know: we don't have it,
and note that this argument is from lack of experience... ;-)
It's 2004.
The Standard was published in 1998.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Andrei Alexandrescu \(See Website for Email\)" <Se****************@moderncppdesign.com> writes:
[...]
| For example, let's think of writing a nice "min" macro. It should avoid
| double evaluation by distinguishing atomic tokens (identifiers or integral
| constants) from other expressions:
|
| $define min(token a, token b) {
| (a < b ? a : b)
| }
By the end of the day, you may rediscover C++ templates... ;-p
--
Gabriel Dos Reis gd*@integrable-solutions.net
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
tom_usenet wrote in news:vk********************************@4ax.com in
comp.lang.c++.moderated: On 21 Aug 2004 12:00:50 -0400, Rob Williscroft <rt*@freenet.co.uk>
wrote:
tom_usenet wrote in news:7p********************************@4ax.com in
comp.lang.c++:
The alternative is to simply not have any kind of separate
compilation of templates. So we could drop two phase name lookup,
2 phase lookup, allows us to write determinate code (*), I really
don't see what it has to do with seperate compilation, if anything,
its a feature that makes export harder (the exported code wouldn't
need to remeber the declaration context).
*) By this I mean code that does what the author of the code
intended and is subject to the minimum possible reinterpretation
at the point of instantiation.
It is necessary for export though.
int helper(); //internal to definition.cpp
export template<class T>
void f()
{
helper(); //want to lookup in definition context!
}
That doesn't work without two-phase name lookup.
Two-phase lookup does far more than is nessacery though.
All that needs to be done is that the declaration of helper is
remebered during instantiation, there is no need to exclude
overloads (*) that come from the instantiators (**) context.
*) Doesn't apply with the given example, but might for helper( T )
for example.
**) My apologies for making up words, but its hard to remember all the
Standard terms for all this.
I don't think two
phase name lookup is vital otherwise, since if the inclusion model is
used, names used in the template definitions can be made visible
simply by putting the definitions before the point of instantiation
(as is usually the case anyway).
The determinate code is a secondary issue, and I think a rare problem;
We have *very* different experiences :)
impl namespaces are generally employed to make sure internal template
gubbins won't be replaced by stuff from the point of instantiation.
"template" and
Which "template", do you mean the .template, if so this is a
parsing problem, the parser preferes < to mean "less-than" over
"template-argument-list", It could be solved with some bactraking
(I think :), but we would loose: "if ( 0 < i > 0 ) ... ".
Or do you want code that is sometimes a member template or sometimes
a non template member ?
"typename" disambiguators,
Again AIUI typename is about writing determinate code.
It's also about allowing the compiler to pre-parse and syntax check
templates even if they aren't instantiated.
Which is about writing determinate code is it not ?
I don't think it is a
common problem that someone passes something that evaluates to a
static member where a type was expected! template and typename are
annoying at best, and give people new to templates unnecessary (if
export isn't used) headaches.
I agree they are annoying, particularly ".template", there has to be
a better solution:
(* off the top of my head *)
template < typename T >
struct some_class_template
{
template:
/* type must be a typename in *all* specialization's
*/
typename type;
/* get must be a template member-function */
template <> get();
public:
/* specialization things */
};
But we've got what we've got, and I for one think its better
than the pre-standard: "I've no idea what this code does, lets
instantiate it and see".
and possibly some other nasty features,
basically moving to the basic template inclusion model implemented
by old Borland and Microsoft compilers (except without the bugs!)
Hmm. It was simpler back then; I think two phase name lookup is
still extremely badly understood, as are the merits and otherwise of
export.
It was simpler, but also very confusing, the behaviour of you code
depended on when you instantiated you templates. Everyting worked
untill it it stoped working and then things just got strange (atleast
thats how I remember it :).
This is the case even with two phase lookup, although I agree that
there is slightly less freedom for the template to change meaning at
instantiation time.
Its a catch 22, templates are supposed to change meaning, but in an
orderly fashion, the typename and .template cruft aside I think the
committee sucsefully found the middle ground.
But I really don't think that this was a common
cause of problems, compared to the errors people get through two-phase
name lookup related issues, was it?
It was for me, but its entirly possible my experiences wern't typical.
Rob.
-- http://www.victim-prime.dsl.pipex.com/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Andrei Alexandrescu (See Website for Email)"
<Se****************@moderncppdesign.com> wrote in message
news:2o************@uni-berlin.de... Next we think, how about accepting any number of arguments. So we write:
$define min(token a, b $rest c) {
min(b, min(a, c))
}
$define min(a, b $rest c) {
min(a, min(b, c))
}
Sorry, I saw this problem when proofreading my post---I always proofread
after I post :oD.
The above could recurse forever when a and b are both tokens. I meant:
$define min(token a, b $rest c) {
min(b, min(a, c))
}
$define min(a, token b $rest c) {
min(a, min(b, c))
}
$define min(a, b $rest c) {
min(a, min(b, c))
}
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Gabriel Dos Reis" <gd*@integrable-solutions.net> wrote in message
news:m3************@uniton.integrable-solutions.net... jc*****@taeus.com (Jerry Coffin) writes:
| So, if you'd prefer, I'd rephrase the question: as I recall, it's
| claimed that EDG put something like three man-years of labor into
| implementing export, and that's not all it takes to implement it
| either.
But duing the period EDG implemented export, they also implemented a
complete Java front-end. It is not like when they were implementing
export, that was the only thing they were doing.
Daveed Vandevoorde wrote 2002-06-08 in this group:
"As a point of data, it took EDG nearly two years to implement export.
During those two years,
most of our time was spent on export proper; the remaining time was spent on
other stuff (e.g., GNU C compatibility, bug fixes, etc.). Had we not
implemented export, we would have been able to
do many other interesting things and our response to improvement requests
would have been (even :-) better."
and:
in 2004-02-05 in microsoft.public.vc.stl:
"There are three implementors or export (the EDG employees):
I am one of them. I, myself, _am_ claiming that it can be used
that way."
so 3 man-years looks right. Certainly, other vendors can learn from EDG, and
Daveed has shown a willingness to help, and this may reduce the time
necessary. So 2 man-years for someone already competent with the internals
of a C++ compiler is not an unreasonable figure.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Hyman Rosen" <hy*****@mail.com> skrev i meddelandet
news:U2wWc.6759$Ff2.2185@trndny06... Walter wrote: > In determining the benefit to users, one must also consider the
improvements > to the compiler that are *not done* because of the heavy diversion
of > resources to implementing export.
Ans pray tell what massive improvements did we see from the vendors
who didn't implement export?
Managed Extensions, and C++/CLR. Plus the D language. :-)
The resources were obviously available, but somehow the priorities were
not what one could expect.
Bo Persson
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Hyman Rosen" <hy*****@mail.com> wrote in message
news:U2wWc.6759$Ff2.2185@trndny06... Walter wrote: > In determining the benefit to users, one must also consider the
improvements > to the compiler that are *not done* because of the heavy diversion of
> resources to implementing export.
Ans pray tell what massive improvements did we see from the vendors who
didn't implement export?
Microsoft did C++/CLI, for example. Your argument makes sense if C++
compilers are otherwise perfect, merely lacking export, and the
implementation engineers would otherwise just go on vacation for 2 years
<g>. I know that the list of improvements people want in Digital Mars C++
gets added to nearly daily. People want faster compiles, faster generated
code, better debugging, more targets, more platforms, more libraries, etc.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
<ka***@gabi-soft.fr> wrote in message
news:d6**************************@posting.google.c om... "Walter" <wa****@digitalmars.nospamm.com> wrote in message
news:<UuDVc.161558$8_6.45179@attbi_s04>... How it works in D is pretty simple. The template arguments are looked
up in the context of the point of instantiation. The symbols inside
the template body are looked up in the context of the point of
definition. It's how you'd intuitively expect it to work, as it works
analogously to ordinary function calls.
I'm not sure I understand this. Do you mean that in something like:
template< typename T >
void
f( T const& t )
{
g( t ) ;
}
g will be looked up in the context of the template definition, where the
actual type of its parameter is not known? And if so, what about:
template< typename Base >
class Derived : public Base
{
public:
void f()
{
this->g() ;
}
} ;
?
I'd say that templates must have the concept of dependent names, which
are looked up at the point of instantiation.
Think of it this way. In your first example, the argument for T (let's call
it arg) is looked up in the scope of the instantiation. Then, the scope of
the definition of f is loaded. The equivalent of:
typedef arg T;
is executed, which declares T to be of type arg, and the T is installed in
the scope of instantiation. Then, the semantic analysis of f happens in the
scope of the instantiation. T is found using normal lookup rules. It works
just like a function call does, except that the "parameter passing" into the
definition scope happens at compile time rather than run time. The analogous
happens with Base in the second example.
When people argue against two-phase lookup in C++, they are saying first
of all that all names should be considered dependent. And of course,
that dependent name lookup should work exactly like any other name
lookup, and not use special rules.
C++ tries to emulate this behavior with the two-phase lookup rules. But it's
hashed up - did you know you cannot declare a local with the same name as a
template parameter? It follows weird rules like that that are all its own.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
On 24 Aug 2004 02:41:16 -0400, Rob Williscroft <rt*@freenet.co.uk>
wrote: It is necessary for export though.
int helper(); //internal to definition.cpp
export template<class T>
void f()
{
helper(); //want to lookup in definition context!
}
That doesn't work without two-phase name lookup.
Two-phase lookup does far more than is nessacery though.
All that needs to be done is that the declaration of helper is
remebered during instantiation, there is no need to exclude
overloads (*) that come from the instantiators (**) context.
You are basically saying that name lookup could occur uniformly in
both the definition and instantiation contexts (with the contexts
merged), rather than with different rules in the two contexts as is
the case with current two phase name lookup rules. This lookup would
presumably all occur only when the template was instantiated (hence
"typename" would not necessarily be needed). This would be a possible,
but unnamed namespaces and static functions and variables add
complication. e.g.
namespace
{
int helper(); //internal to definition.cpp
}
export template<class T>
void f()
{
helper(); //want to lookup in definition context!
}
The usual fact that there are no name clashes in the anonymous
namespace would no longer hold, since the instantiation context might
also have a helper function. Making the call ambiguous would be
unhelpful, completely defeating the point of anonymous namespaces in
the first place.
One way around the problem would be to ignore names from anonymous
namespaces in the instantiation context, but what if the types used to
instantiate the template are from anonymous namespaces (which is
perfectly legal, since such names have external linkage).
Two phase name lookup solves these problems quite well, but these
problems don't occur at all in the inclusion model.
*) Doesn't apply with the given example, but might for helper( T )
for example.
helper(T) wouldn't be excluded under the current rules. It's also about allowing the compiler to pre-parse and syntax check
templates even if they aren't instantiated.
Which is about writing determinate code is it not ?
I think it's mostly about catching errors (usually just typos)
earlier, so it isn't a user of a template who finds the problem, but
the developer.
Tom
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Andrei Alexandrescu \(See Website for Email\)" <Se****************@moderncppdesign.com> writes:
| "Gabriel Dos Reis" <gd*@integrable-solutions.net> wrote in message
| news:m3************@uniton.integrable-solutions.net...
| > "Andrei Alexandrescu \(See Website for Email\)"
| > <Se****************@moderncppdesign.com> writes:
| >
| > [...]
| >
| > | For example, let's think of writing a nice "min" macro. It should avoid
| > | double evaluation by distinguishing atomic tokens (identifiers or
| > integral
| > | constants) from other expressions:
| > |
| > | $define min(token a, token b) {
| > | (a < b ? a : b)
| > | }
| >
| > By the end of the day, you may rediscover C++ templates... ;-p
|
| Not if this time you read my entire post :oD. (And the correction, too.)
I read your entire message. I did not find it appropriate to quote
about forty lines just add one. Which is why I kept the quote to a
minimum. Not an indication that I did not read past those lines.
As for the corrections, it showed up only after another around -- when I
already replied. Next time, make sure that you post the right tinhg ;-/
| The post was meant as an illustration of a syntactic transformation that
| reorders an arbitrary-length list of arguments, be they identifiers,
| numbers, or more complex expressions, into a combination of function calls
| and inline operators. An optimizer could have done that, but it's a very
| particular optimization that depends on the semantics of min (ordering - if
| min(a, b) == a and min(b, c) == b, then min(a, c) == a).
The key point of my message was that I would not be surprised if by
the time you think you have designed what you're looking for, you did
not just redicosver C++ templates, with a checking-system or concepts
that just include languinstic distinctions like Token and such.
I conjecture that only the syntax will differ (i.e. your "$").
But hey, that would not be the first time -- I just saw another
presentation last week on the very same topic (but with C as base
language not C++).
--
Gabriel Dos Reis gd*@integrable-solutions.net
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
<ka***@gabi-soft.fr> wrote in message
news:d6**************************@posting.google.c om... On the other hand, I've never seen any advertising from that vendor;
that seems to be one thing they economize on.
Maybe if some other vendors would invest more in the technology, and
less in advertising...
How much would you estimate Digital Mars spends on advertising? <g>
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Walter wrote: Microsoft did C++/CLI, for example.
So instead of making their C++ standard-compliant, they used the
time saved by not implementing export to create a different language.
OK, I'm puzzled.
I know that the list of improvements people want in Digital Mars C++
gets added to nearly daily.
Yes. Does the list of improvements made get added to at the same rate
as well?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] jc*****@taeus.com (Jerry Coffin) writes:
[snip] The cost isn't primarily to the vendors -- it's to the users. The big
problem is that export is just the beginning of the proverbial
slippery slope. If full compliance appears achievable, most vendors
will try to achieve it, even if it means implementing a few things
don't really value.
[snip]
However - it seems several of those who've announced no intent to
implement export are nonetheless implementing everything else. So
I don't think we are sliding down that slippery slope.
If full compliance appears unachievable, or at least totally
unrealistic, then they're left to their own judgement about what
features to leave out. In this case, those last few features they'd
have implemented for full compliance are likely to be left out.
The result is that for most people, not only is export itself
unusable, but (if they care at all about portability) quite a few
other features are rendered unusable as well.
Actually, I expect within a few more years, just about everything
execpt export will be portable.
[ ... ]
> The area where exception handling may have surprised some people
> and/or had unjustified costs is not in its implementation, but the
> burden for exception safety that's placed on the user. Though few
> people seem to be aware of it (yet), export has a similar effect -- it
> affects name lookup in ways most people don't seem to expect, and can
> substantially increase the burden on the user.
I think most of those effects come not from export but from two-phase
lookup.
I'd agree, to some extent -- it just happens that in an inclusion
model, the effects of two-phase name lookup seem relatively natural,
but in an export model they start to seem quite unnatural.
[snip]
I don't know about that. I haven't used it, but I suspect it will
boil down to be a lot like the overloading rules - strange and
complex when examined in detail, with some infamous surprises -
but in practice, doing what most people expect most of the time.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] da****@calamity.org.uk (Daniel R. James) writes: Hyman Rosen <hy*****@mail.com> wrote in message news:<U2wWc.6759$Ff2.2185@trndny06>... Ans pray tell what massive improvements did we see from the vendors who
didn't implement export?
C++/CLI? ;)
Like export, whether or not it is an improvement is in dispute, and
it's no use to those who desire portability. Or haven't you been
paying attention here lately?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Bo Persson" <bo*@gmb.dk> writes: "Hyman Rosen" <hy*****@mail.com> skrev i meddelandet
news:U2wWc.6759$Ff2.2185@trndny06... Walter wrote: > In determining the benefit to users, one must also consider the improvements > to the compiler that are *not done* because of the heavy diversion of > resources to implementing export.
Ans pray tell what massive improvements did we see from the vendors
who didn't implement export?
Managed Extensions, and C++/CLR. Plus the D language. :-)
[snip]
Much like export, these are of questionable benefit to those who need
portable C++ .
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Walter" <wa****@digitalmars.nospamm.com> writes:
[snip] Is export really the only improvement you want out of your existing C++
compiler?
No. But the relativist analysis has been beat to death in the past,
so I thought I'd experiment with an absolutist angle.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Walter" <wa****@digitalmars.nospamm.com> wrote in message
news:<xlBWc.49332$Fg5.1311@attbi_s53>... <ka***@gabi-soft.fr> wrote in message
news:d6**************************@posting.google.c om... "Walter" <wa****@digitalmars.nospamm.com> wrote in message
news:<UuDVc.161558$8_6.45179@attbi_s04>... How it works in D is pretty simple. The template arguments are
looked up in the context of the point of instantiation. The
symbols inside the template body are looked up in the context of
the point of definition. It's how you'd intuitively expect it to
work, as it works analogously to ordinary function calls.
I'm not sure I understand this. Do you mean that in something like:
template< typename T >
void
f( T const& t )
{
g( t ) ;
}
g will be looked up in the context of the template definition, where
the actual type of its parameter is not known? And if so, what
about:
template< typename Base >
class Derived : public Base
{
public:
void f()
{
this->g() ;
}
} ;
?
I'd say that templates must have the concept of dependent names,
which are looked up at the point of instantiation.
Think of it this way. In your first example, the argument for T (let's
call it arg) is looked up in the scope of the instantiation. Then, the
scope of the definition of f is loaded. The equivalent of:
typedef arg T;
is executed, which declares T to be of type arg, and the T is
installed in the scope of instantiation. Then, the semantic analysis
of f happens in the scope of the instantiation. T is found using
normal lookup rules. It works just like a function call does, except
that the "parameter passing" into the definition scope happens at
compile time rather than run time. The analogous happens with Base in
the second example.
So in sum, symbols inside the template body are looked up in the context
of the point of instantiation, and not in the context of the point of
definition. To make it clearer:
extern void g( int ) ;
template< typename T >
void
f( T const& t )
{
g( t ) ; // #1
g( 1.5 ) ; // #2
}
User code, in another module... (I'm supposing we've done whatever is
necessary to use the f, above here. In C++, we've included the header
where f is defined. In D, I don't know what is necessary.)
void g( double ) {}
void
h()
{
f( 2.5 ) ; // #3
}
In the instantiation of f triggered by line #3, which g is called in
line #1? In line #2? If symbols are looked up in the context of the
definition, both lines should call g(int), because that is the only
symbol g visible at the point of instantiation. If symbols are looked
up at the point of instantiation (as is the case in traditional C++,
e.g. CFront, early Borland, etc.), then both lines call g(double). The
two phase look-up in standard C++ means that line #1 calls g(double),
and line #2 g(int).
When people argue against two-phase lookup in C++, they are saying
first of all that all names should be considered dependent. And of
course, that dependent name lookup should work exactly like any
other name lookup, and not use special rules.
C++ tries to emulate this behavior with the two-phase lookup
rules. But it's hashed up - did you know you cannot declare a local
with the same name as a template parameter? It follows weird rules
like that that are all its own.
There are, IMHO, two problems with two phased look-up as it is
implemented in C++. The first is that which names are dependant, and
which aren't, is determined by fairly subtle rules -- even when quickly
scanning f, above, you might miss the fact that the two g's are looked
up in entirely different contexts, and this is an extremely simple
case. (I'm not sure but what I wouldn't have prefered an explicit
declaration -- a name is only dependant if the template author
explicitly says it is.) The second is the fact that the name lookup is
not only in a different context, but follows subtly different rules.
I don't have enough experience with compilers implementing two phase
lookup correctly to say whether this will be a real problem in actual
practice. It may turn out to be like function overload resolution: the
rules are so complicated that almost no pratitioner begins to really
understand them, but in real code, provided a few, common sense rules
are followed, the results are what one would intuitively expect, and
there is no problem. I hope this is the case, but I'm not counting on
it. (Part of the problem, of course, is that many pratitioners already
have concrete experience with a different set of rules, which works
differently. Just being aware that two phase lookup exists, and knowing
a few simple rules to force dependency when you want it, goes a long
way.)
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"llewelly" <ll*********@xmission.dot.com> skrev i meddelandet
news:86************@Zorthluthik.local.bar... "Bo Persson" <bo*@gmb.dk> writes:
> "Hyman Rosen" <hy*****@mail.com> skrev i meddelandet
> news:U2wWc.6759$Ff2.2185@trndny06... >> Walter wrote:
>> > In determining the benefit to users, one must also consider the
> improvements >> > to the compiler that are *not done* because of the heavy
diversion > of >> > resources to implementing export.
>>
>> Ans pray tell what massive improvements did we see from the
vendors > who >> didn't implement export?
>
> Managed Extensions, and C++/CLI. Plus the D language. :-)
[snip]
Much like export, these are of questionable benefit to those who need
portable C++ .
Sure, but they *are* presented as massive improvements by their
respective implementor.
I would for sure have preferred export to Managed Extensions. It was a
real anti climax after waiting 4 years for a compiler upgrade: "We
haven't implemented much of the C++ Standard, but we have added these
fine extensions."
Somehow portability seems to have a low priority for some of the
compiler providers. :-)
Bo Persson
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Walter wrote: <ka***@gabi-soft.fr> wrote in message
news:d6**************************@posting.google.c om...
"Walter" <wa****@digitalmars.nospamm.com> wrote in message
news:<UuDVc.161558$8_6.45179@attbi_s04>...
How it works in D is pretty simple. The template arguments are looked
up in the context of the point of instantiation. The symbols inside
the template body are looked up in the context of the point of
definition. It's how you'd intuitively expect it to work, as it works
analogously to ordinary function calls.
I'm not sure I understand this. Do you mean that in something like:
template< typename T >
void
f( T const& t )
{
g( t ) ;
}
g will be looked up in the context of the template definition, where the
actual type of its parameter is not known? And if so, what about:
template< typename Base >
class Derived : public Base
{
public:
void f()
{
this->g() ;
}
} ;
?
I'd say that templates must have the concept of dependent names, which
are looked up at the point of instantiation.
Think of it this way. In your first example, the argument for T (let's call
it arg) is looked up in the scope of the instantiation. Then, the scope of
the definition of f is loaded. The equivalent of:
typedef arg T;
is executed, which declares T to be of type arg, and the T is installed in
the scope of instantiation. Then, the semantic analysis of f happens in the
scope of the instantiation. T is found using normal lookup rules. It works
just like a function call does, except that the "parameter passing" into the
definition scope happens at compile time rather than run time. The analogous
happens with Base in the second example.
I'm a bit confused here - in the first paragraph, you wrote:
"The symbols inside the template body are looked up in the context of
the point of definition."
I think the point of James' example was to inquire about how the symbol
'g' is looked up -- at the point of definition g(T t) may not yet be
declared for any type T, so how is the symbol 'g', which is in the
template body, looked up at definition time?
-matt
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
"Walter" <wa****@digitalmars.nospamm.com> writes: 3) The faster compilation is theoretically based on the idea that
the template implementation doesn't need to be rescanned and
reparsed every time it is #include'd. However, many modern C++
compilers already support "precompiled headers", which already
provide just that capability without export at all. I'd be happy to
accept a compilation speed benchmark challenge of Digital Mars DMC++
with precompiled headers vs an export implementation.
I've already mentionned my experiments here in the past. I could
built test cases with Como where the ratio between pre-compiled
headers and export is as high as wanted by just adding more
compilation units. That was easy and was done only to check that
there was a possible win.
But, I was suprised that, in an example built to test what was the
break even point in a more realistic domain level template, there was
a win to use export as soon as two compilations units made use of the
same specialisation.
BTW, the win will depend on the way template are instanciated. Como
use the model which benefits the most of export. Other could have no
benefit at all. Google seems to be unreachable, but if you look at my
old posts on this subject you should find more details.
Yours,
--
Jean-Marc
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
David Abrahams wrote: Hyman Rosen <hy*****@mail.com> writes:
Andrei Alexandrescu (See Website for Email) wrote: Templates cannot be meaningfully typechecked during their compilation.
They also cause complications when instantiated in different contexts.
That makes them unsuitable for "true" separate compilation. Slapping a
keyword that makes them appear as separately compilable while the true
inside the compilation system guts is different (in terms of dependency
management and compilation speed) didn't help.
There have been environments in which the linker did whole-program
optimization, inlining routines out of object files into the call
sites. I think you are mistaken in concept when you try to peer under
the hood of the compiler to call some of its operations "true" and
some not. Step back and think of nothing but the point of view of
the user. Also consider that while extremely complex cases of
instantiation must be handled correctly by the compiler, most actual
templates that people write don't have weird name-capturing problems.
Doesn't that tend to argue that export isn't solving a real problem?
Does that mean that the problem it's solving isn't a real problem, or
that some real problem that should be getting solved, isn't?
Thanks,
Rich
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Benjamin C. Pierce |
last post by:
The Twelth International Workshop on
Foundations of Object-Oriented Languges (FOOL 12)
Saturday 15 January 2005
Long Beach, California, USA
Following POPL 05
The search for sound principles...
|
by: Roel Wuyts |
last post by:
CALL FOR CONTRIBUTIONS
International Workshop on Revival of Dynamic Languages
http://pico.vub.ac.be/~wdmeuter/RDL04/index.html
(at OOPSLA2004, Vancouver, British Columbia, Canada, October...
|
by: akmal chaudhri |
last post by:
Call for papers
dataX
International Workshop on Database Technologies
for Handling XML information on the Web
March 14, 2004, Heraklion, Crete (Greece)
...
|
by: Douglas C. Schmidt |
last post by:
Hi Folks,
On behalf of the entire OOPSLA 2004 Conference Committee, we invite
you to contribute and actively participate in next year's OOPSLA, to
be held in Vancouver, British Columbia, October...
|
by: Dana Morris |
last post by:
Call for Participation
OMG's First Annual Software-Based Communications (SBC) Workshop:
From Mobile to Agile Communications
http://www.omg.org/news/meetings/SBC2004/call.htm
September 13-16,...
|
by: Gail E. Harris |
last post by:
OOPSLA 2005 is being held in San Diego, Oct 16 to 20.
Invited speakers include:
Robert Hass, Martin Fowler, Gerald Jay Sussman
Grady Booch, Jimmy Wales, Mary Beth Rosson, David P. Reed
The...
|
by: Jordan Bruce |
last post by:
*******************************************************
ONTARIO CANADA INFORMIX USER GROUP (OCIUG)
http://www.iiug.org/ociug
NEXT MEETING: WEDNESDAY, JULY 14...
|
by: Wim Vanhoof |
last post by:
-----------------------------------------------------------
WLPE' 06 - CALL FOR PAPERS
Workshop on Logic-based Methods in
Programming Environments
(satellite workshop of ICLP’06)
August...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
