- alignment and endian issues - 2 Updates
- "The C++ committee has taken off its ball and chain" - 2 Updates
- Can one initialise std::string with pre-allocated memory? - 1 Update
| jameskuyper@verizon.net: Apr 19 11:03AM -0700 On Wednesday, April 18, 2018 at 4:14:02 PM UTC-4, Rick C. Hodgin wrote: > On 4/18/2018 3:59 PM, jameskuyper@verizon.net wrote: > > On Wednesday, April 18, 2018 at 3:45:07 PM UTC-4, Rick C. Hodgin wrote: ... > It's not that I review the generated code, it's more when I encounter > something and I'm not sure how it will work in the compiler, I test it. > I typically will test things in MSVC++ and GCC (MinGW). That's the key difference. As long as I know how it will work in the C code, I couldn't care less how it works in the generated code, so long as it produces the result that the C code is supposed to produce. If I don't know how it will work in the C code, that's a very bad sign, because the only relevant things I don't know about all involve behavior that is, at best, implementation-defined (and our contract with our client prohibits me from delivering code with observable implementation- defined behavior). At worst, it may involve undefined behavior. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 19 02:18PM -0400 > that is, at best, implementation-defined (and our contract with our > client prohibits me from delivering code with observable implementation- > defined behavior). At worst, it may involve undefined behavior. There are very few things I don't understand regarding how they will work in C (and more so in C++ because I never have learned C++ but only seen code samples and it made sense to me), but that wasn't always the case. I came from an assembly background to C, and I've made lots of assumptions that were valid in asm, and completely invalid in C/C++. It's actually completely tailored my whole view of data toward the compiler, hence CAlive removing limitations on type punning in every form. Whatever lens you point at data in CAlive, that's how it will be viewed no matter what was there before. You use the right tool for the right job, and you (the developer) are able to keep track of things the compiler could never know. -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 19 12:25PM -0400 On 4/18/2018 8:58 PM, Lynn McGuire wrote: > proposals even if they may cause a change in behavior or failure to > compile for existing code." > Interesting only if C++ can generate faster code. A very interesting development. -- Rick C. Hodgin |
| Manfred <noname@invalid.add>: Apr 19 07:06PM +0200 On 4/19/2018 11:03 AM, Jorgen Grahn wrote: >> "The Committee should be willing to consider the design / quality of >> proposals even if they may cause a change in behavior or failure to >> compile for existing code." <snip> > Personally I like conservative languages, like C++. "Exciting new > features" don't excite me -- or I'd be cargo-culting the > JVM-language-of-the-week instead. I believe the same, and not only as personal preference. Backwards compatibility is a very valuable property. This is obvious from the perspective of software producers, expecially the ones that are involved in long-living projects. But it is also valuable for the language itself: it keeps it usable by high-end projects, which usually have a long life, so that it motivates highly skilled subjects (people and organizations) to put effort in maintaining and improving the language. From this perspective, conservativeness is valuable for compiler writers too: high quality of the language is in the end what motivates the choice for quality projects, and what in turn motivates the fees for quality compilers as well. I don't think that Intel could charge as much as they do, it their compilers were used for short-lived projects. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 19 02:53AM +0200 > copy? There answer seems to be no as I can't find anything about it on > stackoverflow or general googling but I wondered if anyone here knows any > better? No, but you can store it in a `std::unique_ptr` or `std::shared_ptr` with custom deleter. Maybe write a little wrapper class for that. Performance note 1: `shared_ptr` adds a dynamic allocation for the control block. Performance note 2: **measure** before you dismiss `std::string`. Cheers & hth., - Alf |
| 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