| woodbrian77@gmail.com: Jun 25 02:21PM -0700 On Thursday, June 25, 2015 at 6:04:48 AM UTC-5, Öö Tiib wrote: > 10-15 member functions in class is quite livable but 40 is > smelly (too lot of responsibilities) and should be perhaps > split up. Well, std::string has I think over 40 member functions. It's considered to be a mess I guess, but the only thing I can think of to make it better would be to remove either the size or length member function that do the same thing. And I'm guilty of asking for a function to be added to the class. I'd like to see a constructor added that takes a char const* and an integer for how many more bytes beyond the length of the char const* to allocate. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| "Öö Tiib" <ootiib@hot.ee>: Jun 25 12:04PM -0700 On Thursday, 25 June 2015 21:07:15 UTC+3, Lynn McGuire wrote: > > clashes. > No bugs? > Amazing. May be he broke some unit test in process but fixed right away so his push was clear. Such refactorings should be anyway done when new version or new library is introduced that causes the clashes. That can happen at start of maintenance cycle. Clashes can't suddenly start with release candidate in feature freeze? |
| legalize+jeeves@mail.xmission.com (Richard): Jun 25 07:47PM [Please do not mail me a copy of your followup] Rosario19 <Ros@invalid.invalid> spake the secret code >there is no need of C++ namespaces or other namespaces... >namespaces are just the file names where functions are stored >where file names are path+namefile where is the function I disagree completely. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Robert Wessel <robertwessel2@yahoo.com>: Jun 25 03:44PM -0500 On Thu, 25 Jun 2015 13:06:55 -0500, Lynn McGuire <lmc@winsim.com> wrote: >> clashes. Namespaces *are* meant as tool for avoiding name >> clashes. >No bugs? What cases would exist where removing the "using namespace std;" isn't just going to result in obvious compilation errors for any references to things in std? |
| "Skybuck Flying" <skybuck2000@hotmail.com>: Jun 25 10:43PM +0200 Hello, I was just trying to explore "blood"'s leaked source code.. :) and I noticed my SkybuckODE wasn't displaying C/CPP highlighting properly. I think it might be a bug... Anyway what seems to solve it is this: Switch to another drive... and view some source code in c/cpp... then switch back to whatever drive... the app was on or so... and start viewing source there.. Bye for now, Skybuck. |
| legalize+jeeves@mail.xmission.com (Richard): Jun 25 07:59PM [Please do not mail me a copy of your followup] noreply@example.com spake the secret code >tradeoff is that I can no longer really use "line numbers" in the editor >(when using lists) because there's no direct index into the list, whereas >with a vector it would be directly supported. Have you considered using a value type that explicitly represents a line of text and the file line number on which it resides? typedef std::pair<unsigned, std::string> line_t; typedef std::list<line_t> line_container_t; >I will try both, then, and see how they perform. Vectors would certainly >be easier for maintaining "dot" (the current line in ED/EX/VI parlance), >whereas today "dot" is maintained as an iterator (effectively like a pointer). In addition to looking at rope classes (a good suggestion), there is another possibility. You might also want to take a look at "string views". The idea here is to have a class that represents a view into some string data held elsewhere but doesn't actually hold the string. There is a standards proposal paper from 2013 on this: <https://isocpp.org/files/papers/N3762.html> I wrote up something similar to a string view that I called a "string chain": <https://gist.github.com/LegalizeAdulthood/7b67968bd93fbd4f9dbb>. In my case I was parsing an email file and wanting to get a a single thing that I could manipulate that would be all the text associated with a header field. (Header fields can be split across multiple physical lines with intervening whitespace, but the whitespace is not part of the header field value.) In my case the source data is a memory-mapped file, so I simply needed to scan through it looking for interesting segments to join together into a whole unit that I called a chain. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| noreply@example.com: Jun 25 08:09PM > N)) performance for random inserts/erases which is essential for an editor. > For more information go to http://www.i42.co.uk/stuff/segmented_array.htm > neolib::segmented_array<char> would be ideal. Very interesting! Why is everyone suggesting that the editor be character oriented, instead of line oriented? I would have thought something more like: neolib::segmented_array<string> ? I've been going on the model of "line oriented" because in reality, VI is a full screen front end to a line-oriented underlay (ED/EX)... ? Cheers, -RK -- Robert Krten Visit me at http://www.ironkrten.com |
| noreply@example.com: Jun 25 08:13PM > line of text and the file line number on which it resides? > typedef std::pair<unsigned, std::string> line_t; > typedef std::list<line_t> line_container_t; I did, and rejected it on the basis that if I do a deletion then I have to go and renumber all the lines (after the deletion). Same with an insertion / move / copy. The pathological case "g/^/.m0" would be a disaster. > memory-mapped file, so I simply needed to scan through it looking for > interesting segments to join together into a whole unit that I called a > chain. More food for thought, thanks! Cheers, -RK -- Robert Krten Visit me at http://www.ironkrten.com |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 25 09:40PM +0100 > I would have thought something more like: > neolib::segmented_array<string> > ? No, that wouldn't be a good idea. A custom data structure based on segmented_array<char> that also has updatable iterators to lines within that data structure would be more appropriate. > I've been going on the model of "line oriented" because in reality, VI > is a full screen front end to a line-oriented underlay (ED/EX)... Editors can also have paragraphs and pages not just lines. /Flibble |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment