- Comparing Protocol Buffers and the C++ Middleware Writer - 6 Updates
- Formatting Ouput with Punctuation (Commas) - 6 Updates
- reinterpret_cast question (with correction!) - 7 Updates
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 08 04:01PM +0100 On Mon, 8 Aug 2016 14:54:22 +0200 "Fred.Zwarts" <F.Zwarts@KVI.nl> wrote: [snip] > rule, because this is the (almost?) only exception to the rule that a > genitive is expressed with "apostophe s" in English. So, the error is > understandable. You are right that it is understandable, but 'its' is not a genitive. In the expression referred to ("its use") it is a possessive adjective, equivalent to 'zijn' in your own language. Other possessive adjectives are my, your, his, her, our and their (the religious maniacs on this group would probably also include 'thy'). The word 'its' can also be used as a possessive pronoun, but that was not the case in the usage in question. The genitive is one of the few remaining old case forms for nouns in English. I believe Dutch also used to have the same form of a suffixed s, at least where the noun is the name of a person (and maybe still has, I don't know). Chris |
| Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Aug 08 12:08PM -0600 On Mon, 08 Aug 2016 13:48:38 +0100, Ben Bacarisse >> care to explain for the english impaired? >"It's" is a contraction of "it is" or "it has" ("it's been ages since we >spoke", "it's to hot out there"). I believe you meant to write "It's too hot out there." :) Louis |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Aug 08 07:14PM +0100 >>spoke", "it's to hot out there"). > I believe you meant to write "It's too hot out there." > :) Yes. I'm glad I'm following Usenet protocol when posting about spelling and/or garmmar! -- Ben. |
| woodbrian77@gmail.com: Aug 08 03:01PM -0700 On Monday, August 8, 2016 at 1:27:18 AM UTC-5, Ian Collins wrote: > > The CMW, unlike Protocol Buffers, is an on line code generator. > Which would prevent it's use on any of the projects I'm currently > working with. If I understand correctly, you mean a public cloud wouldn't be acceptable for your projects. The following quote is a summary of a private vs public cloud discussion. "So which is right for you? Ultimately, it all boils down to control. A large company may choose a private cloud, while a smaller business might choose a public cloud." https://www.expedient.com/blog/private-vs-public-cloud-whats-difference/ I agree with that much. A smaller company is more likely to decide it can't afford a private cloud. That's fine with me. In my opinion the people in smaller companies tend to be more ethical and friendlier than those working in bigger companies. I'm glad Andrei Alexandrescu left Facebook behind.... Brian Ebenezer Enterprises - So far G-d has helped us. http://webEbenezer.net Brian Ebenezer Enterprises http://webEbenezer.net |
| woodbrian77@gmail.com: Aug 08 03:23PM -0700 On Monday, August 8, 2016 at 6:53:23 AM UTC-5, Daniel wrote: > > of the storm. > This song talks about what happens to Middleware writers who don't thinks it's > necessary to follow de facto standards for serialization/deserialization. What standards are you talking about? |
| Daniel <danielaparker@gmail.com>: Aug 08 04:05PM -0700 > > This song talks about what happens to Middleware writers who don't thinks it's > > necessary to follow de facto standards for serialization/deserialization. > What standards are you talking about? Emphasis on "de facto". But seriously, for binary serialization, why would you want to use anything other than Protocol Buffers? Best regards, Daniel |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 08 06:46PM +0200 On 08.08.2016 15:54, Öö Tiib wrote: >> So that's very non-portable code. ;-) > UTF-8 is right now 83% - 87% of all web content ... so if Windows > can't even byte stream that then what is it useful for? It's not Windows, it's standard library implementations for Windows, and it's not byte streams, it's the C++ narrow streams. The proper standard-conforming portable way in C++ to produce or consume UTF-8 is to use wide streams (they're designed to convert to/from external bytes), with a properly translating buffer. To be honest I think the whole C++ i/o design sucks. More than miss Lovelace. And I'm not talking about Ada Lovelace. > Perhaps > something like "English_Australia.1252" will work there then. :-) Maybe. The only two standard locale names in C++ are "C" and "", where the former is the C and C++ default locale, and the latter denotes the user's default locale. This is part of the low pressure area effect noted above. > Perhaps 'num_put' is indeed best. I wondered how he can't find > *anything* in stream I/O and so I just pointed direction. If he > wants to use I/O utilities then he has quite lot to read there. Yes, I wish the infamous Someone™ could come up with something better… Cheers!, - Alf |
| Good Guy <hello.world@example.com>: Aug 08 06:15PM +0100 On 08/08/2016 04:36, MikeCopeland wrote: > Not quite wqhat I'm looking for: I'm not working with money data, but > large integer values. With your solution, there's no way to format > integers >999 with punctuation. Am I missing something? --- Try the method given in this video. You'll need to adapt the technique to suit your project. <https://www.youtube.com/watch?v=n9_3MbIjQbE> -- With over 350 million devices now running Windows 10, customer satisfaction is higher than any previous version of windows. |
| red floyd <no.spam@its.invalid>: Aug 08 10:43AM -0700 On 8/8/2016 10:15 AM, Good Guy wrote: > Try the method given in this video. You'll need to adapt the technique > to suit your project. > <https://www.youtube.com/watch?v=n9_3MbIjQbE> Dude, please don't post that ugly HTML here. Plain text ASCII, please. |
| Good Guy <hello.world@example.com>: Aug 08 06:53PM +0100 this one works: > cout << "double: " << AndyFormatWithCommas(aDouble) << endl; > return 0; > } *Source: <https://www.youtube.com/watch?v=9SubQGhfgJQ>* -- With over 350 million devices now running Windows 10, customer satisfaction is higher than any previous version of windows. |
| red floyd <no.spam@its.invalid>: Aug 08 01:19PM -0700 On 8/8/2016 10:53 AM, Good Guy wrote: [html redacted] WTF do you have against plain text, dude? |
| Good Guy <hello.world@example.com>: Aug 08 10:21PM +0100 Actually there is a wonderful tool called Google that has most of the answers - some good and some not so good but it requires some effort to make them work. -- If you want to filter all of my posts then please read this article: <https://support.mozilla.org/en-US/kb/organize-your-messages-using-filters> In step 7 select "Delete" With over 350 million devices now running Windows 10, customer satisfaction is higher than any previous version of windows. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 08 10:53AM +0200 On 08.08.2016 00:10, Daniel wrote: > A<std::string> a("key","value"); > A<std::string>::value_type& data = a.data(); > } The classes have the same layout and the cast just adds `const`-ness. So in practice it's technically safe. Weasel word "technically": at the design level it's unsafe. For presumably the reason why `data_` doesn't have first item `const` (which forces the cast), is that you want class `A` to be copy assignable. And then the value of the apparent `const` first item that client code has just got a reference to, can change underneath. You'd probably get some really perplexed client code that way. • • • Nothing is said about the design level, the *why*s of this code. E.g. are you returning a reference as an optimization, or in order to let client code modify the second item of the pair? How reasonable alternatives are depend on the larger view of what this is used for, I believe. • • • Anyway, remember the old adage: first make the code correct, and only then make it fast. Cheers & hth., - Alf |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 08 05:22PM +0100 On 08/08/2016 09:53, Alf P. Steinbach wrote: >> } > The classes have the same layout and the cast just adds `const`-ness. So > in practice it's technically safe. Technically undefined behaviour is unsafe. /Flibble |
| Daniel <danielaparker@gmail.com>: Aug 08 10:52AM -0700 On Monday, August 8, 2016 at 4:53:28 AM UTC-4, Alf P. Steinbach wrote: > forces the cast), is that you want class `A` to be copy assignable. And > then the value of the apparent `const` first item that client code has > just got a reference to, can change underneath. I think we can safely dismiss that concern. If you really believed that, you'd have to call the associative containers - map, multimap, etc. - unsafe, as they have std::pair<const Key,Value> value_type, and are copy assignable. In my example, 'A' could easily be made copy assignable with std::pair<const std::string, T> by the simple expedient of introducing a pointer, but that's not the concern here. > Nothing is said about the design level, the *why*s of this code. > E.g. are you returning a reference as an optimization, or in order to > let client code modify the second item of the pair? The context is associative containers where the key/value pairs are stored in sequence containers, and it is necessary to keep then sorted by the first item, and where it is necessary to have compatibility with C++ concepts for associative containers. > How reasonable alternatives are depend on the larger view of what this > is used for, I believe. After the original post, I thought about looking at the Google b-tree implementation that supports the STL associative container interface, as it has the same requirement. What Google does is define value_type and mutable_value_type typedef std::pair<const Key, data_type> value_type; typedef value_type& reference; typedef const value_type& const_reference; typedef std::pair<Key, data_type> mutable_value_type; define leaf field values as an array of mutable_value_type mutable_value_type values[kNodeValues]; and use reinterpret_cast to return as a reference or const_reference, reference value(int i) { return reinterpret_cast<reference>(fields_.values[i]); } const_reference value(int i) const { return reinterpret_cast<const_reference>(fields_.values[i]); } So I guess Google is okay with this. Daniel |
| Daniel <danielaparker@gmail.com>: Aug 08 12:27PM -0700 On Monday, August 8, 2016 at 4:53:28 AM UTC-4, Alf P. Steinbach wrote: > > std::pair<const std::string, T>; > > std::pair<std::string, T> > The classes have the same layout and the cast just adds `const`-ness. Are we sure they have the same layout, though? I found a discussion about that here. http://stackoverflow.com/questions/14272141/is-casting-stdpairt1-t2-const-to-stdpairt1-const-t2-const-safe Daniel |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 08 08:38PM +0100 On 08/08/2016 20:27, Daniel wrote: > Are we sure they have the same layout, though? I found a discussion about that > here. > http://stackoverflow.com/questions/14272141/is-casting-stdpairt1-t2-const-to-stdpairt1-const-t2-const-safe Who cares? Formally it is undefined behaviour so you shouldn't do it all. /Flibble |
| Daniel <danielaparker@gmail.com>: Aug 08 01:33PM -0700 On Monday, August 8, 2016 at 3:38:55 PM UTC-4, Mr Flibble wrote: > Formally it is undefined behaviour so you shouldn't do it all. Sausages also have undefined behaviour. Daniel |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 08 09:48PM +0100 On 08/08/2016 21:33, Daniel wrote: > On Monday, August 8, 2016 at 3:38:55 PM UTC-4, Mr Flibble wrote: >> Formally it is undefined behaviour so you shouldn't do it all. > Sausages also have undefined behaviour. Well that was certainly a fucking bizarre thing to say. /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