<div dir="ltr">[...]<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Readability is definitely better in C++11 when avoiding iterators and<br>
using lambdas, but I was kind of hoping we could avoid those ugly cases. I<br>
wasn't thinking of using the STL heavily, just a few containers like<br>
string, and perhaps others for any specialized use cases.<br>
<br>
</blockquote>
<br>
Sadly, containers means iterators, inevitably, and yes C++03 syntax is<br>
ugly, but you get used to it, and just type it automatically. Pity "auto"<br>
and "for( a: container )" is C++11, oh well.<br>
</blockquote>
<br></div>
Yes. Unless we use a foreach macro ;-P<br></blockquote><div><br></div><div>m-m-m-m-m-macro?</div><div><br></div><div>There seems to be a typo here, I assume you mean the std::for_each template :)</div><div><br></div><div>
And of course requiring the use of a function object declared immediately before the for_each, not a function declared some distance away.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I'm not sure iterators are needed often for string though, but it's been a while since I looked at code using it.</blockquote><div><br></div><div>Ahh, I may have been misunderstanding you again.</div><div><br></div>
<div>Strictly strings are not containers, so I havn't considered them whenever you said container, I was thinking vector, list, etc.</div><div><br></div><div>I find iterators are rarely used on strings because it has operator[] and most of the operations return an index, not an iterator.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I proposed banning OOP, operator overloading and exceptions in src to make<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
it (much?) easier to understand & maintain the code vs idiomatic C++, with<br>
all its unintuitive bug-prone corner cases (which are still in C++11), see<br>
my reply to Lex for more info.<br>
<br>
<br>
</blockquote>
Looking at it again, I'm not sure we mean the same thing by OOP, its a much<br>
abused and overloaded term, could you perhaps explain your meaning?<br>
  Depending on what you mean, banning it is either sensible, or the silliest<br>
idea ever :)<br>
</blockquote>
<br></div>
I mean inheritance and virtual functions. I don't think they would pull their weight in src, unless we were going to use gtkmm for custom widgets.</blockquote><div><br></div><div>Agree I can't immediately think of places where inheritance is likely to be useful at high level, but thats no reason to ban it.</div>
<div><br></div><div>Mind you, the concepts of document and filetype could be combined by deriving a filetype specific document type from the base Document class, allowing filetype specific overriding of functions like indenting :)</div>
<div><br></div><div>class Perl_document::Document { etc };</div><div><br></div><div>Which brings me to the point that some *design* and planning might be useful before we start hacking.</div><div><br></div><div> [...]</div>
<div><br></div><div>Cheers</div><div>Lex</div></div></div></div>