addressalign-toparrow-leftarrow-leftarrow-right-10x10arrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcredit-cardcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobe--smallglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1languagelaunch-new-window--smalllight-bulblightning-boltlinklocation-pinlockm-swarmSearchmailmediummessagesminusmobilemoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstar-shapestartickettrashtriangle-downtriangle-uptwitteruserwarningyahooyoutube

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

From: Rob D.
Sent on: Saturday, December 25, 2010, 1:13 PM
Hey all!

I've been working on a few topics that I would be interested in presenting, but since I just got married this past fall, I have not had much time to put together any presentations.

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.

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."

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.

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.

Any interest in these? Could certainly use some feedback on the breadth or depth desired for these topics.

Happy Holidays!
-Rob Douglas



On Sat, Dec 25, 2010 at 12:03 PM, Conrad Weisert <[address removed]> wrote:
Although the weather may be miserable, we want to keep the momentum going for the Chicago C/C== User Group with a meeting in January or February.

I have something I'd like to present, but I prefer to wait until spring, since I spoke to the group last year.

We need either a volunteer speaker or some good ideas. Let's hear them.




--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Conrad Weisert ([address removed]) from Chicago C/C++ Users Group.
To learn more about Conrad Weisert, visit his/her member profile


Meetup, PO Box 4668 #37895 New York, New York[masked] | [address removed]