text:
Trip Report: Exit Concepts, Final ISO C++ Draft in ~18 Months
Herb Sutter	C++	 2009-07-21 2009-07-22 5 Minutes
A week ago, I attended the summer ISO C++ meeting in Frankfurt, Germany. The C++ committee made a lot of progress on addressing national body comments on the full committee draft published last year, and is well on the way to publishing a second and final CD this winter with a final draft international standard a year after that. To meet that schedule, the committee decided to defer a major feature, "concepts", and not include it in this standard.
I'm surprised at some of the commentary I've been reading on the web about the deferral of concepts, including not just technical inaccuracies but also that their absence in C++0x is somehow a big deal for C++ as a language or is a major geopolitical firestorm. It may feel like a big deal because of the work that's gone into concepts and the large number of pages of standardese that were needed to specify the feature, and there was a lot of discussion about important design details including heavy traffic on the committee reflectors this spring and early summer that probably made them look more controversial than they are.
But my opinion is that concepts' presence or absence in C++0x just won't make much difference to most users. Let me give some reasons why I feel that's so, and maybe debunk some common misconceptions along the way, in the form of an unofficial FAQ. Note that I was never involved in the design of concepts and don't speak for the designers, whose views might differ here and there; the following are observations from my point of view as a participant in the standards body (including in Frankfurt last week), and chair of the ISO C++ committee during the entire time concepts were being developed up to the meeting they were voted into the ISO C++0x working draft last fall.
Q: Bjarne Stroustrup is the creator of C++ and a primary designer of concepts. What's his take?
A: Great question. See Bjarne's coverage here, published earlier today in Dr. Dobb's.
Q: Were concepts removed because of political reason X, Y, or Z?
A: No. Concepts were removed because of normal project management considerations. The basic constraint has been phrased in many ways, all of them hitting at the same underlying tension among time, scope, cost, and quality. Here are two examples: "You can pick what goes on the train, or you can pick when the train leaves the station, but you can't pick both." "You can have good, fast, and cheap – pick any two."
Fundamentally, the committee members felt that concepts are desirable but many (though not all) believed that they were still in design mode and needed more "bake time" – a formal poll of committee members in Frankfurt put the expected time at between three and four years – to get up to the quality of a feature that belongs in an international standard. Therefore, the two major options, and the ones that people generally argued for, were to either:
Prioritize (bigger) scope. Wait for concepts, and accept a delay to the rest of the standard including features that are already finalized and ready to ship.
Prioritize (faster) schedule. Finish and ship the standard to get already-done features into users' hands, and decouple concepts to continue work on them for a future standard.
The committee decided to prioritize schedule and ship C++0x sooner while still leaving the door wide open to also adopt concepts later.
Q: Isn't removing concepts a lot of work? Concepts are used pervasively in the C++0x CD published last fall.
A: Yes, but it's less work than you'd think. We won't have a de-conceptized working draft for the post-meeting mailing, two weeks after the meeting, but should have one soon after that. (I would be remiss not to add: Thanks to our always-hardworking project editor, Pete Becker!)
Recall that, until last September, we had a complete draft of C++0x features specified entirely without the use of concepts. And many of the uses of concepts in the draft standard library were just replacements of preexisting non-concepts wording or implicit requirements (e.g., DefaultConstructible, MemberContainer), and will just revert to their previous wording or disappear back into implicitness.
The main C++0x feature that was always specified in terms of concepts was the new range-based for loop (e.g., for( x : collection ) ). I've seen some wonder what we'll do about that, but it's already done; the non-concepts text for that feature was already voted in at the same Frankfurt meeting.
Q: Wasn't this C++0x's one big feature?
A: No. Concepts would be great, but for most users, the presence or absence of concepts will make no difference to their experience with C++0x except for quality of error messages (see below).
C++0x is still a major revision with many new major features, including improvements to templates (e.g., variadic templates, template aliases). C++'s other major new features include lambda functions (which unfortunately for Java were rejected for Java 7), move semantics (aka rvalue references), a concurrency memory model, threading and atomics libraries, initializer lists, and more. Other handy new features include delegating constructors, inherited constructors, defaulted and deleted functions, explicit virtual overriding control, alignment support, static assertions, and more. Not to mention convenience features like range-based for loops and "auto" type inference that are small but will certainly get a lot of use (as they do in C# and Java).
A number of those features are available now or soon in real compilers, including Gnu gcc, Visual C++ 2010, and Intel C++.
Q: Aren't concepts about adding major new expressive power to the language, and so enable major new kinds of programs or programming styles?
A: Not really. Concepts are almost entirely about getting better error messages.
Yes, concepts would add one truly new expressive capability to the language, namely the ability to overload on concepts. That's inconvenient to simulate without language support. Concept-based overloading would have been used in a handful of places in the standard library. But that's it.
By far the most visible benefit of concepts lies in clearer template error messages, including the ability to do separate checking – confirming that a template's implementation type-checks correctly with all possible valid types without having to instantiate it, and confirming that a given type can be used to instantiate a template without knowing the template's implementation.
Q: Weren't concepts all about bringing templates into the 21st century? Where does this leave templates?
A: Templates are still king of the genericity hill, for all their faults in the area of opaque compiler messages.
It's important to remember that, in 1994, C++ was the only major language whose type genericity capabilities were strong enough to create the Standard Template Library (STL). Today, 15 years later, that is still true; you can't express the STL's containers-algorithms design separation well, or at all, using generics facilities in Ada, Java, .NET, or any other significant commercial or research language that I know of; as we learned when doing STL.NET, you can do the containers well with other generics, but not the orthogonalization with algorithms that is the heart of STL design style. Concepts or not, that hasn't changed.
So my personal view is that templates have been in the 21st century since about 1994. No other language has yet caught up to their expressive power. And C++0x is adding some further power to templates, in particular by adding variadic templates and template aliases, both of which will help to simplify template code.
Previous Post Effective Concurrency: The Power of "In Progress"
Next Post Suggestions on improving C++ skills
45 thoughts on "Trip Report: Exit Concepts, Final ISO C++ Draft in ~18 Months"
Pingback: Retrospective: The removal of C++0x Conctpts « C++ Digest
Andrea Caloini says:
Is Boost using its concepts library in the other libraries?
(I assume that the not in "C++ is *not* an object oriented language" is a typo and you actually meant "C++ is an object oriented language".)
I am not saying that C++ is not OO because templates aren't. What I meant to say is that the design of templates, as a language feature, lacks encapsulation: the operations that must be implemented by a template parameter are implicit in the implementation (!) of the template itself.
I agree that templates achieve "compile-time duck typing", a flavour that is safer (if less flexible) than Python's (see also http://en.wikipedia.org/wiki/Duck_typing, section "Templates or generic types")
Concepts do not constrain template's duck typing beyond what static typing already does, they just declare outside the template what the template needs from its parameters and, by doing so, can help the compiler pointing out errors with greater precision.
Poor error messages increase the cost (and the frustrations) of developing a piece of software.
It goes without saying that having a compiler that points out errors in your code (close to the location of the problem!) is better than having to rely on the documentation alone or having to decipher the instantiation "haystack".
Tyler Shaub says:
C++ is not an object oriented language. Templates don't try to be object oriented. This is not a bad thing.
Your analysis of template debugging is all kinds of faulty: you don't have to look at source for a function to figure out it's use – check the documentation.
Also, as many have commented on, templates achieve something similar to python's duck typing. In my experience I have the same kind of problems, but the last conclusion I would draw is that python is not object oriented because of it. Good code/templates should be written such that it's "easy to use correctly, and hard to use incorrectly."
When code that uses a templatized library does not compile the error you get is what some people call the "instantiation stack".
This kind of wording painfully points to the fact that templates are a non-object oriented feature of an object oriented language: you need to look at the internals of a templatized library in order to provide a type that compiles.
It's the same as saying that you have to look at the internals of a function to figure out its signature.
For me it is very regretful that this issue is not going to be addressed in what is now C++1x.
Glen says:
@Nicol Bolas
@Doug Gregor
Quoting the current status quo back to me seems to miss my point – which is that the status quo probably needs to change.
I reiterate that if something can't see the light of day inside of 13 years (Concepts and Modules), it's either very wrong or wasn't worked on long enough. Assuming it's the latter because Bjarne (and Herb?) still believe Concepts should be in C++ then the problem is likely to be with (as people keep reminding me like I didn't know :)) the volunteer nature of the committee and the lack of resources to do anything different.
In that light it can't be remiss to suggest solutions to that. Mine was that Bjarne, Herb, and some other appropriate committee members consider pushing to get a full time, paid, non volunteer effort together so that Concepts and Modules etc. can see the light of day before I am a very old man!
I see no reason why Microsoft and Apple or Whoever etc. can't sponsor (not own) that effort (with money from STL.NET etc. lol) and make a clear commitment to implement the results (unlike with Attributes apparently?) without doing so in a way that invokes the wrath of God that Nicol describes.
C++ can and does make money when effort goes into the features people want and when they get them in a standards based way.
I'd love to hear other ideas on how we might improve things rather than just state the status quo.
IMHO we have to ask again if we are missing some kind of commercial reality if it takes 13 years to mature an idea that still doesn't see the light of day? In that time frame C# and .NET came from nowhere to cleaning up the market. So in that context if these features need more time then we should be asking the committee to find a way to put it in and in a way that gets us these features before we die and C++ does.
The volunteer route is just not delivering fast enough IMHO. That is not to say they aren't working hard enough. We just need to clone them! Maybe the committee should work on that latter idea actually? ;).
I am not laying any blame on anyone for the 'failure' of Concepts. I don't even claim to know if Concepts are a good thing (though they look good). I just do claim that there are some great C++ features like Modules, Concepts, and open multi-methods on the horizon that could get here a lot sooner than they apparently will if we just ring our hands and accept the status quo without a fight.
A number of people have asked why I focused on error messages, when concepts do have other benefits such as separate checking and the ability to say what you mean when writing templates.
That's because I was focusing on: (a) the most visible effects, not just the most important underlying reasons; and (b) the point of view of a typical C++ programmer, who consumes template libraries much more often than authoring them (most people I teach say they have never done the latter, and the most frequent questions I get in class exercises that ask attendees to write a template are about what the syntax is and how to use template parameters in the body of the template).
As I put it above (emphasis added): "… for most users, the presence or absence of concepts will make no difference to their experience with C++0x except for quality of error messages… By far the most visible benefit of concepts lies in clearer template error messages, including the ability to do separate checking…"
Note that I included the ability to express constraints in code and do separate checking among the reasons/sources behind the end result of better diagnostics. Most C++ programmers aren't authoring templates, and so wouldn't be writing "requires" etc. For them, the primary effect concepts would have would be better (earlier and clearer) diagnostics, for all of the underlying reasons that posters have mentioned.
Doug Gregor says:
The C++ committee cannot "push" any particular feature, because it has no resources to commit to the development of a feature. Modules were moved to a TR because no volunteers stepped forward to develop an implementation and specification for the feature, while Concepts did have volunteers working on both.
Dave Abrahams says:
It's true that templates don't *need* a type system. But then, neither does the rest of the language. We could all be programming with Python or some other fully-dynamic language. Despite the fact that I'm a great fan of Python, I find it much less usable, practically speaking, than C++ is once a program gets even to moderate size. Why is that? It's because the explicit declarations of types and other statically-checkable features of my program are essential for creating modularity (a.k.a. the ability to modify one part of my program without breaking all the others).
I'm sure some fraction of what academics do with language theory is purely cerebral and makes no difference to ordinary programmers, but don't dismiss it just because someone used the word "theory." For the most part, the focus of language theoreticians is driven by real needs of programmers in science and industry, and in the end, a language's "theoretical background" has practical implications for real programmers trying to get something done.
"What concepts are about" is a completely subjective question, and I am sure that even among those actually working on concepts you'll find a wide range of opinions. That said, I don't think anyone who's been deeply involved with the feature would agree with Herb's assessment that they're "almost entirely about getting better error messages." For me, for what it's worth, they're about modularity, about being able to express what I mean in code, and about making generic programming accessible to people without PhDs in (or maybe just with an aversion to) stupid template hackery.
Anyway, just to throw my own take in the ring, there's more on what went down in Frankfurt at http://cpp-next.com/archive/2009/08/what-happened-in-frankfurt.
Nicol Bolas says:
You seem to have a problem with understanding the difference between the C++ specification and, for example, Visual Studio. These are not the same thing; they are only barely related to each other.
Visual Studio is a product by Microsoft. C++ is an ISO specification that is maintained by a working group of volunteers. Visual Studio *implements* C++, but it is not C++. In order for there to be a "conceptualised, Lambdafied, Modularised" Visual Studio 2005, there would have had to be a C++ specification with these features in it released in 2003 at the latest in order for Microsoft to implement all of these features.
It should also be pointed out that VS is, even now, not ISO C++03 compliant. And I'm not just talking about misfeatures like "export". So when would Microsoft get to implementing concepts, lambda, and modules? Whenever they felt like it.
Now, if Microsoft so decided, they could have *created* a compiler for a C++-like language that was "conceptualised, Lambdafied, Modularised". But it would not have been ISO Standard C++. And any new standard that implemented those features would likely implement them differently, thus creating incompatibilities.
Also, the FSF-brigade would have been screaming bloody murder, with talks of "embrace, extend, extinguish" and such.
Canceling STL.NET will do nothing for getting us Modules one day sooner. Bjarne, Edge, and Microsoft do not control C++. The C++ Working Group does. And money doesn't make them work faster.
If there's one thing the failure of Concepts tells us though, is that if something isn't working out, cut it ASAP. If the WG had been pushing Modules instead of Concepts, *those* would have worked out (Modules are simpler than Concepts). Instead, Modules was bumped for later, and we still failed to get Concepts.
@Glen: I agree with most of the points you mentioned but those seems to be just dreams.
I feel so disappointed.
@Nicol Bolas:
1: I have to disagree with you. Providing theoretical background is not just nice but it helps the programmer to have better understanding of the problems and solutions that definitely result in much more quality in the finished work. I really hate to see some programmers just want the get the work done. The result is obviously as low quality as what we can see in lots of weak softwares available these days.
Also I have to disagree with folks who think the main use of concepts is about the error messages. IMHO quality of error messages is one of the results of the theoretical background of templates that makes the templates more rational.
And I can't guess why Herb just mentioned the error quality as the only reason for concepts too!
Pingback: Concepts in C++ – gone for now, but not forgotten « Bubblescope
Angelo Pesce says:
Some points:
– About Lisp macros. Those are different and more powerfull beasts. We shouldn't really compare those to C++ templates, but if you really want, then to me the most interesting part is that they're not strictly compile time. C++ went towards static everything, that made sense 15 years ago, not now. We're at a point where C++ is so static that we don't have good modules, our code takes ages to compile and link, we can't hot-reload code… And the usual excuse that C++ cares about performance is totally untrue, again, it was 15 years ago, but today? No alignment, no threads, no SIMD, some will come, but too late. Templates statically generate code, way too much, they actually make things slower if you don't take care.
– About templates being 21th century. Yes, maybe templates are very powerful, still less powerful than Lisp, but if you want not to regard lisp as mainstream… Fine. Still most of their power is impossible to use. You can make boost::lambda, but do you want to use it? With all those incomprehensible errors? Suffice to say, I develop games on PS3, 360, PC, PSP etc… No two compilers will compile the same template code. You make one compiler compile, then the other 99% of the times, if the templates are any sophisticated, won't. Now to me one thing is clear. If you make a standard so ugly that even C++ compilers, after years, can't get it totally right, then you've really made an ugly, ugly, ugly mess. Template's power is evil.
– C# collections… They're sane. They're threadsafe. They have interfaces, so you can actually use them publicly, without having to expose everything, and without needing to wrap your stuff in getters and setters. STL. Yes you have algorithms, but you can use them only privately, because publicly you don't want to expose STL containers directly, you have to wrap them, and then algorithms are no usable anymore. C# does not have algorithms? What about LINQ? PLINQ? Way powerful, on collections.
I'm surprised by this article
Pingback: La morte dei concept (C++0x)… « JP's Web Place
Nicol, if you re-read my post you will see that I am aware the team is volunteer, I actually say that in my post.
Your comment that:
'You seem to be operating under the belief that the C++ Working Group is an organization who's members spend their days doing nothing but thinking about and working on the C++ specification. This is simply not true.'
seems to be missing exactly the point I was trying to make which is it is exactly because the C++ Working Group clearly does not as you say 'spend their days doing nothing but thinking about working on the C++ specification' that I believe we have a problem.
If they did work full time on it, maybe it wouldn't be 13 years, as we are now hearing, to get an acceptable Concepts proposal together. We still have no Modules or any of the other things that I mentioned in my post either. But maybe someone just needs to blog more about that?
I don't think it's wrong to suggest if a full time team could address this situation quicker than what we have today. I never said it would be easy or likely, just that it might be necessary and a way it might happen. Surely there has to be a way to better the situation we have now.
C# has had a dedicated full time commercial team and it shows. C++ does not and it also shows. If we had had a full time team earlier then maybe VS2005 even could have been a conceptualised, Lambdafied, Modularised C++. It didn't happen because people were working on other things (like STL.NET) which I doubt will ever get used.
MS dropped the ball so badly with C++ that they had to buy EDG technology to catch up (a good thing) and it was a similar story for MFC. One could even speculate that we only got Lambdas so quickly because it fitted in with the Concurrency agenda MS is following. In VS2010, I can't even use nullptr still in standard C++, and how hard is that to implement or agree on sooner??!!
Even if there was no full time team, better coordination and less distraction with things that people are not asking for would benefit the community as a whole. For example, if I was Herb, I'd suggest MS cancel the STL.NET project (sorry to pick on it) now (maybe they have?) and use that money and those people to work on Modules with Bjarne and EDG. I am sure there are other examples people can think of. Of course by then we will all have solid state drives (or even flying cars? ha ha) and maybe it wont matter after all… :)
Anyway, nobody doubts these are all great amazingly talented (and humble) people, I just want to see the fruits of their work sooner and more unified, that's all. If we can kick up enough debate on this, maybe they'll find a way. I can wish at least can't I? :)
1: The theoretical background of C++'s templates means nothing to a programmer trying to get something done. Providing a theoretical background is nice and all, but I'd rather the WG spend their time on features that actually *do* something.
2: Templates don't *need* a type system. That's the whole idea behind templates. Concepts only gave them one to make it easier to specify constraints.
Herb only highlighted error messages because that's the main use for them. The other stuff is not a necessity.
@Glen
You seem to be operating under the belief that the C++ Working Group is an organization who's members spend their days doing nothing but thinking about and working on the C++ specification. This is simply not true.
The C++ Working Group is a *volunteer* organization. There is no "being fired" because nobody hired them in the first place. It exists as a collective of people who want to improve C++ and submit a specification for ISO approval. That is all.
The reason that languages like C# evolve faster is because Microsoft hires people for the sole purpose of evolving their language. C++ is governed by a volunteer organization.
"A bolder attitude to using keywords."
Backwards compatibility is why a lot of people use C++ to begin with. If you start making already compiling code break just because you were not willing to take some time to choose a less conflicting keyword, then you don't deserve users. Even C#, for example, overloaded the keyword "delegate" in their implementation of lambda instead of using a keyword like "lambda" or "unnamed".
Anonymous Coward says:
Judging by their retrograde coding standard, Google would not be interested. I'd pin my hopes on Adobe.
Bill McGann says:
I'm surprised that no one has mentioned here that Boost implements the functionality of 'concepts' at the library level. As a stop-gap, you can use Boost's (ugly) library as an alternative to real language-support.
Hoang Vu says:
I agree with you. However, there is always too much politics in our profession. MS is always insisting that it customers move on to C#. They haven't paid proper attention to the Visual C++ project for years.
Herb, I would like to express the ignorant opinions of a lay person who used to use C++ but who now has to use C# because Microsoft's C++ story evolved too slowly. What upsets me is that the C++ committee seems to be doing the same.
I have enormous respect for all the people involved in C++0x, but IMHO not having Concepts is a major screw up. It's hard to pin the blame on anybody so in that case I just think we have to blame everybody for now until the situation is fixed.
IMHO C++ is suffering because of a collective lack of will and organisation by the committees strongest members to simply do the right things for C++ in a timely fashion. This has been hurting the customers that use C++ for some time. Microsofts own forums for C++ generate almost hate mail type responses these days that reflects that the situation is as bad as I suggest. Doing all the right things on your own is the wrong thing customers are saying.
In the time we could have had a great standard C++0x we instead have a PPL, a TBB, a C#, a C++/CLI, an STL.NET etc. etc, but not yet the C++ that most people appear to be asking for. So many distractions exist for no good reason. For example, STL.NET will never fly as managed C++ prior to C++/CLI was never going to fly. Who ever asked for those?
Herb says we can have any two of good, fast, and cheap. But why say that?! MS and Google are not short of money or talent and they both use C++ a lot so I see no good reason (other than political or poor community organisation) for not being able to have a good, fast and expensive C++! C++ appears to be in need of a clear focused C++ development team at this point, not just a committee.
Because if Concepts took 5-7 years so far, and the committee says it'll take another 5 years to appear then that's 13 years! If this is for real, you should all fire yourselves now or get a better plan because that's just a crazy amount of time to do anything! It's just not commercial or necessary to work in these timeframes and the drop off in the popularity/credibility of C++ in the market reflects these facts surely?
Anyway, my plan is not to fire you because you are all voluntary after all! So the plan is in fact to hire you!! All of you. Here's the plan:
* MS, Google and Apple please put a few million 'in the kitty' for C++. You use it and you can afford it. And we like it and want to use it in more places and with more productivity.
* Ship C++0x today, but minus Concepts and Attributes. MS abuses attributes in the C# space all the time, I am sure the C++ world will do the same if given the chance.
* Get a Globe Trotter style C++ development dream team together that contains the greatest minds pf C++ focused on and prioritised by what customers actually want and don't work on anything else until that spec is thrashed out completely.
* The kitty can pay for the dream team. My choices are: Bjarne, Herb, Lawrence, and Andrei (of Elements in programming fame) and who ever else that team wants to enlist themselves but someone from Clang, EDG. and Apple would be nice. That kind of team will have all the moral authority and combined commercial power to define the de-facto standard the second the results are published.
* Enough work has been done already on the important areas, that if there are no distractions, lots of coffee, and you all work together full time, face to face, then surely the team should be able to publish a definitive work in months not years (read less than one year)?
For me, this work should produce a C++ containing:
* Concepts perfected.
* A definitive language specification for MODULES!
* Open multi-methods. Don't let this become the next Concepts dragging on for 5 years from now, do it now!
* Attributes (if you insist). But one that Microsoft WILL actually implement (?) and that doesn't use double brackets, one is enough ;)
* C++/CLI's override and method rename mechanism – further reunification here would have been nice? Why not? Why the resorting to attributes here?
* A bolder attitude to using keywords. If you are trying to simplify the language and its error messages then why obscure it again with strange hard to read attributes and re-using of old keywords in odd places. How about specifying in the standard a list of keywords you might use in the future and issue warnings about them now to pave the way in the future…
* Park the evolution of iterators. Ranges are definitely the way to go. Lets have them now in this standard.
* A far bolder set of standard Attributes and compiler directives for things like unused parameters, variables, multi inclusion guards, optimisation hints etc. etc.
There appears to be some big improvements in C++ IDEs and compiler technology on the way in the next few years from MS/EDG/Clang etc. so nailing the definitions of some big advances in the language design now would be a great way to revive C++'s status and ensure we get ALL of these things inside of 2 years, not 5 years.
In concusion: 5 years is too long for us to wait for these features. We should have had them yesterday!
Ok, phew, that's it! I'd love to read some other peoples opinions here and hope this kicks up even more hard arguments and friendly but passionate discussions and gets the committee revisting its ideas so we don't get what feels like failure, but instead get an even bigger bolder and quicker plan!
Peter Doubleday says:
I'm still groping around with the concept of "Concepts," although Stepanov's recent book (highly recommended, even for mathematical ignoramuses like me) helps.
As far as I can see, they're inappropriate for the task of simplifying error messages in template instantiations. What, you need implicit and explicit? And "concept maps"? And all the usual C++ baggage of overriding and scope and such-like? I think I'll take my three thousand word compiler dissertation which boils down to "You screwed up," thanks very much.
I do think they're an enticing idea, though; if only because they seem to embed set theory into the C++ type system. This has got to make libraries more robust and more usable. I don't get to work much with mathematical libraries (more's the pity), but I have spent quite a lot of time working with large-scale concurrency issues — and I'm pretty damn sure that concepts would help me build and analyse a far better solution than I could with even C++1x.
jalf says:
@AP: We've gotten by without 1 and 2 so far though. Generic programming in C++ is already far more advanced than in Haskell, so the theoretical underpinning obviously isn't a complete show-stopper. Concepts would have been nice for those reasons, but they're not "needed".
@James Slaughter: The main reason why concepts could have cleaned up error messages is because they provide a mechanism for detecting the error at the instantiation site, rather than inside the instantiated template. That would have been a pretty major improvement, and pretty much orthogonal to cleaning up the error messages in general.
Catching errors earlier have little to do with how the compiler prints out and formats those errors.
Pingback: POCO C++ Libraries Blog » Concepts Removed from C++0x
James Slaughter says:
I was never sold on the better error messages part of the concepts deal. I didn't trust compilers to do a better job of telling me that "You can't call A because B doesn't map to concept C due to not having function D" than they've done in the past, especially when A is overloaded on different Cs and D is potentially an overloaded name in scopes accessible via B. Admittedly, the instantiation stacks were likely to be shallower, but it all seemed like hand-waving and wishful thinking.
I'm also convinced that implementations could do a service to users by filtering their own messages before they spit them at the users, and that this doesn't require concepts. For example, there are implementations that automatically invoke STLFilt. It would be commendable if Visual C++ followed suit, but I guess the fact that it hasn't done so indicates a relative lack of demand for better error messages anyway…?
I predict that strategic use of constexpr and static_assert will do more for compile time diagnostics than concepts ever would. Having said that, concepts were compelling for other reasons, and though I agree with the decision that's been made, I look forward to seeing them in future.
How will this affect VS2010?
Paul Leopardi says:
7 years after my first publication of the GluCat library, I am still looking for a sensible way for C++ to mimic the relationship between different mathematical constructs. In the case of GluCat, the main template class is numeric, and is intended to take a template parameter which is a numeric type such as float, double, etc. The template class then provides a numeric type which is just like float, double, etc. – except that multiplication is not commutative. Concepts *could* have provided a mechanism for Glucat to flag to other template libraries that the multiplication that it provides is *not* commutative; and concepts *could* have provided a mechanism for GluCat to require that its numeric template parameter class provides a multiplication which *is* commutative. I still can't see a clear way of doing this in C++ 1998. It now looks like I needn't bother with C++1X, as it won't even try to provide a solution.
Pingback: Jamu Kakar (jkakar) 's status on Friday, 24-Jul-09 20:01:41 UTC - Identi.ca
Jonathan Leonard says:
P.S. One should also not forget the code bloat that results from template instantiations and the effect it may have on the size of one's working set and thus ultimately performance.
I'd also like to point out that while LISP may not be able to do as much as C++ at compile time, that isn't the only way to good performance. It may help you catch errors earlier (which is definitely a good thing) but the issues about whether something happens at compile time (i.e., front-end compile), JIT-time (i.e., back-end compile), or runtime are really orthogonal to whatever actual performance the entire process (from load to unload) exhibits (and even the time taken to compile should be considered as a cost [albeit with a smaller weight than run time in most cases]).
Also, Haskell's type system is arguably even more advanced than C++'s and thus should be able to provide the [expressibility] benefits of LISP with the [perceived and often assumed rather than measured] performance of C++.
Good job. But I think you might agree, it's not the prettiest thing.
@Trey, you are right; you _could_ do it. My point is only that it generally isn't.
I've seen a statically typed scheme extension; in PLT i think. Maybe it's done there
@David, The improvements in C++0x and VC10 is certainly exciting, but I'm not sure it's reached "most expressive". MPL and its ilk is impressive; not because of its expressiveness, but rather that it's even possible.
"call" templatizes on: typename FuncDecl, typename C
MakeFnDecl on: typename iterator
and MakeFnDecl is instantiated with IntVec::const_iterator for "call".
Everything else should be fairly clear.
"I challenge a C++ developer to show me an instance where they passed "std::search" as an argument to a function call […]"
I like a challenge!
typename FuncDecl::Result call(C const& container, typename FuncDecl::Fn function)
return function(container.begin(), container.end(),
container.begin(), container.end());
struct MakeFnDecl
typedef iterator Result;
typedef iterator (*Fn) (iterator, iterator, iterator, iterator);
// simplified std::search decl
typedef std::vector IntVec;
IntVec ints;
ints.push_back(10);
std::cout << *call< MakeFnDecl >(ints, &std::search);
I tried to keep it as simple as possible while also showing that basically all of those things could be templatized/delayed at various points. Most importantly MakeFnDecl could be declared and deduced in a more meaningful place.
Definitely not easy though, and obviously the designer has to have exactly this consideration in mind.
…PS: Thanks for the insightful (as always) post on the dropping of Concepts Herb! It's definitely a loss, but it's managable, and we still get cool stuff.
PPS: oh man i hope (read "doubt") the formating doesn't destroy this code
I have to disagree with Herb's post. Concepts are needed in C++ for much more than *pretty error messages*. Concepts are to C++ what typeclasses are to Haskell – in that they are fundamental for generic programming in C++.(For those unfamiliar with typeclasses – see: A comparison of c++ concepts and haskell type classes http://portal.acm.org/citation.cfm?id=1411324 for a comparison.)
Concepts are required for at least the following purposes: 1) To put the generic programming features of C++ on a solid theoretical background 2) To provide a type system for templates 3) To simplify error messages. (Admitted 1 and 2 are closely related.) I am certain Herb knows all this, but I cannot guess why he chose to highlight reason 3 as the only reason for adding concepts to C++
Pingback: C++0x Concepts fall
C++ Programmer says:
A comment from Jeremy Siek, one of the co-authors of the C++ Concepts proposal:
"Sad day"
http://lambda-the-ultimate.org/node/3518#comment-50071
"While the Concepts proposal was not perfect (can any extension to C++ really ever be perfect?), it would have provided a very usable and helpful extension to the language, an extension that would drastically reduce the infamous error messages that current users of template libraries are plagued with.
It is a real shame that disagreement over what I viewed as an uncontroversial design point turned into the sticking point. […]"
In Bjarne's words ( http://www.ddj.com/article/printableArticle.jhtml?articleID=218600111&dept_url=/cpp/ ):
" […] this was a big disappointment for those of us who have worked on concepts for years and are aware of their potential […]"
"At the July 2009 Frankfurt meeting of the ISO C++ Standards Committee (WG21), the "concepts" mechanism for specifying requirements for template arguments was "decoupled" (my less-diplomatic phrase was "yanked out"). That is, "concepts" will not be in C++0x or its standard library. That — in my opinion — is a major setback for C++, but not a disaster."
"I and others preferred the first alternative ("fix and ship") and considered it feasible. However, a large majority of the committee disagreed and chose the second alternative ("yank and ship," renaming it "decoupling")."
"Surprisingly (maybe), there were no technical presentations and discussions about "concepts" in Frankfurt. The discussion focused on timing and my impression is that the vote was decided primarily on timing concerns."
Here come the managers!
Robert Jacques says:
"Today, 15 years later, that is still true; you can't express the STL's containers-algorithms design separation well, or at all, using generics facilities in Ada, Java, .NET, or any other significant commercial or research language that I know of"
Although you may be simply pointing out the problems with generics, I'd like to point out there are other languages which have templates. The D programming language (http://www.digitalmars.com/d/), even has template constraints, which serve a similar purpose to concepts. They've enabled simpler and more flexible functions. (e.g. the std.algorithm library: http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html)
Great report, Herb. I've been away from C++ for a couple of years, but I enjoy following up the improvements to the next version of the C++ Standard.
Thing is, C++ people tend to care whether the language figures things out at compile time or runtime. This is largely a cultural matter. C++ is a descendant of C, which was in part designed to write Unix in. Any systems implementation language has to be efficient. Lisp, on the other hand, was designed with little regard for efficiency, although some implementations have produced very efficient code. We tend to disregard efficiency on the desktop, but it's very important for servers and some forms of scientific computing.
The big advantage C++ templates have over Common Lisp macros is that C++ type information is available at compile time. The big advantage C++ templates have over the Common Lisp Object System is that they're all done at compile time instead of runtime. (The big disadvantage, of course, is that C++ templates are nowhere near as elegant as either of those Common Lisp features.)
C++ templates are therefore still the most versatile processing available at compile time, and this is still quite valuable.
Pingback: Concepts won't be in C++0x « cschleiden
Trey Jackson says:
I'm a bit confused over the distinction you draw between CL macros and the compile time type analysis provided in C++.
Strictly speaking, you may be right (that CL can't do what C++ does at compile time). As a user of languages, what do I care if the language figures things out at compile time or at runtime?
Looking at the selection of libraries boost provides, nearly all of them are either already provided/trivial in CL, or completely unnecessary. And while I admire the technical skills of the boost community, they've had to work *really* hard to provide the basic functionality found in CL (and many many other languages).
Regarding iterators and the data structure/algorithm separation provided by STL. That is certainly one way to solve the problem. CL approached the problem with a different solution, you can still define new types and register them appropriately such that they will blend in seamlessly with all the expected routines: setf, sort, merge, map, whatever…
Re Common Lisp macros — macros are similar in many ways to function or class templates, in the sense that they generate implementations of algorithms or data structures and are parameterized over structured data. (of course, by macros, I mean Lisp macros — not the broken things in C/C++).
Granted, I don't have much experience; however, I'm not aware in any Lisp of a protocol for macros to deduce information based on the compile-time type of its arguments. no problem, you can always explicitly provide it — you could write a macro "map" that works over any sequence type, provided a "sequence traits" parameter that, for instance, specifies how to iterate forward and such. You could — but who has? I don't mean just "iterate" — what about find, search, partition, sort!
Common Lisp excels in some other ways — it's easier to pass parameterized functions around since static type deduction need not be performed on its arguments. I challenge a C++ developer to show me an instance where they passed "std::search" as an argument to a function call — you can't easily, because static type deduction can't be performed yet, and function templates are not themselves objects. This is a big sore point in C++. CL, with its dynamic typing practice, doesn't need to perform type deduction on function arguments — it can be done at runtime or, with a sufficiently powerful optimizer, it can be _deferred_ until the point of call.
I would be interested in seeing a higher-order-macro based STL analogy. Perhaps calling "std::sort", you pass an ordering-predicate-macro ^_^. It would definitely be unique. But I don't think it would be usable. Even in CL, you really want functions, not macros, and you cannot pass macros as function arguments.
Thanks for the interesting thought experiment though. I think I'll be pondering this one for a while.
Andreas Fredriksson says:
"So my personal view is that templates have been in the 21st century since about 1994. No other language has yet caught up to their expressive power."
How are C++ templates more expressive than say Common Lisp macros, where code can be manipulated arbitrarily at compile time to create new syntactic elements at a whim?


When you're looking to buy or rent a property, there's a lot more to consider than the price alone.
Location, location, location! We're constantly being told how important it is to buy or rent a property in just the right spot, but how can you determine which suburb is right for you?
If you're buying an investment property, you really need to do some research and find suburbs that demand good rental prices. The last thing you want to do is spend money on a property in an area that no one wants to live in. Inner-city locations are always sought after, as are suburbs close to hospitals and tertiary institutions.
Before you start looking at properties, have a think about the type of lifestyle you enjoy. If you work and play close to the inner city, then it makes good sense to live nearby – you don't want to worry about how you're going to get home after Friday night drinks. If you have children and prefer a less congested and more family-oriented environment, your suburb choices should reflect that. Some people love the thought of home being a quiet sanctuary, so suburbs on the fringes of the city may work best.
We all have certain things we need to make our lives easier. Make a list of non-negotiable priorities you can tick off with each property you see. Many people like to be within walking distance of supermarkets, schools, public transport and parks. Or, if you're a social butterfly, cafes, bars, restaurants and cinemas in close proximity are a must.
Before you buy, get a real feel for the suburb. Check out the property at different times of the day. Is it difficult for visitors to get a park? How long does it take to walk to the station? Do you enjoy walking through the neighbourhood? You should feel comfortable with the suburb and its surrounds.
Don't forget to look into other costs that may impact where you buy, such as local council rates and body corporate fees (if you're looking to buy an apartment or unit). These will vary based on the area and property type. While you're at it, you can talk to us about the right electricity and gas plan for you, to estimate what you could pay for your energy.
Wherever you choose to rent or buy, make your decision a well-informed one to avoid any regrets.


In a series of debates with Oliver Cromwell in Civil War England of 1647, the Levellers argued for democracy for the first time in British history.
Evolving from Oliver Cromwell's New Model army in Parliament's struggle against King Charles I, the Levellers pushed for the removal of corruption in parliament, universal voting rights and religious toleration. This came to a head with the famous debates between the Levellers and Cromwell at St Mary's church in Putney, London. Renowned human-rights lawyer and author Geoffrey Robertson argues for the relevance of the Levellers' stand today, showing how they were the first Western radical democrats.


text:
Home » Bar Jokes
A dog goes into a bar and orders a martini
A dog goes into a bar and orders a martini. The bartender says, "You don't see a dog in here drinking a martini very often."
The dog says, "At these prices, I'm not surprised."
Category: Bar Jokes | No comments
A grasshopper hops into a bar
A grasshopper hops into a bar. The bartender says, "You're quite a celebrity around here. We've even got a drink named after you."
The grasshopper says, "You've got a drink named Steve?"
We don't serve your type here
Several fonts walk into a bar. "Get out of here!" shouts the bartender. "We don't serve your type here."
Horse serving drinks
A guy walks into a bar and finds a horse serving drinks. The horse asks, "What are you staring at? Haven't you ever seen a horse tending bar before?"
The guy says, "It's not that. I just never thought the parrot would sell the place."
A mushroom walks into a bar and orders a drink
A mushroom walks into a bar and orders a drink. The bartender tells him to get out. The mushroom says, "Why? I'm a fun-guy."
A pair of jumper cables
A pair of jumper cables walk into a bar and ask for a drink. The bartender says, "OK, but I don't want you starting anything in here."
Beer, please, and one for the road
A man walks into a bar with a chunk of asphalt under one arm. The man says, "Beer, please, and one for the road."
A penguin walks into a bar
A penguin walks into a bar, goes to the counter, and asks the bartender, "Have you seen my brother?"
The bartender says, "I don't know. What does he look like?"
A time traveler walks into a bar
The barman says, "We don't serve time travelers in here."
A time traveler walks into a bar.
An amnesiac walks into a bar
An amnesiac walks into a bar. He goes up to a beautiful blonde and says, "So, do I come here often?"
12345Next »Last »

redpajama_set_name: RedPajamaCommonCrawl


text:
Q: How do I form the union of scala SortedMaps? (I'm using Scala nightlies, and see the same behaviour in 2.8.0b1 RC4. I'm a Scala newcomer.)
I have two SortedMaps that I'd like to form the union of. Here's the code I'd like to use:
import scala.collection._

object ViewBoundExample {
    class X
    def combine[Y](a: SortedMap[X, Y], b: SortedMap[X, Y]): SortedMap[X, Y] = {
        a ++ b
    }
    implicit def orderedX(x: X): Ordered[X] = new Ordered[X] { def compare(that: X) = 0 }
}

The idea here is the 'implicit' statement means Xs can be converted to Ordered[X]s, and then it makes sense combine SortedMaps into another SortedMap, rather than just a map.
When I compile, I get
sieversii:scala-2.8.0.Beta1-RC4 scott$ bin/scalac -versionScala compiler version
2.8.0.Beta1-RC4 -- Copyright 2002-2010, LAMP/EPFL

sieversii:scala-2.8.0.Beta1-RC4 scott$ bin/scalac ViewBoundExample.scala
ViewBoundExample.scala:8: error: type arguments [ViewBoundExample.X] do not
    conform to method ordered's type parameter bounds [A <: scala.math.Ordered[A]]
        a ++ b
          ^
one error found

It seems my problem would go away if that type parameter bound was [A <% scala.math.Ordered[A]], rather than [A <: scala.math.Ordered[A]]. Unfortunately, I can't even work out where the method 'ordered' lives! Can anyone help me track it down?
Failing that, what am I meant to do to produce the union of two SortedMaps? If I remove the return type of combine (or change it to Map) everything works fine --- but then I can't rely on the return being sorted!

A: Currently, what you are using is the scala.collection.SortedMap trait, whose ++ method is inherited from the MapLike trait. Therefore, you see the following behaviour:
scala> import scala.collection.SortedMap
import scala.collection.SortedMap

scala> val a = SortedMap(1->2, 3->4)
a: scala.collection.SortedMap[Int,Int] = Map(1 -> 2, 3 -> 4)

scala> val b = SortedMap(2->3, 4->5)
b: scala.collection.SortedMap[Int,Int] = Map(2 -> 3, 4 -> 5)

scala> a ++ b
res0: scala.collection.Map[Int,Int] = Map(1 -> 2, 2 -> 3, 3 -> 4, 4 -> 5)

scala> b ++ a
res1: scala.collection.Map[Int,Int] = Map(1 -> 2, 2 -> 3, 3 -> 4, 4 -> 5)

The type of the return result of ++ is a Map[Int, Int], because this would be the only type it makes sense the ++ method of a MapLike object to return. It seems that ++ keeps the sorted property of the SortedMap, which I guess it is because ++ uses abstract methods to do the concatenation, and those abstract methods are defined as to keep the order of the map.
To have the union of two sorted maps, I suggest you use scala.collection.immutable.SortedMap.
scala> import scala.collection.immutable.SortedMap
import scala.collection.immutable.SortedMap

scala> val a = SortedMap(1->2, 3->4)
a: scala.collection.immutable.SortedMap[Int,Int] = Map(1 -> 2, 3 -> 4)

scala> val b = SortedMap(2->3, 4->5)
b: scala.collection.immutable.SortedMap[Int,Int] = Map(2 -> 3, 4 -> 5)

scala> a ++ b
res2: scala.collection.immutable.SortedMap[Int,Int] = Map(1 -> 2, 2 -> 3, 3 -> 4, 4 -> 5)

scala> b ++ a
res3: scala.collection.immutable.SortedMap[Int,Int] = Map(1 -> 2, 2 -> 3, 3 -> 4, 4 -> 5)

This implementation of the SortedMap trait declares a ++ method which returns a SortedMap.
Now a couple of answers to your questions about the type bounds:

*

*Ordered[T] is a trait which if mixed in a class it specifies that that class can be compared using <, >, =, >=, <=. You just have to define the abstract method compare(that: T) which returns -1 for this < that, 1 for this > that and 0 for this == that. Then all other methods are implemented in the trait based on the result of compare.

*T <% U represents a view bound in Scala. This means that type T is either a subtype of U or it can be implicitly converted to U by an implicit conversion in scope. The code works if you put <% but not with <: as X is not a subtype of Ordered[X] but can be implicitly converted to Ordered[X] using the OrderedX implicit conversion.
Edit: Regarding your comment. If you are using the scala.collection.immutable.SortedMap, you are still programming to an interface not to an implementation, as the immutable SortedMap is defined as a trait. You can view it as a more specialised trait of scala.collection.SortedMap, which provides additional operations (like the ++ which returns a SortedMap) and the property of being immutable. This is in line with the Scala philosophy - prefer immutability - therefore I don't see any problem of using the immutable SortedMap. In this case you can guarantee the fact that the result will definitely be sorted, and this can't be changed as the collection is immutable.
Though, I still find it strange that the scala.collection.SortedMap does not provide a ++ method witch returns a SortedMap as a result. All the limited testing I have done seem to suggest that the result of a concatenation of two scala.collection.SortedMaps indeed produces a map which keeps the sorted property.

A: Have you picked a tough nut to crack as a beginner to Scala! :-)
Ok, brief tour, don't expect to fully understand it right now. First, note that the problem happens at the method ++. Searching for its definition, we find it at the trait MapLike, receiving either an Iterator or a Traversable. Since y is a SortedMap, then it is the Traversable version being used.
Note in its extensive type signature that there is a CanBuildFrom being passed. It is being passed implicitly, so you don't normally need to worry about it. However, to understand what is going on, this time you do.
You can locate CanBuildFrom by either clicking on it where it appears in the definition of ++, or by filtering. As mentioned by Randall on the comments, there's an unmarked blank field on the upper left of the scaladoc page. You just have to click there and type, and it will return matches for whatever it is you typed.
So, look up the trait CanBuildFrom on ScalaDoc and select it. It has a large number of subclasses, each one responsible for building a specific type of collection. Search for and click on the subclass SortedMapCanBuildFrom. This is the class of the object you need to produce a SortedMap from a Traversable. Note on the instance constructor (the constructor for the class) that it receives an implicit Ordering parameter. Now we are getting closer.
This time, use the filter filter to search for Ordering. Its companion object (click on the small "o" the name) hosts an implicit that will generate Orderings, as companion objects are examined for implicits generating instances or conversions for that class. It is defined inside the trait LowPriorityOrderingImplicits, which object Ordering extends, and looking at it you'll see the method ordered[A <: Ordered[A]], which will produce the Ordering required... or would produce it, if only there wasn't a problem.
One might assume the implicit conversion from X to Ordered[X] would be enough, just as I had before looking more carefully into this. That, however, is a conversion of objects, and ordered expects to receive a type which is a subtype of Ordered[X]. While one can convert an object of type X to an object of type Ordered[X], X, itself, is not a subtype of Ordered[X], so it can't be passed as a parameter to ordered.
On the other hand, you can create an implicit val Ordering[X], instead of the def Ordered[X], and you'll get around the problem. Specifically:
object ViewBoundExample {
    class X
    def combine[Y](a: SortedMap[X, Y], b: SortedMap[X, Y]): SortedMap[X, Y] = {
        a ++ b
    }
    implicit val orderingX = new Ordering[X] { def compare(x: X, y: X) = 0 }
}

I think most people initial reaction to Ordered/Ordering must be one of perplexity: why have classes for the same thing? The former extends java.lang.Comparable, whereas the latter extends java.util.Comparator. Alas, the type signature for compare pretty much sums the main difference:
def compare(that: A): Int     // Ordered
def compare(x: T, y: T): Int  // Ordering

The use of an Ordered[A] requires for either A to extend Ordered[A], which would require one to be able to modify A's definition, or to pass along a method which can convert an A into an Ordered[A]. Scala is perfectly capable of doing the latter easily, but then you have to convert each instance before comparing.
On the other hand, the use of Ordering[A] requires the creation of a single object, such as demonstrated above. When you use it, you just pass two objects of type A to compare -- no objects get created in the process.
So there are some performance gains to be had, but there is a much more important reason for Scala's preference for Ordering over Ordered. Look again on the companion object to Ordering. You'll note that there are several implicits for many of Scala classes defined in there. You may recall I mentioned earlier that an implicit for class T will be searched for inside the companion object of T, and that's exactly what is going on.
This could be done for Ordered as well. However, and this is the sticking point, that means every method supporting both Ordering and Ordered would fail! That's because Scala would look for an implicit to make it work, and would find two: one for Ordering, one for Ordered. Being unable to decide which is it you wanted, Scala gives up with an error message. So, a choice had to be made, and Ordering had more going on for it.
Duh, I forgot to explain why the signature isn't defined as ordered[A <% Ordered[A]], instead of ordered[A <: Ordered[A]]. I suspect doing so would cause the double implicits failure I have mentioned before, but I'll ask the guy who actually did this stuff and had the double implicit problems whether this particular method is problematic.

redpajama_set_name: RedPajamaStackExchange


"SSNT really taught me about challenge and opportunity. Myotherapy is definitely growing in Australia and I think the quality of the Clinical Myotherapy students coming out of SSNT is extremely high. I think we're at the forefront of what's out there in the industry today."
Clinical myotherapy is a system of health care focusing on assessment, treatment and management of musculoskeletal pain. Musculoskeletal pain can be divided into three categories: myofascial pain arising from trauma or muscle contracture; neuropathic pain deriving from the nervous system; and articular pain that originates from the joints.
Clinical Myotherapists can treat various issues such as sporting and occupational injuries, stiffness and sore body, chronic overuse syndromes, symptoms associated with arthritis, back pain, neck pain, stress and tension, pregnancy and more.
This three-year degree is approved by TEQSA (Tertiary Education Quality and Standards Agency) the National Australian accreditation body. Students will gain theoretical knowledge in the biomedical and clinical sciences combined with a proficiency in clinical reasoning and the dexterity to utilise specific manual skills.
Students will learn how to ease muscle contracture and treat musculoskeletal pain caused by trauma, ageing and overload of muscles.
Students will gain hands on experience at Think Wellbeing Centre under the guidance of experienced practitioners in a clinical setting treating public patients. This prepares graduates to confidently and successfully commence practice in the community.
Career Prospects: Complementary clinics, Medical clinics, Sporting clubs and Industries that require the treatment of pain management and musculoskeletal treatment.
Course tuition fees are available by contacting a Course and Career Advisor. If you are an eligible domestic student you may choose to defer some, or all, of your tuition fees through FEE-HELP. And as we are a university you can also take advantage of no loan fees on FEE-HELP when you study selected courses with us.
Scholarships are available for this course to full-time on-campus students only.
* SSNT reserves the right to increase fees by up to 10% in each calendar year to cover increases in the cost of course delivery. The total course cost will depend on the duration of the course and whether a student studies full time or part time.
Online learning registered providers may offer overseas students up to one-third of their course online. If online or distance learning is offered, the registered provider must ensure that the overseas student is studying at least one unit that is face-to-face in each study period.
Each subject you complete includes 3 assessments on average. Assessments are mapped to specific subject learning outcomes and may include quizzes, written assignments, presentation, reflective journal, case analysis, literature review, practical exams and written exams.
Musculoskeletal Anatomy 2 builds upon the foundational knowledge of the formation and spatial relationships of the tissues and joints of the lower body that is gained in Anatomy and Physiology 1 (BHS101A) & Anatomy & Physiology 2 (BHS104A), and the musculoskeletal components of the human body gained in Musculoskeletal Anatomy 1 (CMY102A). This subject comprises the study of the back, thorax, pelvis, hip and lower limb. A practical component of this subject is essential and will incorporate anatomy wetlabs where available, so that students can examine specimens of tissues and regions of the human body in actuality. Dynamic anatomic and cadaveric software and models will also be part of the practical component.
Clinical Assessment 1 (CMY105A) will provide the student with the theoretical knowledge and practical skills required to perform a comprehensive musculoskeletal and neurological assessment of the upper body. These skills are important to the practising Clinical Myotherapist as they essentially underpin the clinical reasoning of a consultation process. Students work in pairs practising assessment skills on each other under close supervision. Due to the practical nature of this subject, students are given ongoing feedback on their techniques and application during class.
Students will be introduced to patient record keeping by keeping a log of the assessments they have undertaken and the outcomes they noted.
Surface Anatomy & Trigger Point Location 1 introduces the student to the palpation techniques used to identify specific muscles and their trigger points and referred pain patterns, preparing the student for myofascial dry needling. Students work in pairs to locate and explore bony landmarks, tendons, muscles, ligaments, pulses and other soft tissue structures and areas of the upper body and limbs. Due to the practical nature of this class, students are given ongoing feedback on their techniques and application during class.
A practical subject that covers a variety of soft tissue mobilisation methods including massage, myofascial release (MFR), cupping, muscle energy technique (MET), neuromuscular techniques and proprioceptive neuromuscular facilitation (PNF) stretching. Students will practise techniques on each other in the clinical classroom and under close supervision.
Musculoskeletal Anatomy 1 builds upon the foundational knowledge of the formation and spatial relationships of the tissues and joints of the upper body that is gained in Anatomy and Physiology 1 (BHS101A). This subject introduces students to the musculoskeletal components of the human body in a theoretical and practical setting, and comprises the study of the axial and appendicular skeleton (upper limb), nervous system, cervical and thoracic spine, head, and shoulder. A practical component of this subject will incorporate anatomy wet labs where available, so that students can examine specimens of tissues and regions of the body. Dynamic anatomic and cadaveric software and models will also be part of the practical component.
This subject studies the history of manual therapy and clinical myotherapy in Australia. Palpatory skills, thermal therapy, postural assessment and muscle management are introduced with attention to the comfort and safety of the patient and practitioner. WH&S and Healthcare law and ethics are introduced at a foundational level to complement the introduction to manual therapies and the initiation of industry placements.
Research & Evidence Based Practice (BHS107A) provides essential knowledge in research methods and research article evaluation for complementary medicine students. This subject introduces the fundamentals of research practice and methods for the natural therapies including research design, methodology, analysis and basic statistical skills. This subject provides the student with the proficiency to be able to appropriately read, analyse and evaluate current healthcare research.
Biochemistry 1 (BHS105A) is a core subject that builds upon the basic chemistry principles covered in Bioscience (BHS102A). It comprises an introduction to the basic biochemical compounds in the body. This subject includes the structure and function of carbohydrates, amino acids, proteins, enzymes, lipids and nucleic acid, DNA and RNA. The concept of gene expression and regulation is discussed in addition to cellular membrane structure and transport through the membrane.
Anatomy and Physiology 2 (BHS104A) builds and expands on the information and skills learnt in Anatomy and Physiology 1 (BHS101A). This subject continues to investigate the structure and function of the human body with special attention given to the interaction between tissues, organs and systems that maintain homeostasis. The structure and function of the respiratory, cardiovascular, immune, lymphatic and special senses systems are covered in detail including the homoeostatic control mechanisms of each system and the integration of the systems in the body.
The study of Anatomy and Physiology 2 (BHS104A) is vital in the education of healthcare practitioners to enable them to understand the structure and function of the human body as well as the importance of homeostasis and the ways in which the body maintains balance.
Counselling & Communication Skills (BHS103A) encompasses counselling skills commonly needed by complementary and alternative healthcare practitioners. This subject comprises a practical approach to a variety of communication skills and strategies including promoting change, compliance, obstacles to change, systems, transition and self-care. Sessions facilitate the development of effective listening and responding skills, increased personal awareness and insight in order to assist the building of a therapeutic relationship.
This subject is vital in the education of all complementary healthcare practitioners, as it enables them to understand and put into use communication skills essential for building a therapeutic relationship in practice and supporting clients through change.
Bioscience (BHS102A) provides a foundational knowledge for further studies in anatomy and physiology, clinical nutrition, biochemistry and pharmacology. It comprises the study of relevant concepts of general, physical and organic chemistry and includes atomic theory, the periodic table, chemical compound structure, nomenclature, behaviour and bonding as well as organic compounds and their basic properties and reactions.
Bioscience (BHS102A) is a crucial component of the modern healthcare practitioner's education in order to provide the basic building blocks for structural and therapeutic knowledge.
Anatomy and Physiology 1 (BHS101A) introduces the basic concepts and terminologies required to study and understand the structure and function of the human body. The interaction between tissues, organs and systems that maintain homeostasis is covered in detail. In addition, this subject covers the structure and function of cells and epithelial tissue, the internal structural anatomy of the human body and the integumentary and musculoskeletal systems.
This subject is vital in the education of all complementary health practitioners, as it enables them to understand the structure and function of the human body as well as the importance of homeostasis and the ways in which the body maintains this balance.
In this practical and theory based class the student will enhance their advancing palpation techniques to perform a comprehensive musculoskeletal and neurological assessment of the spine, sacro-iliac joint and TMJ. Working in pairs students will build on their practice assessment techniques in a supervised and feedback orientated environment. Students learning will emphasize critically analysing assessment methods based on current research and literature.
Pain Management 2 gives the students comprehensive information about the assessment, treatment, diagnosis and management of musculoskeletal conditions of the lower body. Students develop understanding of musculoskeletal conditions affecting the lower body including the aetiology, incidence, presenting signs and symptoms, clinical and diagnostic features. At the completion of Pain Management 2, students will be able to describe common pharmacological and cutaneous interventions for pain.
Myofascial Dry Needling 2 provides the student with further knowledge on myofascial trigger points and their associated pain patterns and further develops skills in dry-needling techniques. The focus is on muscles of the torso and lower body. Clinical Health Management provides the student with the ability to put together a Clinical Myotherapy treatment from history taking to assessment, diagnosis, treatment and management, and provides a platform for their future Clinical Practicum subjects. Due to the practical nature of this class, students are given ongoing feedback on their techniques and application during class.
Exercise Prescription 1 introduces students to the practical application of exercise as a therapeutic approach to patient management. The theories, principles and foundations of exercise prescription are applied to demonstrate suitable and appropriate types of exercise for a range of patient presentations. Students develop an ability to safely and effectively prescribe exercise under close supervision in a classroom situation. Due to the practical nature of this class, students are given ongoing feedback on their techniques and application during class.
Musculoskeletal Pathology encompasses the common pathological conditions that a Clinical Myotherapist will see in practice and builds upon the core pathological concepts provided in General Pathology (BHS201A). This subject address the morphology, aetiology and underlying general principles operating in disease states in the neurological, musculoskeletal and integumentary systems, in addition to select disease states in the endocrine and pulmonary systems. An introduction to the currently used laboratory diagnostic methods that would inform diagnosis of conditions in a general practise is also included in this subject.
This subject is a key component in the education of a Clinical Myotherapist, as it provides knowledge of the various disease states that will be seen in practice, and correlates these disease states at a cellular and gross anatomical level with clinical signs and symptoms.
Pain Management 1 gives the students comprehensive information about the assessment, treatment, diagnosis and management of musculoskeletal conditions of the upper body and builds upon the foundational knowledge acquired in subjects such as Anatomy & Physiology, Pathology and Clinical Assessment. Students develop understanding of musculoskeletal conditions affecting the upper body including the aetiology, incidence, presenting signs and symptoms, clinical and diagnostic features. At the completion of this subject students will be able to distinguish between acute and chronic pain states and evaluate the most effective methods of treatment and management employing sound clinical reasoning.
Myofascial Dry Needling 1 will provide the student with continued and additional information on myofascial trigger points and their associated pain patterns, and develop the ability to apply dry needling techniques in order to reduce the noxious activity of myofascial trigger points in the upper body. This subject will cover the practical application of the principles of infection control and will be delivered in accordance with current Australian safety standards. The ethical considerations for the practical application will be considered throughout and reflected upon in regards to needling for specific pathologies.
Biomechanics & Kinesiology introduces the students to the concepts of motion analysis for movements around a joint, forces involved in movement and positioning, and instrumentation for motion analysis. On completion of this subject, the students will be able to analyse movement from real-life examples, and discuss the forces involved. This subject provides the underpinning knowledge for exercise prescription.
Surface Anatomy & Trigger Point Location 2 furthers the student to the palpation techniques used in identifying specific muscles and their trigger points and referred pain patterns preparing the student for myofascial dry needling. Students work in pairs to locate and explore bony landmarks, tendons, muscles, ligaments, pulses and other soft tissue structures and areas of the lower body and limbs.
Neuroscience & Motor Control introduces students to International Association for the Study of Pain (IASP) terminology and aids the student in conceptualising the neurophysiology of pain. The IASP are a worldwide professional association dedicated to research, diagnosis and treatment of pain and, as such, set the standard for pain management guidelines. This subject provides students with a deeper understanding of human neuroanatomy and neurophysiology. The most recent theories regarding the development of pain and myofascial trigger points in the human body are discussed together with introducing students to the methods, procedure and contraindications of myofascial dry needling and the supporting evidence.
General Pathology (BHS201A) introduces the basic pathological processes operating in the body and the ways in which disease may result from injurious stimuli. Basic pathological processes of response to injury, growth abnormalities, degenerative disorders of the musculoskeletal and neurological systems, immunology, toxicology and microbiology, and their characteristic diseases are studied.
This subject is vital in the education of all complementary healthcare practitioners as it enables them to understand the nature of various disease states, and correlates these at a cellular and gross anatomical level with clinical signs and symptoms that may be seen in practice.
Myotherapy Clinical Practicum 3 is the final clinical practicum for the Clinical Myotherapy degree. Students are closely monitored by a suitably qualified and experienced practitioner. In this subject they are drawing on every aspect of their studies to assess, diagnose, treat, manage and refer patients in the student clinic environment.
Neuropsychology provides the student with knowledge about the psychological aspects of pain in the human body and psychological considerations in pain management. Students develop and explore knowledge of the current theories relating to the environmental dimensions and biopsychosocial influences of pain and their relationship to psychological issues. Neuropsychology will further increase the student's knowledge in health behaviour models, mental health issues and the role of social and occupational factors in pain management.
In this subject students write a literature review on a topic of their choice, which must examine a clinical aspect of their speciality. The emphasis is on presenting and critically evaluating current literature by searching for and appraising the literature, and writing a clear and fully referenced literature review. Students will be expected to present a proposal early in the trimester, and a full literature review by the end of the trimester. The in class experience is practical in nature where the students are provided a collaborative environment to cover the process of writing a literature review, ask questions and receive feedback on their own projects.
In Myotherapy Clinical Practicum 2, students continue the student clinic experience, integrating new information as other theoretical and practical subjects are completed. Students are closely monitored by a suitably qualified and experienced Clinical Myotherapist.
Pain Management 3 follows the curriculum provided by the International Association for the Study of Pain (IASP), discussing medical and alternative treatment and management of painful conditions. This curriculum provides the student with an in-depth understanding of the pain management strategies for a variety of conditions and an appreciation of other options of treatment and management.
Building on the knowledge and skills of Exercise Prescription 1 (CMY209A), and Lifespan Myotherapy (CMY301A) students are developing their exercise prescription skills to embrace a variety of resources, equipment, facilities, settings & venues in their management of specific conditions and special populations. Due to the practical nature of this subject, students are given ongoing feedback on their techniques and application during class.
In Myotherapy Clinical Practicum 1, students are introduced to working in a student clinic. Under the close supervision and monitoring of an experienced practitioner, students will begin to consult with and treat members of the public as they present with injuries or conditions. In this subject students are required to begin integrating all of the theoretical and practical studies undertaken in the course so far.
The clinical experience provides the student with an opportunity to formulate and implement evidenced based and relevant treatment plans while exhibiting appreciation of the necessary ethical and medico-legal responsibilities inherent in the practitioner-patient relationship.
Joint Mobilisation brings together the theory and practical approaches to assessment and treatment. This passive movement technique is applied to a spinal or peripheral joint in which an oscillatory movement is performed within the control of the patient. This subject draws on the 'concept' of treatment as developed by G. Maitland in which factors such as clinical reasoning, examination and evaluation are applied to the role of mobilisation in the management of musculoskeletal disorders.
Musculoskeletal Integrative Pharmacology comprises a study of basic principles of pharmacology, the pharmacokinetics of drugs commonly used in medical practice and common drug – drug and drug-myotherapy treatment strategy interactions. Drugs for pain, inflammation, psychological functions, cancer, infection and the cardiovascular, respiratory, gastrointestinal, reproductive and endocrine systems are discussed.
This subject examines drug actions, uses, contraindications, adverse effects and interactions, together with implications for myotherapy treatment strategies. Musculoskeletal Integrative Pharmacology is crucial for the modern myotherapy practitioner to understand common medications that clients may be taking and common interactions between these medications and treatments as well as medications that support myotherapy treatment strategies. This subject also emphasizes the need for clear lines of communication and common language between doctors and myotherapy practitioners in order to obtain the best health outcomes for clients.
Professional Practice (BHS401A) comprises the basic skills needed for the operation and management of a complementary healthcare practice and provides an understanding of the legal and ethical requirements that are pertinent to the complementary healthcare.
Sports Injury Management builds upon the clinical skills of assessment and treatment, with specific application to the athletic populations. This subject provides students with the underpinning theory and a range of practical skills to work in the sporting environment and support the prevention and management of common sporting injuries.
Professionalism, ethics and responsibilities are addressed, along with emergency action planning and on-field trauma management skills. Students will learn to apply evidence based and clinically reasoned decisions in sport specific return-to-play scenarios, and gain the practical skills to support return to play including taping and pre-game athlete support.
Students will be expected to complete clinical placement hours with a sporting club either previously or concurrently with this elective to support learning. Assistance to find placements will be provided.
Lifespan Myotherapy provides students with the knowledge of how to treat musculoskeletal pain that is relevant to paediatric and geriatric patients as well as in-depth knowledge on contraindications/precautions and acceptable treatments for pre and post-natal patients. This subject also provides students with knowledge about the impact of illness/injury/pain on quality of life. It incorporates theory on the history and efficacy of CAM and traditional remedies. Information relating to disease-specific population groups, as well as indigenous health issues and cultural implications for treatment will be incorporated.
This subject provides students with fundamental nutrition knowledge through examining the relationship between food, nutrition and human health. Students will learn about macro and micro-nutrition, dietary guidelines, role of nutrition in metabolism, health maintenance and disease, nutrient rich food sources, and the specific nutritional requirements throughout the lifespan. Students will also learn how to identify and construct a healthy diet according to specific dietary guidelines, and know the impact of nutritional deficiency and excess as they relate to health and disease.
The occupational environment plays an important role in combating or promoting the rise of chronic disease and disability. This environment has the capacity to affect the physical, psychological, economic and social well-being of workers' and thus, proper attention to workers' health offers vast opportunities for workers and employers alike. In this subject students will explore evidence linking worker health and wellbeing to organizational health and business performance. Specific analysis for business needs will be considered, with practical interventions designed to educate and enhance the occupational environment.
The problem of falls is a significant global issue and can result in injury, hospitalisation, loss of independence, social isolation, depression, poor health status, institutionalism and death. The World Health Organisation identify falls as occurring as a result of complex interrelationships between biological, behavioural, environmental and socioeconomic risk factors. With the predicted costs of falls expected to increase exponentially as our population ages there is a need for effective preventive strategies such as active ageing programs. This subject examines these complexities of ageing, where students will learn to assess falls risk and develop effective prevention strategies that promote wellbeing in ageing populations.
Here for good. We believe society is best served when our students, faculty, and our entire organisation use our collective skills and experience to create positive and lasting change. Our students and graduates are improving lives and making our world better. Our institutions are providing the critical skills, knowledge and support to help make this happen. Social Enterprise is an exciting theoretical based subject driven by the desire to create positive change through entrepreneurial activities. By providing students with a framework to understand business model generation and the skills to source, evaluate, and measure opportunities, Social Enterprise empowers students to conceptualise, develop, and propose new ventures that focus primarily on social change for good. In addition, this subject helps students understand and analyse different entrepreneurial business strategies, as well as incorporate theoretical discussions on major trends and issues in the social economy.
Industries that require the treatment of pain management and musculoskeletal treatment.


text:
Sir Richard Sutton vermoor deur vennoot se seun in 'ontploffing van geweld', hof gesê
'n Seun het 'n mesaanval op sy ma en haar lewensmaat geloods, die miljoenêr sakeman sir Richard Sutton, op die herdenking van sy pa se dood, seething with resentment over how he felt the couple had treated him, 'n moordverhoor gehoor het.
Thomas Schreiber, 35, who killed Sutton, 83, a hotelier and landowner, and inflicted life-changing injuries on Anne Schreiber, 66, believed the pair favoured his two sisters, which left him feeling like an outcast, the jury was told.
The court also heard that there had been two violent incidents before the knife attack, including one that erupted during a row over a chandelier and ended with Sutton hitting Schreiber so hard with his walking stick that it broke.
Tensions were also rising before the "explosion of violence" in April at the family's Dorset mansion because Schreiber, his mother and her partner were locked down together at the height of the Covid pandemic, it is alleged.
Adam Feest QC, prosecuting, said there was no disputing that Schreiber had killed Sutton and seriously injured his mother, but that the defendant's state of mind would be a key element for the jury to consider. Schreiber denies murder and attempted murder.
Jurors heard a string of messages recorded in the weeks and months before the attack in which Schreiber expressed his hatred for his victims and talked of revenge.
He told one friend: "I have a plan which I'm working on … Revenge is at its heart." He confided to another: "I would like to get a gun and shoot a bullet in my mum's face and Richard's." The month before the attack he wrote: "My mind is consumed with hatred of the very worst kind towards my family … I contemplate murdering them … day and night … I want them to suffer."
Schreiber visited his father's grave on the day of the attack. His mother told police she was in the kitchen when she turned to see him holding a 15cm long knife. His eyes were "almost frightening to look at because they looked terribly, terribly determined", sy het gese. He appeared wild and "very, very unusual, very, very out of control".
She suffered as many as 15 wounds and needed about 27 litres of blood products – the human body holds between four and six litres. Among her injuries was a vertical cut to the right side of her face from her eyebrow to her chin, but the most significant was a partial transection of the spinal cord, which had caused "serious, ongoing physical consequences", the jury was told.
Feest said Sutton had been estranged from his wife, Lady Fiamma Sutton, for almost 20 years while Anne Schreiber and her husband, David Schreiber, separated in about 2002-03. Dit, the prosecutor said, was caused at least in part by David Schreiber's alcoholism, which put a strain on their marriage emotionally and financially.
In die somer van 2003 Anne Schreiber and her three children were invited by Sutton to move to his mansion, Moorhill. David Schreiber moved into a cottage on the estate where he lived until his death in 2013.
Feest said the defendant took his father's side and felt his mother was "toxic" and she and his sisters "gold-diggers".
In Christmas 2018 after a trip to Wincanton races, the family argued over the defendant not offering to drive, the court was told. Sutton intervened, and may have swung a fist at Schreiber, who hit the older man in the face.
In November 2020 Ms Schreiber suggested to one of her daughters, Louisa, that she might have one of their grandmother's chandeliers.
Schreiber lost his temper and became abusive to his sister. Sutton stepped in and hit Schreiber across the back with his walking stick so hard it snapped.
After the attack on his mother and her partner in April, Schreiber fled and telephoned relatives and friends. He told one friend: "I've killed my mum and I've killed Richard and I'm here lying in blood and I'm about to kill myself."
In a reference to the chandelier episode, he told another: "I don't appreciate being knocked around by Richard."
Die verhoor duur voort.
hof, explosionviolence, killedpartners, Richard, Sutton
Supreme court rejects Trump bid to shield documents from January 6 panel
prem	 1 dag gelede
The US supreme court has rejected a request by Donald Trump to block the release of White House records to the congressional committee investigating the deadly January 6 attack on the Capitol, dealing a blow to the fo...
High court to hear claims Sarah Everard vigil ban breached human rights
Women's rights activists are at the high court to argue that the police's decision to ban a vigil for Sarah Everard in London was a breach of their human rights. The Metropolitan police were criticised last March afte...
Loud loos: the court case that ruled flushing at night was anti-social
Naam: Loud loos. Ouderdom: 19 jare. Voorkoms: It's more about sound than looks, occurrence than appearance. OK then, occurrence: Regularly, throughout the night. And what particular sound are we talking about here? Die...
Arron Banks may have been 'used and exploited' by Russia, hof verhoor
The Observer and Guardian journalist Carole Cadwalladr has told a court she believes the multimillionaire Brexit backer Arron Banks may have been "used and exploited" by the Russian government, as she defended her rep...
Fate of Nazi-looted Pissarro to be decided by US supreme court
Depicting a rainswept Paris street, the Nazi-looted painting has long hung on the walls of one of Madrid's top art museums. Its fate is now in the hands of the highest court in the US, in a case that has long pitted t...
Novak Djokovic faces deportation from Australia after federal court upholds visa cancellation
Novak Djokovic will be deported from Australia ahead of the Australian Open after the full federal court dismissed the world No 1's bid to restore his visa. On Sunday the court rejected a challenge to the decision of ...
Windrush descendants lose high court fight to expand scheme
Four Windrush generation descendants have lost their high court battle for the scheme for victims to be widened to include them. Yvonne Williams, Yvonne Smith, Jennifer Ulett-Hall and Damian Gabrielle argued in the hi...
Canadian court halves prison sentence of woman who killed abusive husband
A Canadian court has halved the sentence of a woman who killed her husband, revisiting a controversial case that revealed the legal system's "outdated thinking" of the realities of domestic abuse. In 'n 2-1 ruling rele...