You bring up an excellent point about the rigidity of C# generics constraints. One of the crucial features of the proposals for concepts in C++ is retroactive modeling, which allows you to adapt to the specific syntax of a concept *without* changing your data type. So the problem you mention for C# generics is not actually a problem with C++ concepts.
Here's an example. I'm writing a concept for a Stack, which might look like this:
template concept Stack {
typename value_type = S::value_type;// the type of values on the stack
void push_to_top(S& s, const value_type& value);
void pop_from_top(S& s);
value_type& get_top(S& s);
bool is_empty(const S& s); };
I picked some silly names on purpose. Now, std::stack doesn't match the syntax of this concept. So what if we try to pass a std::stack to a function like the following, which expects something that is (we use the term "models") a Stack?
It's going to fail to compile, because std::stack does not match the syntax of the Stack concept. If C++ concepts had the same restrictions as C# generics in this regard, we would be stuck writing an adaptor class. Yuck.
Retroactive modeling saves the day. We can fix the problem by writing a model definition like this:
In this model definition, we're meeting all of the requirements of the concept by providing function definitions that transform the syntax of the Stack concept (pop_from_top, is_empty, etc.) into calls to the std::stack itself (see the function bodies). Now, when we call clear_stack() with a std::stack, it "just works": the calls to is_empty() and pop_from_top() in clear_stack() go through the model definition. Of course, if we picked more standard names and member functions in our Stack concept, the model definition could be empty or (for implicit/structural concepts) omitted entirely.
Retroactive modeling is *really* important for making it easier to reuse template code. You won't need to be paranoid about matching syntax *exactly* with every concept you need to model, because the compiler will detect any mismatches and you can fix them through a model definition---without having to change the data types, templates, or concepts. Of course, people will still try to agree on names and concepts when possible, because it saves typing. You can check out the actual proposals before the C++ committee (references follow) for more information. There are two active proposals, but the groups are working together, so expect a final "combined" proposal in the future.
There are other differences between C# generics and C++ concepts. Before starting to design concepts for C++, most of the authors of one of the concepts proposals (N1849; see below) did an extensive study of the generics facilities of several languages (e.g., C# generics, Java generics, Haskell, ML functors, C++ templates). They ran into trouble with every language they tried, and we designed our C++ concepts to avoid those problems. Here's the original paper; there's an extended version (with more languages and more detail) under review:
Ronald Garcia, Jaakko Jarvi, Andrew Lumsdaine, Jeremy G. Siek, and Jeremiah Willcock. A Comparative Study of Language Support for Generic Programming. In Proceedings of the 2003 ACM SIGPLAN conference on Object-oriented programming, systems, languages,
Note that many of these taxes are justifiable, and I think that we should tax them appropriately for what they cost the taxpayers.
Tax on cigarettes? Fine, smoking has been linked to lung cancer, heart disease, and other ailments. These are all expensive to treat, and yes we pay for those treatments.
Tax on alcohol? Of course - how many lives are lost per year to alcohol-related accidents? We have to pay for the emergency services that respond to an accident, the damage caused by the vehicles, preventative measures, etc.
Tax for pollution? At some point, we're going to have to clean up this mess we've made. Taxing for pollution has two benefits. The first is that, if the tax is high enough, polluters will find it more economically beneficial not to pollute. The second is of course that we can use the revenue generated in the meantime to help pay for the cleanup.
Methods like this were once used to keep minorities from voting - literacy tests, for instance, were given at the polls - but this was not considered constitutional.
I think that times have changed, however. Everyone in the U.S. has the opportunity to learn to read, and I find it hard to excuse illiteracy at the age of 18.
I would propose testing at the polls and using the test results to weight the vote. This way, those that take time to learn about the candidates and their respective platforms will be rewarded with a bigger say in government.
Every person in the United States should have equal freedoms, but I don't believe that equal representation falls in that category. A Professor of Political Science is most likely more capable of choosing a better candidate than the average person, but the Professor gets no more say.
This is the reason I spent many hours decided whether or not to vote. I've taken quite a lot of my time studying the candidates and have chosen to vote for some candidate "A" (no, don't read into the choice of letters). Any fool who thinks candidate "B" is cute, or blindly follows "B" based on one issue (and ignoring the rest), completely cancels out my vote for "A". In my opinion, this is absurd. We all have the same chances to learn about the candidates, but regardless of the level of thought we've put into it, that ballot is worth only as much as one other American recognizing a name or spelling his/her name in voting dots.
I'm only voting knowing that I can cancel out one person who has spelled his/her name in dots.
>If you have an alternative policy that is even >slightly practical for a class with 800-odd >students,
> I'd sure like to hear it!
It's not quite a policy, but as a TA in charge of projects I had the students submit their code through e-mail (via a Perl script). The e-mail recipient was a dummy account which test-compiled the project and sent back a "compile success" or "compile failed" (with error messages, of course).
This alleviated most of the Visual C++/gcc conflicts for a smaller (150 student) class.
Slashdot Mirror
You bring up an excellent point about the rigidity of C# generics constraints. One of the crucial features of the proposals for concepts in C++ is retroactive modeling, which allows you to adapt to the specific syntax of a concept *without* changing your data type. So the problem you mention for C# generics is not actually a problem with C++
// the type of values on the stack
concepts.
Here's an example. I'm writing a concept for a Stack, which might look like this:
template
concept Stack
{
typename value_type = S::value_type;
void push_to_top(S& s, const value_type& value);
void pop_from_top(S& s);
value_type& get_top(S& s);
bool is_empty(const S& s);
};
I picked some silly names on purpose. Now, std::stack doesn't match the syntax of this concept. So what if we try to pass a std::stack to a function like the following, which expects something that is (we use the term "models") a Stack?
template
void clear_stack(S& s)
{
while (!is_empty(s)) {
pop_from_top(s);
}
}
It's going to fail to compile, because std::stack does not match the syntax of the Stack concept. If C++ concepts had the same restrictions as C# generics in this regard, we would be stuck writing an adaptor class. Yuck.
Retroactive modeling saves the day. We can fix the problem by writing a model definition like this:
template
model Stack >
{
typedef T value_type;
void push_to_top(std::stack& s, const T& value) { s.push(value); }
void pop_from_top(std::stack& s) { s.pop(); }
value_type& get_top(std::stack& s) { return s.top(); }
bool is_empty(const std::stack& s) { return s.empty(); }
};
In this model definition, we're meeting all of the requirements of the concept by providing function definitions that transform the syntax of the Stack concept (pop_from_top, is_empty, etc.) into calls to the std::stack itself (see the function bodies). Now, when we call clear_stack() with a std::stack, it "just works": the calls to is_empty() and pop_from_top() in clear_stack() go through the model definition. Of course, if we picked more standard names and member functions in our Stack concept, the model definition could be empty or (for implicit/structural concepts) omitted entirely.
Retroactive modeling is *really* important for making it easier to reuse template code. You won't need to be paranoid about matching syntax *exactly* with every concept you need to model, because the compiler will detect any mismatches and you can fix them through a model definition---without having to change the data types, templates,
or concepts. Of course, people will still try to agree on names and concepts when possible, because it saves typing. You can check out the actual proposals before the C++ committee (references follow) for more information. There are two active proposals, but the groups are working together, so expect a final "combined" proposal in the future.
There are other differences between C# generics and C++ concepts. Before starting to design concepts for C++, most of the authors of one of the concepts proposals (N1849; see below) did an extensive study of the generics facilities of several languages (e.g., C# generics, Java generics, Haskell, ML functors, C++ templates). They ran into trouble with every language they tried, and we designed our C++ concepts to avoid those problems. Here's the original paper; there's an extended version (with more languages and more detail) under review:
Ronald Garcia, Jaakko Jarvi, Andrew Lumsdaine, Jeremy G. Siek, and Jeremiah Willcock. A Comparative Study of Language Support for Generic Programming. In Proceedings of the 2003 ACM SIGPLAN conference on Object-oriented programming, systems, languages,
Note that many of these taxes are justifiable, and I think that we should tax them appropriately for what they cost the taxpayers.
Tax on cigarettes? Fine, smoking has been linked to lung cancer, heart disease, and other ailments. These are all expensive to treat, and yes we pay for those treatments.
Tax on alcohol? Of course - how many lives are lost per year to alcohol-related accidents? We have to pay for the emergency services that respond to an accident, the damage caused by the vehicles, preventative measures, etc.
Tax for pollution? At some point, we're going to have to clean up this mess we've made. Taxing for pollution has two benefits. The first is that, if the tax is high enough, polluters will find it more economically beneficial not to pollute. The second is of course that we can use the revenue generated in the meantime to help pay for the cleanup.
Methods like this were once used to keep minorities from voting - literacy tests, for instance, were given at the polls - but this was not considered constitutional. I think that times have changed, however. Everyone in the U.S. has the opportunity to learn to read, and I find it hard to excuse illiteracy at the age of 18. I would propose testing at the polls and using the test results to weight the vote. This way, those that take time to learn about the candidates and their respective platforms will be rewarded with a bigger say in government. Every person in the United States should have equal freedoms, but I don't believe that equal representation falls in that category. A Professor of Political Science is most likely more capable of choosing a better candidate than the average person, but the Professor gets no more say. This is the reason I spent many hours decided whether or not to vote. I've taken quite a lot of my time studying the candidates and have chosen to vote for some candidate "A" (no, don't read into the choice of letters). Any fool who thinks candidate "B" is cute, or blindly follows "B" based on one issue (and ignoring the rest), completely cancels out my vote for "A". In my opinion, this is absurd. We all have the same chances to learn about the candidates, but regardless of the level of thought we've put into it, that ballot is worth only as much as one other American recognizing a name or spelling his/her name in voting dots. I'm only voting knowing that I can cancel out one person who has spelled his/her name in dots.
>If you have an alternative policy that is even >slightly practical for a class with 800-odd >students, > I'd sure like to hear it! It's not quite a policy, but as a TA in charge of projects I had the students submit their code through e-mail (via a Perl script). The e-mail recipient was a dummy account which test-compiled the project and sent back a "compile success" or "compile failed" (with error messages, of course). This alleviated most of the Visual C++/gcc conflicts for a smaller (150 student) class.