addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupshelp-with-circleimageimagesinstagramlinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

Re: [Chicago-C-CPP-Users-Group] Winter meeing

From: Nevin ".
Sent on: Wednesday, December 29, 2010 5:53 PM
I for one am definitely interested in all three of these topics!

On 25 December[masked]:17, Rob Douglas <[address removed]> wrote:
The first topic I am considering is Iterators vs. Ranges, with an additional look as to how they may evolve in C++0x, though that could even be its own topic. Ranges have thus far been considered as simply a pair of iterators, or a container supplying a begin() and end(), or a static array with a known length, or a stream with some special end-of-stream flag. This topic would go over the STL as it currently is, discussing some of the design ideas, and some of the drawbacks they elicit. It would also look at boost iterator adaptors and ranges, and the recent work that has been done in them, with my take on how they should be changed. Do iterator based algorithms really make sense as range based algorithms? Are there design problems or redundancies with the STL algorithms? What performance considerations might be involved in range based algorithms, over iterator based ones? How does one compose ranges who have subranges that are dependent length/dimensions of the parent-range?
If there's any additional issues with this, that people are interested in, please let me know. I would likely need to be break it up into several presentations.

I think exploring the tradeoffs (expressability, performance, container mutability, iterator/range invalidation, etc.) would make this a very interesting talk.
The second topic I am looking at is "Code analysis: Recognizing 'Informative' vs. 'Operative' Code." Basically, C++ takes C, a language where nearly every piece of written code translates into machine instructions, (operative code) and adds a swath of code which informs the user or the compiler, for numerous reasons. The discussion (more than a strict presentation) would look to highlight this distinction. This is a much rougher topic, as I've never heard anyone talk about it explicitly, though I've found it to be the basis for a lot of arguments between developers, lumped under "code style."

While less technical than the range talk, this could get a lot of discussion going.? It is a different way of looking at the language and the power we get from it over C.
If there is significant interest, I would be glad to go over C++0x's lamdas facility, which I have been using a lot in my own iterator/range research. That might be able to pushed into a full hour long presentation, on it's own.

It could easily be its own presentation.? Two things I'd like to see covered are (1) is there any practical use for the new std::bind once you have the C++0x lambda facility, and (2) what do the various lambda libraries (boost::lambda, boost::phoenix::lambda, etc.) give us that the C++0x lambda facility doesn't (such as polymorphic lambdas).

I doubt, though, that I could get any of these presentations ready by the end of January, but February may be possible. Spring would definitely be likely, too.

(I figure there won't be much feedback on this until next year.)?? Let us know when you can present!

?Nevin ":-)" Liber? <mailto:[address removed]>? (847)[masked]

Our Sponsors

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy