<p dir="ltr"><br>
On May 1, 2013 6:13 AM, "Vane, Edwin" <<a href="mailto:edwin.vane@intel.com">edwin.vane@intel.com</a>> wrote:<br>
><br>
> Your list has a good mix of different sized projects. Some of the points are clearly more useful to the community than others so I would recommend organizing your list that way. That said, starting with projects that are interesting to you is a good idea for keeping your motivation high:)<br>
><br>
> The only item I'm not sure of is using vector::data() and string::data(). I haven't really seen any compelling reason for converting existing &operator[i] calls. I'm fine to be convinced otherwise.</p>
<p dir="ltr">One minor reason is that the &op[i] version is undefined in the case of an empty vector, but people often don't bounds check this operation (because they also pass a zero size to whatever code receives the buffer, so it's never dereferenced, which is usually sufficient)</p>
<p dir="ltr">><br>
> > -----Original Message-----<br>
> > From: Guillaume Papin [mailto:<a href="mailto:guillaume.papin@epitech.eu">guillaume.papin@epitech.eu</a>]<br>
> > Sent: Tuesday, April 30, 2013 1:22 PM<br>
> > To: Vane, Edwin<br>
> > Cc: <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> > Subject: Re: [cfe-dev] GSoC project ideas<br>
> ><br>
> > "Vane, Edwin" <<a href="mailto:edwin.vane@intel.com">edwin.vane@intel.com</a>> writes:<br>
> ><br>
> > >> -----Original Message-----<br>
> > >> From: Guillaume Papin [mailto:<a href="mailto:guillaume.papin@epitech.eu">guillaume.papin@epitech.eu</a>]<br>
> > >> Sent: Monday, April 29, 2013 5:25 PM<br>
> > >> To: Vane, Edwin<br>
> > >> Cc: <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> > >> Subject: Re: [cfe-dev] GSoC project ideas<br>
> > >><br>
> > >> I added some comments and wrote a summary of the new plan at the end<br>
> > >> of the mail.<br>
> > >><br>
> > >> "Vane, Edwin" <<a href="mailto:edwin.vane@intel.com">edwin.vane@intel.com</a>> writes:<br>
> > >><br>
> > >> > Comments below.<br>
> > >> ><br>
> > >> >> -----Original Message-----<br>
> > >> >> From: Guillaume Papin [mailto:<a href="mailto:guillaume.papin@epitech.eu">guillaume.papin@epitech.eu</a>]<br>
> > >> >> Sent: Sunday, April 28, 2013 9:13 PM<br>
> > >> >> To: Vane, Edwin<br>
> > >> >> Cc: <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> > >> >> Subject: Re: [cfe-dev] GSoC project ideas<br>
> > >> >><br>
> > >> >> I'm working on the proposal and would like to have your feedback<br>
> > >> >> about the following plan regarding cpp11-migrate.<br>
> > >> >><br>
> > >> >><br>
> > >> >> Tasks<br>
> > >> >> =====<br>
> > >> >><br>
> > >> >> Table of Contents<br>
> > >> >> =================<br>
> > >> >> 1 Transform to replace 'auto_ptr' by 'unique_ptr'<br>
> > >> >> 2 Transform for delegating constructors<br>
> > >> >> 3 Transform for non-static data member initializers<br>
> > >> >> 4 Add support for interactive actions<br>
> > >> >> 5 Default transformation profile<br>
> > >> >> 6 Integrating LibFormat<br>
> > >> >> 7 Transform to make use existing of move constructors<br>
> > >> >> 8 Generate a diff of the changes<br>
> > >> >> 9 Other incomplete ideas<br>
> > >> >><br>
> > >> >><br>
> > >> >> 1 Transform to replace 'auto_ptr' by 'unique_ptr'<br>
> > >> >> ==================================================<br>
> > >> >><br>
> > >> >> Seems like a good transform to start.<br>
> > >> >><br>
> > >> > I agree. It's not completely trivial due to semantic differences<br>
> > >> > between auto_ptr and unique_ptr (e.g. no destructive copy in<br>
> > >> > unique_ptr) but should be a good first big project.<br>
> > >> ><br>
> > >><br>
> > >> I had this in mind (non-triviality) as you mentioned it in an earlier mail.<br>
> > >><br>
> > >> >> 2 Transform for delegating constructors<br>
> > >> >> ========================================<br>
> > >> >><br>
> > >> >> A transform that can convert code such as:<br>
> > >> >><br>
> > >> >> struct A<br>
> > >> >> {<br>
> > >> >> int x;<br>
> > >> >><br>
> > >> >> A() : x(0) { }<br>
> > >> >> A(int _x) : x(_x) { }<br>
> > >> >> };<br>
> > >> >><br>
> > >> >><br>
> > >> >> Into:<br>
> > >> >><br>
> > >> >> struct A<br>
> > >> >> {<br>
> > >> >> int x;<br>
> > >> >><br>
> > >> >> A() : A(0) { } // now use delegation<br>
> > >> >> A(int _x) : x(_x) { }<br>
> > >> >> };<br>
> > >> >><br>
> > >> >><br>
> > >> >> This is a really trivial case here but I expect this transform to<br>
> > >> >> be non-trivial to implement.<br>
> > >> >><br>
> > >> ><br>
> > >> > A test for determining if the functionality of one constructor is<br>
> > >> > completely subsumed by another would be really difficult to do. I'm<br>
> > >> > not sure the benefit of a few less lines of code and some improved<br>
> > >> > maintainability is really worth it. There is the common workaround<br>
> > >> > of having constructors call init() functions that might be easier<br>
> > >> > to handle but still, I think there are more useful things to focus<br>
> > >> > on first.<br>
> > >> ><br>
> > >><br>
> > >> Okay, I will remove this of the list then.<br>
> > >><br>
> > >> I was considering handling only constructors with empty bodies (at<br>
> > >> least for the one 'delegated') and only simple expressions in<br>
> > >> initialization (such as parameters, literals, ...). But it was mostly<br>
> > >> for aesthetics reasons and some other transforms might be more beneficial<br>
> > (tr1?).<br>
> > >><br>
> > >> >> 3 Transform for non-static data member initializers<br>
> > >> >> ====================================================<br>
> > >> >><br>
> > >> >> When one or more constructor initialize a member variable with<br>
> > >> >> a value independant from the constructor arguments the<br>
> > >> >> initialization can be placed in-class.<br>
> > >> >><br>
> > >> >> This might be beneficial when multiple constructors are duplicating<br>
> > >> >> member initialization.<br>
> > >> >><br>
> > >> >> Note that this transform might easily leads to conflicts with the<br>
> > >> >> previous transform (delegating constructors).<br>
> > >> >><br>
> > >> ><br>
> > >> > Also questionable implementation/benefit ratio. You'd have to<br>
> > >> > ensure every member variable is initialized the same way by every<br>
> > >> > constructor. If you detect such a case, that would mean removing<br>
> > >> > all the existing initializations and adding the in-class initialization.<br>
> > >> > All that's left is to hope the user didn't mind making some vars<br>
> > >> > initialized by constructors and some by the in-class initializers.<br>
> > >> ><br>
> > >><br>
> > >> I totally agree. I will remove it from the list.<br>
> > >><br>
> > >> >> 4 Add support for interactive actions<br>
> > >> >> ======================================<br>
> > >> >><br>
> > >> >> Some actions might need user interaction.<br>
> > >> >><br>
> > >> >> Example (maybe not the best one):<br>
> > >> >> If some replacement code needs to introduce a new variable and<br>
> > >> >> that the default identifier is already taken then we might want to<br>
> > >> >> prompt the user for an alternative name.<br>
> > >> >><br>
> > >> >> Or simply to ask confirmation before a risky replacement.<br>
> > >> >><br>
> > >> ><br>
> > >> > Definitely something we'd like to add to the migrator but requires<br>
> > >> > some design first. User interactivity should be implemented in such<br>
> > >> > a way that the actual user interface doesn't matter. That way one<br>
> > >> > could write a plugin for an editor/IDE or just have a simple<br>
> > >> > command-line interface. This implies some sort of library interface<br>
> > >> > for cpp11-migrate and cpp11-migrate itself then turns into a library.<br>
> > >> > LibFormat and clang-format have the same relationship. I'm not sure<br>
> > >> > if this much design work is suitable to a GSoC project.<br>
> > >> ><br>
> > >><br>
> > >> I see. Actually this idea was very vague. I will remove it from the<br>
> > >> list as I don't think I'm well suited (yet?) to start designing such a library.<br>
> > >><br>
> > >> >> 5 Default transformation profile<br>
> > >> >> =================================<br>
> > >> >><br>
> > >> >> Apply a list of transformation by default and allow different<br>
> > >> >> profiles. By profile I'm talking about an option such as:<br>
> > >> >><br>
> > >> >> cpp11-migrate -target-profile=[clang-3.2|gcc-4.7|...] ...<br>
> > >> >><br>
> > >> >><br>
> > >> >> This option will enable all known safe (low-risk/zero-risk)<br>
> > >> >> transformations to the input files and are supported by the given<br>
> > >> >> target.<br>
> > >> >><br>
> > >> >> This could allow incremental migration toward C++11. Let's say the<br>
> > >> >> project has to support Clang 3.1 in a first place and later on the<br>
> > >> >> minimum version switch to 3.2, they can re-run the tools with the<br>
> > >> >> new profile.<br>
> > >> >><br>
> > >> ><br>
> > >> > This is kinda cool. It's certainly not much work right now since<br>
> > >> > there are only a handful of transforms. It'd be a slightly nicer<br>
> > >> > way than just saying --all-transforms (if such an option existed)<br>
> > >> > especially for people out there migrating code that's tied to a<br>
> > >> > particular compiler version.<br>
> > >> ><br>
> > >> > Remembering the discussion about C++11 on llvm-dev a while back,<br>
> > >> > maybe you could even specify a list of compilers to this flag and<br>
> > >> > the common subset of supported features is applied :)<br>
> > >> ><br>
> > >><br>
> > >> I actually had this in mind as well (but maybe an unconscious memory<br>
> > >> from the discussion on llvm-dev?).<br>
> > >><br>
> > >> >> 6 Integrating LibFormat<br>
> > >> >> ========================<br>
> > >> >><br>
> > >> >> In order to format correctly inserted code.<br>
> > >> >><br>
> > >> ><br>
> > >> > Would definitely be nice. The transforms don't do too much to<br>
> > >> > mangle code right now but any that use the TypePrinter to print out<br>
> > >> > types will cause the 'const' to go on the wrong side of the type<br>
> > >> > specifier according to most styles. (i.e. const MyType *A => MyType<br>
> > >> > const A*). I don't think LibFormat handles const locations though<br>
> > >> > yet, probably for the same reason the transforms are limited in<br>
> > >> > dealing with const qualifiers currently: clang doesn't provide enough<br>
> > TypeLoc info.<br>
> > >> ><br>
> > >><br>
> > >> Good.<br>
> > >><br>
> > >> >> 7 Transform to make use existing of move constructors<br>
> > >> >> ======================================================<br>
> > >> >><br>
> > >> >> With move semantics added to the language and the standard library<br>
> > >> >> being updated accordingly (move constructors added to many types),<br>
> > >> >> it is now interesting to take an argument by value and then moving<br>
> > >> >> it (as opposed to take by 'const &' and then copy).<br>
> > >> >><br>
> > >> ><br>
> > >> > Could be useful. Also in this category would be use of<br>
> > >> > stl_container::emplace() functions. You'll have to be very, very<br>
> > >> > careful about semantics though.<br>
> > >> ><br>
> > >><br>
> > >> Well, I guess this idea will be a good fit for second half of the GSoC.<br>
> > >><br>
> > >> >> 8 Generate a diff of the changes<br>
> > >> >> =================================<br>
> > >> >><br>
> > >> >> Add an option to print a diff of the modifications against the<br>
> > >> >> original source file.<br>
> > >> >><br>
> > >> ><br>
> > >> > Could be useful as a kind of 'dry-run' mode where changes are not<br>
> > >> > actually<br>
> > >> made but one could find out how many and what sort of changes were made.<br>
> > >> ><br>
> > >><br>
> > >> I will remove this one from the list. It has been pointed out the SCM<br>
> > >> tools already provide such functionality quite well. I think for most<br>
> > >> projects using cpp11-migrate they will already be under source control<br>
> > management.<br>
> > >><br>
> > >> I was thinking about users that are curious about the tool (or C++11)<br>
> > >> who might want to try cpp11-migrate on a file non-destructively. But<br>
> > >> an option for the output file or directory would be easier to<br>
> > >> implement and as useful. But then, what if an included file is<br>
> > >> modified? Is it necessary to reproduce the source tree structure?<br>
> > >><br>
> > ><br>
> > > These questions you ask indicate why it's just more complex for<br>
> > > cpp11-migrate to handle this sort of thing. The easiest option would<br>
> > > be to run the migrator on your source, use SCM to see the diff and<br>
> > > then use SCM to undo the changes: easy non-destructive investigation.<br>
> > > Without SCM you could just copy your code-base and do a directory<br>
> > > diff. Also easy.<br>
> > ><br>
> > >> >> 9 Other incomplete ideas<br>
> > >> >> =========================<br>
> > >> >><br>
> > >> >> If the charge of the previous ideas is not sufficient for the<br>
> > >> >> GSoC I'm confident there is more work to do.<br>
> > >> >><br>
> > >> >> - initializer_list and uniform initialization transforms (use<br>
> > >> >> cases not identified yet)<br>
> > >> ><br>
> > >> > Someone once suggested to me looking for:<br>
> > >> ><br>
> > >> > Std::vector<int> A;<br>
> > >> > A.push_back(a);<br>
> > >> > A.push_back(b);<br>
> > >> > ...<br>
> > >> > A.push_back(z);<br>
> > >> ><br>
> > >> > And replacing with<br>
> > >> ><br>
> > >> > Std::vector<int> A = {a,b,...,z};<br>
> > >> ><br>
> > >> > I'm not entirely sure this is worth the effort. That is, how often<br>
> > >> > is a vector initialization done this way? I'm not aware of other<br>
> > >> > use cases right now.<br>
> > >> ><br>
> > >><br>
> > >> I was think about easier cases (more commonly used?) such as:<br>
> > >><br>
> > >> struct A<br>
> > >> {<br>
> > >> A(int a, int b);<br>
> > >><br>
> > >> int a;<br>
> > >> const char *b;<br>
> > >> };<br>
> > >><br>
> > >> A bar()<br>
> > >> {<br>
> > >> return F(1, "toto"); // -> return { 1, "toto" };<br>
> > >> }<br>
> > >><br>
> > ><br>
> > > I actually kinda like this use of uniform initialization. Using braced<br>
> > > init lists in return statements is really helpful. Granted, it's more<br>
> > > helpful in new code that you're writing. I wouldn't be against adding<br>
> > > this as a smallish project to add to your proposal if you liked.<br>
> > ><br>
> ><br>
> > I will add this (restrained?) case to the list. It can be a base for future work on<br>
> > using uniform initialization.<br>
> ><br>
> > >><br>
> > >> // code such as:<br>
> > >> F ary[] = { A(1, "foo"), A(2, "bar"), A(3, "foobar") };<br>
> > >> // becomes:<br>
> > >> F ary[] = { {1, "foo"}, {2, "bar"}, {3, "foobar"} };<br>
> > >><br>
> > >> // returning object by calling the constructor<br>
> > >> std::vector<int> foo(bool arg)<br>
> > >> {<br>
> > >> if (!arg)<br>
> > >> return std::vector<int>(); // -> return { };<br>
> > >><br>
> > >> std::vector<int> results;<br>
> > >> // <fill-in results...><br>
> > >> return results;<br>
> > >> }<br>
> > >><br>
> > >><br>
> > >> But I think they have a limited usefulness and I don't want to add<br>
> > >> this to my proposal.<br>
> > >><br>
> > >> And I agree, I don't think it's that common to initialize a vector in such a way.<br>
> > >> Maybe to initialize some static containers and using a factory<br>
> > >> functions<br>
> > >> (see:<br>
> > >> <a href="http://stackoverflow.com/questions/3701903/initialisation-of-static-">http://stackoverflow.com/questions/3701903/initialisation-of-static-</a><br>
> > >> vector).<br>
> > >> In this situation it would be good to get rid of the factory function<br>
> > >> and initialize the vector directly, which seems to add a lot of complexity.<br>
> > >><br>
> > >> >> - tr1 replacements. Doing everything might not be possible but at<br>
> > >> >> least some would be useful such as: unordered_map, smart<br>
> > >> >> pointers, function<> & bind(), tuple.<br>
> > >> ><br>
> > >> > This one in particular is high priority. I think pretty much<br>
> > >> > everything in<br>
> > >> > TR1 except the extra math functions is in C++11.<br>
> > >> ><br>
> > >><br>
> > >> One thing I'm afraid with this task is that to be useful it requires<br>
> > >> to implement all the changes from tr1. If we change the include by dropping<br>
> > 'tr1/'<br>
> > >> it means we should support the transformation of everything the #include<br>
> > has.<br>
> > >> Maybe it's not risky at all to drop out 'tr1/' in the include<br>
> > >> directives and the reference to the namespace 'tr1::' but I don't<br>
> > >> know yet. If I understand correctly<br>
> > >> C++11 has some difference with tr1 but only additions, mostly to<br>
> > >> C++benefit of the<br>
> > >> new languages features.<br>
> > >><br>
> > >> Also, I think someone already talked about this, it will be<br>
> > >> interesting to find some open source project using tr1 to apply the<br>
> > >> transformation. I took a quick look, it doesn't seem impossible to find some.<br>
> > >><br>
> > ><br>
> > > Since Marshall suggested the transform I bet he has some TR1 code he'd like<br>
> > to transform. Perhaps he can point us at some open-source code to test on.<br>
> > ><br>
> > > The first part of implementing this transform would be to do an<br>
> > > inventory of TR1 and research what made it into C++11 and what didn't<br>
> > > and what changes, if any, were made to things that did make it in. I'd<br>
> > > split this inventory into three lists: Stuff that appears exactly in<br>
> > > C++11 as it does in TR1, stuff that didn't make it at all, and stuff<br>
> > > that made it but with changes. The first list is the easiest to<br>
> > > address: just drop 'tr1::' and modify the #includes to use the right<br>
> > > STD header. The stuff that didn't make it is also pretty easy: don't<br>
> > > change anything. The third list will just need to be a bunch of<br>
> > > special cases hard-coded into the transform.<br>
> > ><br>
> > > I think this transform has high value and could be straightforward to get<br>
> > something useful working. It only requires a bit of research to start.<br>
> > ><br>
> ><br>
> > Okay, it really sounds like a valuable inclusion to the project. I will add it to the<br>
> > list.<br>
> ><br>
> > >> >> - fixing existing bugs (I think it's a good way to get around the<br>
> > >> >> project before starting the GSoC to get acquainted with the<br>
> > >> >> code)<br>
> > >> ><br>
> > >> > I agree.<br>
> > >> ><br>
> > >> >> - and (much) more...<br>
> > >> >><br>
> > >> ><br>
> > >> > Another option could be looking at additions to STL for C++11 and<br>
> > >> > making changes based on those additions. I mentioned emplace earlier.<br>
> > >><br>
> > >> I haven't thought looking at this but it's a good idea. Functions<br>
> > >> such as emplace as you pointed-out is a perfect example of a tranform<br>
> > >> people might want to benefit by using cpp11-migrate.<br>
> > >><br>
> > >> > Another option could be looking for nested calls to std::max or<br>
> > >> > std::min to do an N-wise horizontal max/min op:<br>
> > >> > std::max(std::max(a,b), std::max(c,d)) => std::max({a,b,c,d});<br>
> > >> > Again, not sure how useful this particular case is. Another<br>
> > >> > suggestion was replacing use of C arrays with std::array. I haven't<br>
> > >> > looked into the implications of this myself though. Yet another<br>
> > >> > option is something done by the remove-cstr tool in<br>
> > >> > clang-tools-extra. C++11 allows you to create std::fstreams with a<br>
> > >> > std::string directly now instead of calling std::string::c_str().<br>
> > >> ><br>
> > >><br>
> > >> For std::array I'm not sure, I think it's usefulness is limited to<br>
> > >> small number of situations.<br>
> > >><br>
> > >> I like the idea of removing std::string::c_str() calls for std::fstream.<br>
> > >><br>
> > >> Also:<br>
> > >> - the access of vector data, can be replaced from '&vec[0]'/'&vec.front()' to<br>
> > >> 'vec.data()'. I haven't looked if something more has to be taken care of<br>
> > >> here.<br>
> > >> - already mentioned in the tooling doc: replace member functions<br>
> > >> begin()/end() by their free function equivalent.<br>
> > >><br>
> > >><br>
> > >> To resume the list of apparently interesting ideas:<br>
> > >> - Transform to replace 'auto_ptr' by 'unique_ptr'<br>
> > >> - Transform to use free-function std::begin()/std::end()<br>
> > >> - Integrating LibFormat<br>
> > >> - Default transformations, profiles<br>
> > >> - Transform to remove call to std::string::c_str() when using<br>
> > >> std::fstream<br>
> > >> - Transform to make use existing of move constructors<br>
> > >> - Transform to make use of new emplace functions for STL containers<br>
> > >> - [maybe] tr1 replacement (need to know more about the implications)<br>
> > >> - [maybe] Command line option for output file / output directory<br>
> > >> - [maybe] Make use of new std::vector.data() / std::string::data()?<br>
> > ><br>
> > > Do you want our feedback on prioritizing this list?<br>
> > ><br>
> ><br>
> > Here is my list ordered by the order I would like to implement things (not order<br>
> > of importance). I haven't thought carefully yet about the time it would take.<br>
> ><br>
> > - Transform to replace 'auto_ptr' by 'unique_ptr' [*]<br>
> > - Transform to use free-function std::begin()/std::end()<br>
> > - Transform to use uniform-initialization on return by calling a constructor<br>
> > - Transform to remove call to std::string::c_str() when using std::fstream<br>
> > - Integrating LibFormat [*]<br>
> > - Default transformations, profiles [*]<br>
> > - Transform to replace uses of tr1 [*]<br>
> > - Transform to make use existing of move constructors [*]<br>
> > - Transform to make use of new emplace functions for STL containers<br>
> > - [maybe] Make use of new std::vector.data() / std::string::data()?<br>
> ><br>
> > I marked with [*] the one I consider the most important to have.<br>
> ><br>
> > Yes any feedback is most welcomed !<br>
> ><br>
> > Thank you.<br>
> > --<br>
> > Guillaume Papin<br>
><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</p>