- Cloud cuckoo land? - 2 Updates
- C++ variable names - 3 Updates
- transactional memory idea - 3 Updates
| Daniel <danielaparker@gmail.com>: Jan 17 06:54PM -0800 On Friday, January 17, 2020 at 5:24:40 PM UTC-5, Mr Flibble wrote: > Now fuck off you homophobic, sexist cockwomble. "It was the kind of newsgroup where, if you couldn't swear at home, you could go there and do it." -- Jim Thompson, "The C++ Inside Me" |
| woodbrian77@gmail.com: Jan 18 01:09PM -0800 On Friday, January 17, 2020 at 12:52:06 AM UTC-6, Christian Gollwitzer wrote: > unclear why something was changed, and the large number of 600 commits > seemingly indicating an active project reduces to only a handful useful > commits. I think you are missing the forest for the trees. This is the CMW ambassador: https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc On a scale of 1 to 10 how would you rate it? I'd give it at least a 7. It's a well-behaved server. It builds fast and runs efficiently. Also, the code in the repo is the tip of the iceberg. The back tier, which is private, isn't in the repo. There are many changes to the back tier that don't show up as commits in the repo. Brian Ebenezer Enterprises http://webEbenezer.net |
| Lynn McGuire <lynnmcguire5@gmail.com>: Jan 17 06:52PM -0600 On 1/16/2020 4:11 PM, Öö Tiib wrote: > It can be tricky for three star programmer to understand what they > do without such notation OTOH it is unclear if it does help. > <https://wiki.c2.com/?ThreeStarProgrammer> I won't be showing you my three star programming then. Lynn |
| Manfred <noname@add.invalid>: Jan 18 04:22PM +0100 On 1/16/2020 11:11 PM, Öö Tiib wrote: > It can be tricky for three star programmer to understand what they > do without such notation OTOH it is unclear if it does help. > <https://wiki.c2.com/?ThreeStarProgrammer> Note that, as far as I read somewhere, the Hungarian notation was initially introduced to indicate the "intention or kind" of a variable or function, which is not that silly of an idea - in fact you always use the variable name to indicate its purpose, the Hungarian decoration introduced some kind of naming convention with this respect. For example, I read it was initially used to identify the coordinate system some point would belong to (page, print margins, ...) in MS Office applications. It ended up being misused to encode the variable type in its name, which is indeed questionable at best, and definitely unfit for generic programming. |
| "Öö Tiib" <ootiib@hot.ee>: Jan 18 10:41AM -0800 On Saturday, 18 January 2020 17:22:30 UTC+2, Manfred wrote: > or function, which is not that silly of an idea - in fact you always use > the variable name to indicate its purpose, the Hungarian decoration > introduced some kind of naming convention with this respect. I have also only read about it somewhere. Charles Simonyi is over 70 years old, probably the idea has changed over time. By my impression it was invented to have notation of "kind" of variable in BCPL programming language (ancestor of C) that did not have types. That made indeed perfect sense in type-less language but why should same used in C or C++, where we have static types? > For example, I read it was initially used to identify the coordinate > system some point would belong to (page, print margins, ...) in MS > Office applications. There can be lot of meta information about variables and types of those so it is perhaps hard to mangle that into variable name. Different people have different idea what is important enough to indicate it and how to indicate it and so it is perhaps best to indicate nothing. IDEs tend to show type of variable under cursor anyway. > It ended up being misused to encode the variable type in its name, which > is indeed questionable at best, and definitely unfit for generic > programming. I haven't seen a single case where it did not feel cryptic and hard to follow. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 17 03:49PM -0800 On 1/17/2020 12:10 AM, Bonita Montero wrote: > Another issue: why do I have to write decltype(syncedOp) or why > is C++ too stupid to deduce the lambda-type itself. If it could > I could write the lambda directly in the function-call. Post this over on comp.arch. I generally dislike transactional memory, but thats just me. There are places where a nice TM can be used in the writer side of a RCU algorihtm. Readers read, full steam ahead, not even caring about any transaction. However, the writers use the transactions when they mutate the data-structure. The readers are totally free, the writers are not. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 18 03:49AM +0100 >>> requires the caller to have a lambda /variable/. >> Why should this be a problem ? > It imposes needless verbosity and bug vectors on the calling code. No, that's not bug-prone. >> too large. > No, there is no connection between the way you do cleanup (unsafely, or > as I propose safely) and the transaction working set. RAII-safeness isn't needed here. There are no resources which might be allocated in a transaction because a transaction has to be a simple piece of code whose working-set should fit in the L1-cache. >> I do that with a bool which can hold two states ? > In the same way as your current code which you snipped, which returns > either 0 or 1. Ok, but your bool-wrapper is stupid. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 18 04:57AM +0100 >>> requires the caller to have a lambda /variable/. >> Why should this be a problem ? > It imposes needless verbosity and bug vectors on the calling code. I'm asking myself what a by-reference lambda should be good for. Having by-copy-captures disables modification of those captures if you don't jave a mutable lamda anyway. By-reference-captures can't also be modified, but just the referenced values. So passing a lambda by const-reference is useless. |
| 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