- Some C++14 code - 18 Updates
- Special link-list algorithm help - 7 Updates
| Tim Rentsch <txr@alumni.caltech.edu>: Jul 17 11:57PM -0700 > std::list instead of a contiguous buffer with occasional reallocation, > i.e. "garbage collection. I agree, however, that std::list is more > convenient. A good suggestion IMO. A problem with lists (as I think Bjarne has pointed out) is they suffer from lack of cache locality, so in practice arrays/vectors nearly always do better. Compacting the array could be done all at once or might be doable incrementally. If the data structure is central to the application this kind of alternative is worth investigating; if it isn't, I think either approach is reasonable, just choose whichever one seems like an easier fit. |
| boltar@cylonHQ.com: Jul 11 10:22AM On Wed, 11 Jul 2018 21:27:08 +1200 >> They don't make that much difference to the application programmer. >They make a huge difference to the application programmer, that's why we >use them... No they don't, they just make code more concise. And if you do anything complicated with templates beyond just using the STL you eventually end up having to use specialisation and/or typeid() sprinkled around your code when you get down to the point where types have to processed individually which is little different to what you'd have to do in C from the start. |
| Juha Nieminen <nospam@thanks.invalid>: Jul 11 08:01AM > Back when C was invented the return type should have been last. After > all, it's the last thing you'll need from the function. But it wasn't. By that same logic the type of a variable should also come after the name of the variable. (After all, there are language that work like that.) C++ is complex enough. Maybe we should at least *try* to minimize the different number of ways to write the same thing, unless there's a very good reason to add an alternative. Purely cosmetic reasons are not enough. (And yes, backwards compatibility ought to be retained for practical purposes. If you want to create an entirely new language, nothing is stopping you.) |
| Bart <bc@freeuk.com>: Jul 10 11:47PM +0100 On 10/07/2018 23:20, Vir Campestris wrote: > Now there are reasons for having it last, and that's why the new syntax. > Trouble is we're all old fashioned C programmers at heart, and don't > like change... so the new one looks odd. But then the 'auto' keyword looks odd; what does it mean, since here it's not working out the return type for itself? Perhaps try this: #define function auto function main() -> int ... and join the half of the world's languages which use a keyword to introduce a function definition. (I notice Jonathan Blow didn't have a problem with this aspect of C++ as his new language hasn't addressed that: you still have to work out where functions start and end by analysing a bunch of syntax see if it matches the pattern for the start of a function instead of the keyword just telling you.) -- bart |
| boltar@cylonHQ.com: Jul 11 02:30PM On Wed, 11 Jul 2018 12:14:27 -0000 (UTC) >that contains a vector or a map in it (whose elements might >also contain vectors or maps...) memcpy() isn't going to cut >it. It's just going to break the program really badly. Certainly for complex types you'd have to pass in a function pointer to a function you wrote that would be called to do the actual copy. The above was just for example purposes, not a definitive API. However the point is that for probably 90% of what C++ containers get used for the C equivalent wouldn't be too much extra work to use. >libraries out there. They look horrible, and they are horribly >inefficient (every additional malloc() you do, makes it less >efficient.) C++ isn't magic - it still ultimately has to allocate memory whether it be on the stack or heap. That will take the same amount of time as in C. |
| boltar@cylonHQ.com: Jul 11 11:07AM On Wed, 11 Jul 2018 22:25:21 +1200 >> you get down to the point where types have to processed individually which >> is little different to what you'd have to do in C from the start. >Do I? That's good to know. Well perhaps you don't if you're just writing mickey mouse code. Some of us have had to however. |
| Vir Campestris <vir.campestris@invalid.invalid>: Jul 10 11:20PM +0100 On 10/07/2018 07:29, Juha Nieminen wrote: > it just seems needlessly complicated for no good reason. Everybody and > their grandmother understands "int main()", and using the trailing type > syntax serves mostly the use of making the code harder to read. I'll bite. Back when C was invented the return type should have been last. After all, it's the last thing you'll need from the function. But it wasn't. Now there are reasons for having it last, and that's why the new syntax. Trouble is we're all old fashioned C programmers at heart, and don't like change... so the new one looks odd. If you ever start on a green field project with a code standard that forces it you'll be used to it in 3 months, and the old one will look odd. (but I don't think I've started on a greenfield project since 19-something) Andy |
| boltar@cylonHQ.com: Jul 11 11:14AM On Wed, 11 Jul 2018 13:51:50 +0300 >With above, a C programmer needs to take great care how to use a >supposedly standard tool - does it need malloc, not malloc, free, not >free, ensure correct types are used in each invocation. The resulting An API as above is not going to allocate containers on the stack so some sort of free() will be required even if its wrapped in an API delete function. >exemplar takes extra care, the programmer hesitates to add another one >and will rather go to the inefficient and error-prone >array[i_believe_this_is_sufficient_buffer_size] approach instead. Or You might, I wouldn't. I've used these sorts of APIs and I've never had a problem with them but I imagine someone who's only ever used C++ might struggle a bit when having to manually handle memory and multiple types. >alternatively, if he indeed adds the needed number of those containers, >he will have no attention span left for his own work, all his efforts >have just been spent on ensuring that he has used a standard tool correctly. Only if he's a poor programmer. |
| Vir Campestris <vir.campestris@invalid.invalid>: Jul 10 11:11PM +0100 > You ever read the STL source code? Its enough to make anyone weep. There's > no reason a similar library (albeit without the templating) couldn't be > written in C and then the application code using it would look a lot tidier. The whole point of the standard TEMPLATE library is the templates. But yes, I have read it. And yes, it's horrible. Andy |
| boltar@cylonHQ.com: Jul 11 09:26AM On Tue, 10 Jul 2018 17:44:38 +0200 >It's rvalue-qualified so the machinery can be used to construct a menu >in a single expression, like this (it's my actual code at the moment): > $with( gui_ext::Auto_parent{ *this } ) Wtf is "$with" ? Is this C++ or Perl or have you been messing about with macros? >In between the resulting FLTK menu bar and the pure data Itemlist's << >machinery, is a generator class Menu_bar that translates the hierarchy >of menu items to FLTK menu text paths, for FLTK menu creation. Yes, it's Congratulations. You've added things to a menu bar in a complicated and no doubt highly inefficient under the hood way. |
| Ian Collins <ian-news@hotmail.com>: Jul 11 10:25PM +1200 > having to use specialisation and/or typeid() sprinkled around your code when > you get down to the point where types have to processed individually which > is little different to what you'd have to do in C from the start. Do I? That's good to know. -- Ian. |
| Juha Nieminen <nospam@thanks.invalid>: Jul 11 12:14PM > struct vector *vectorCreate(enum type *type); > int vectorAdd(struct vector *vec, void *value); > int vectorErase(struct vector *vec, int pos); There's a huge difference because that "vector" does not know how the element values should be copied or assigned. That might work with elementary types and PODs, but once it gets any more complicated than that, it becomes either a nightmare or impossible. For example, suppose that the element is a struct that contains a vector or a map in it (whose elements might also contain vectors or maps...) memcpy() isn't going to cut it. It's just going to break the program really badly. Essentially you would need to replicate constructors, copy constructors, assignment operators and destructors in C, by manually passing and storing tons of pointers around (which don't need to be stored in C++). Yes, I have seen such C libraries out there. They look horrible, and they are horribly inefficient (every additional malloc() you do, makes it less efficient.) |
| boltar@cylonHQ.com: Jul 11 09:19AM On Tue, 10 Jul 2018 23:11:04 +0100 >> no reason a similar library (albeit without the templating) couldn't be >> written in C and then the application code using it would look a lot tidier. >The whole point of the standard TEMPLATE library is the templates. They don't make that much difference to the application programmer. The C equivalent would be something like: struct vector *vectorCreate(enum type *type); int vectorAdd(struct vector *vec, void *value); int vectorErase(struct vector *vec, int pos); struct map *mapCreate(enum type keytype, enum type valtype); int mapAdd(struct map *map, void *key, void *value); or something like that where a negative return value would be an error and >= 0 would be an array position. I'm sure there are many similar libraries out there already and in fact the berkeley DB library which ships with every version of unix I've ever used, allows you to do something similar anyway, albeit with a somewhat complicated API since its a lightweight DB , not just a collection. |
| Paavo Helde <myfirstname@osa.pri.ee>: Jul 11 01:51PM +0300 > int vectorErase(struct vector *vec, int pos); > struct map *mapCreate(enum type keytype, enum type valtype); > int mapAdd(struct map *map, void *key, void *value); Thanks for sharing this horror code from C, sometimes we tend to forget how much good is there in C++. With above, a C programmer needs to take great care how to use a supposedly standard tool - does it need malloc, not malloc, free, not free, ensure correct types are used in each invocation. The resulting code cannot be probably refactored in any way because the dangers of mixing up e.g. int and long are too great. The main problem with that style is that it does not scale. As each exemplar takes extra care, the programmer hesitates to add another one and will rather go to the inefficient and error-prone array[i_believe_this_is_sufficient_buffer_size] approach instead. Or alternatively, if he indeed adds the needed number of those containers, he will have no attention span left for his own work, all his efforts have just been spent on ensuring that he has used a standard tool correctly. |
| Juha Nieminen <nospam@thanks.invalid>: Jul 11 07:43AM > same as you might get in Python or Ruby in Javascript; the details will > vary but you will get the values 10, 20, 30, and 40 printed out in some > form and in that order. A language like C++ isn't intended to dictate to the programmer what the text format of something like a list of numbers should be. This especially given that for consistency it would also need to support "std::cin >> v;" which becomes a mess given in how many ways that can fail. > You can write a printlist() routine for a generic list to get it > displayed as you want. So can you in C++. > (How would a debugger for C++ display such a vector?) That's up to the debugger, not up to the C++ standard. > with existing arrays) than the C++ where such things have to be > implemented using its language building features. And the syntax for > invoking those has limitations. I have no idea what you are talking about, or what it has anything to do with a language syntax being "fragile". I suspect you have no idea either. |
| Bart <bc@freeuk.com>: Jul 11 01:48PM +0100 On 11/07/2018 13:14, Juha Nieminen wrote: > that contains a vector or a map in it (whose elements might > also contain vectors or maps...) memcpy() isn't going to cut > it. It's just going to break the program really badly. If things are that complicated then I might suggest that neither C++ nor C is the right language. Look at CPython for example, which allows all those complex container types, in spades, and using dynamic typing to boot (so you can have a vector of ANY mix of types). But CPython is written in C. Using C++ wouldn't bring much to the table, since /its/ container types cannot directly be used for those in Python. > libraries out there. They look horrible, and they are horribly > inefficient (every additional malloc() you do, makes it less > efficient.) That wouldn't really happen as you wouldn't bother with anything so complex in C. Either those vectors contain only 'flat' elements that can simply be allocated or copied as a block, or you have special handling for the elements /that is part of the application/. -- bart |
| Ian Collins <ian-news@hotmail.com>: Jul 11 09:27PM +1200 >>> written in C and then the application code using it would look a lot tidier. >> The whole point of the standard TEMPLATE library is the templates. > They don't make that much difference to the application programmer. They make a huge difference to the application programmer, that's why we use them... -- Ian. |
| Manfred <noname@add.invalid>: Jul 10 08:01PM +0200 On 7/10/2018 7:23 PM, Stefan Ram wrote: > int main(){ two_argument_constructor_no_list INITIALIZER_LIST; } > transcript > two_argument_constructor_no_list ;) http://shop.oreilly.com/product/0636920033707.do Item 7 |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 11 08:47AM -0400 On 7/10/2018 5:56 PM, Mr Flibble wrote: > Too late mate: Terry A. Davis has beaten you to it. He had all the same > goals you had His goals are similar in some areas, but different overall. I communicated with Terry many years ago before TempleOS was called by that name. It was an interesting design departure from traditional OS designs. He introduced me to the concept of char being the default type to be unnatural, and that it should've been unsigned char. I had never thought of that before, but the moment he said it I agreed. :-) > and he accomplished them in his mind's eye. Now he just > randomly shouts at dust motes. He has been very open and public about his mental problems, issues, and maladies. He takes medication, and he has a plethora of mental issues. He also cites hearing responses directly from God in several areas, many of which contradict things taught in the Bible. My heart goes out to him. > https://en.wikipedia.org/wiki/TempleOS > Please take your medication. When you are better spend your time on more > useful endeavours. I'll give your advice the full swath of consideration it demands, Leigh. -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 11 08:49AM -0400 On 7/11/2018 5:57 AM, Anton Shepelev wrote: >> This is Terry. Seems like a very odd demented thing. > The OS in very interesting regardless of the author: > http://www.codersnotes.com/notes/a-constructive-look-at-templeos/ A channel I watch on YouTube did a video on it a few months back: Shine OS a better Temple OS https://www.youtube.com/watch?v=qsunFPbQDYc -- Rick C. Hodgin |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jul 10 03:22PM -0700 On 7/10/2018 2:56 PM, Mr Flibble wrote: > https://en.wikipedia.org/wiki/TempleOS > Please take your medication. When you are better spend your time on > more useful endeavours. This is some pretty crazy shi% man: https://www.reddit.com/user/TempleOSV413 There seems to be some strange white power and pedophile crap in there. Very weird! I wonder if Rick has conversed with this "thing"? |
| Anton Shepelev <anton.txt@g{oogle}mail.com>: Jul 11 12:57PM +0300 Chris M. Thomasson: > Just a bunch of crap associated with TempleOS. > This is Terry. Seems like a very odd demented thing. The OS in very interesting regardless of the author: http://www.codersnotes.com/notes/a-constructive-look-at-templeos/ -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived] |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jul 10 03:24PM -0700 On 7/10/2018 3:22 PM, Chris M. Thomasson wrote: > This is some pretty crazy shi% man: > https://www.reddit.com/user/TempleOSV413 > There seems to be some strange white power and pedophile crap in there. Unfortunately, I just read it a bit more carefully, and things got even more dark and weird. I don't even want to quote anything in that pile of whack job garbage! ;^o > Very weird! I wonder if Rick has conversed with this "thing"? Wow. |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jul 10 03:29PM -0700 On 7/10/2018 3:22 PM, Chris M. Thomasson wrote: > https://www.reddit.com/user/TempleOSV413 > There seems to be some strange white power and pedophile crap in there. > Very weird! I wonder if Rick has conversed with this "thing"? Is this the guy that created TempleOS: https://www.reddit.com/r/programming/comments/5s7wu4/templeos_red_sea_file_system_and_block_chains/ Here is one of his comments, with a terrible word censored in q-bert speak: ___________________________ I had fat32 at first and made redsea second by design. I am shrewd. I do not fight the last war like a zombie ni%%$#. Actually it was because FAT32 was patented and I could not use a fat table. They kept pestering me about FAT32 being patented, so I made my own just in case. God planned the development of TempleOS. It is divine intellect. ___________________________ Just a bunch of crap associated with TempleOS. This is Terry. Seems like a very odd demented thing. |
| Keith Thompson <kst-u@mib.org>: Jul 10 04:03PM -0700 "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> writes: [BIG SNIP] > whack job garbage! ;^o >> Very weird! I wonder if Rick has conversed with this "thing"? > Wow. WHY. ARE. YOU. POSTING. ABOUT. THIS. HERE??? -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister" |
| 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