| comp.lang.c++@googlegroups.com | Google Groups |  |
| Unsure why you received this message? You previously subscribed to digests from this group, but we haven't been sending them for a while. We fixed that, but if you don't want to get these messages, send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
- Are there any certifications for C++ - 5 Updates
- Deleting std::vector Item(s) - 2 Updates
- "JetBrains CLion C++ IDE First Impressions" - 3 Updates
- How to print/format error messages in C++? - 1 Update
- wchar_t aliasing - 3 Updates
| Robert Hutchings <rm.hutchings@gmail.com>: Sep 24 09:41AM -0500 Hi all, SOME employers like "certs"...are there any for C++? What is the best? Regards, Rob Hutchings |
| Robert Hutchings <rm.hutchings@gmail.com>: Sep 24 10:49AM -0500 On 9/24/2014 9:41 AM, Robert Hutchings wrote: > SOME employers like "certs"...are there any for C++? What is the best? > Regards, > Rob Hutchings I found this link: http://www.cppinstitute.org/?p=5 Have you ever heard of this? |
| Christopher Pisz <nospam@notanaddress.com>: Sep 24 02:32PM -0500 On 9/24/2014 10:49 AM, Robert Hutchings wrote: > I found this link: > http://www.cppinstitute.org/?p=5 > Have you ever heard of this? I'd give negative points to anyone that had a "certification" in any programming language on their resume. It's not the type of thing you get tested for once and are forever deemed worthy. It's something you have to do every day, have a passion for, and an intuition for. Reciting the rules of the language is a small percentage of what is required to be a good programmer. Certifications are for those guys that sit in the closet with their copy of Windows Server and push Windows Updates through the network, while feeling like they are super smart, IMO. |
| Robert Hutchings <rm.hutchings@gmail.com>: Sep 24 02:47PM -0500 On 9/24/2014 2:32 PM, Christopher Pisz wrote: > Certifications are for those guys that sit in the closet with their copy > of Windows Server and push Windows Updates through the network, while > feeling like they are super smart, IMO. Well, I tend to agree. In the past, some prospective employers used Brainbench to test applicants knowledge. I think "certs" have always been overrated... |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 24 07:59PM On Wed, 2014-09-24, Robert Hutchings wrote: > Hi all, > SOME employers like "certs"...are there any for C++? If there is one, I've never heard about it, or met anyone who admitted to being certified. Back in the 1990s certification for Java and MS stuff seemed popular; perhaps it still is but, I'm not even sure about that. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Ike Naar <ike@iceland.freeshell.org>: Sep 24 04:29AM > if(defWork.recVal >= uuu) > defVect.erase(vIter+iii); > } Have you already looked at remove_if() from <algorithm> ? |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 24 04:42PM On Tue, 2014-09-23, Andreas Dehmel wrote: > } > } > defVect.erase(vDest, defVect.end()); Isn't that just a complicated way to write this? auto end = std::remove_if(defVect.begin(), defVect.end(), deletePredicate); defVect.erase(end, defVect.end()); In either case, I too warmly recommend the "move, then erase" approach. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Ian Collins <ian-news@hotmail.com>: Sep 24 01:44PM +1200 Rick C. Hodgin wrote: > On Tuesday, September 23, 2014 4:23:46 PM UTC-4, Ian Collins wrote: >> Stick to C++ here, preach elsewhere. <more OT nonsense> Welcome to my kill file. -- Ian Collins |
| drew@furrfu.invalid (Drew Lawson): Sep 24 02:13PM In article <220ff353-0f27-44de-ad4d-32281ee42b2c@googlegroups.com> >led people out of sin and sinful behaviors. He showed people God >manifest in the flesh. He healed their sicknesses. Raised the dead. >Cleansed them of sin. And told them to abandon their family responsibilities. ("Let the dead bury the dead.) Also denounced peace. ("Think not that I am come to send peace on earth: I came not to send peace, but a sword.") >Why do people hate that? Why do people hate Jesus? Why do they hate Why do you hate Jesus? Why do you feel the need to lie (by omission and editing sophistry) about his life and full message? You seem to love 10-20% of Jesus. -- |Drew Lawson | If you're not part of the solution | | | you're part of the precipitate. | |
| drew@furrfu.invalid (Drew Lawson): Sep 24 02:15PM In article <716cb2ba-71c2-41d3-9638-c0fae69b6db3@googlegroups.com> >On Tuesday, September 23, 2014 4:23:46 PM UTC-4, Ian Collins wrote: >> Stick to C++ here, preach elsewhere. >There's something afoot. Try an anti-fungal. -- Drew Lawson | "But the senator, while insisting he was not | intoxicated, could not explain his nudity." |
| scott@slp53.sl.home (Scott Lurndal): Sep 24 01:24PM >> couldn't be opened), log the message and terminate gracefully. >I have once had to deal with library that did that, and that basically >disqualified that library for use in our application because terminating Libraries are different. And when I said terminate, that doesn't mean calling exit, it must means terminating the function that detected the error. That can be by returning an error code, or by signaling an exception. I prefer libraries that return an error code rather than raising an exception because the library can be used in more contexts (I've rejected libraries that signalled via exceptions because the code they were being used with didn't support exceptions at runtime). |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 24 01:47AM +0100 On Tue, 23 Sep 2014 09:22:50 +0200 > From what I can tell, this does violate the aliasing rules. Am I > missing something? Do GCC/Visual C++ make some special guarantees > that this will work? Not as far as I am aware, but the mere act of casting in that way does not of itself breach the strict aliasing rule in §3.10/10 of the standard. It depends on what the code does with the cast value. You can cast between a particular wchar_t value and its underlying integer type without breaching the strict aliasing rule, and do whatever you want with the cast value, since no aliasing takes place: you end up with two independent values. Where you have arrays/strings of wchar_t, you can again cast the decayed array of wchar_t to a pointer to the underlying integer type and copy that pointer around without breaking the strict aliaising rule. What you cannot do in the last case is to dereference that pointer. I have rarely seen code which does that. For example, on systems with 32 bit wchar_t, I have commonly used code which reinterpret_casts std::wstring::c_str() to uint32_t* in order to call a library codeset conversion function which takes a uint32_t* argument. Of itself that is OK. Technically speaking there may be breach of the strict aliasing rule when the library function dereferences the pointer, but since this is done in a different compilation unit the compiler knows nothing about it and has to take it on trust, so everything works. In this kind of case you can "cheat" strict aliasing just by arranging your translation units appropriately and use compatible types with the same size, signedness and alignment. Possibly that is what the code you have seen does. Chris |
| markus <markus@addr.is.invalid>: Sep 24 04:00AM +0200 On 2014-09-23 21:18, Öö Tiib wrote:> On Tuesday, 23 September 2014 10:23:11 UTC+3, markus wrote: >> they are all distinct types. > "Windows" is series of operating systems. It does not deal with C++ > fundamental types and typedefs. The Win32/64 API defines wchar_t as UTF-16 and unsigned short as 16-bit int. > Did you mean some particular version of some particular C++ compiler > targeting some particular version of Windows? All of them on Win32/64. AFAIK, everything tries to be compatible to either Visual C++ or GCC/Mingw and they do what I mentioned. > things that is quite fully well defined in C++ standard. Did you mean > that non-'char' pointers are somewhere taken and type-punned and then > used in mix in Qt and Firefox source code? Yes, I'm taking about pointers. E.g. Firefox has a helper for automagic casting (Char16.h): class char16ptr_t { private: const char16_t* mPtr; public: char16ptr_t(const char16_t* aPtr) : mPtr(aPtr) {} char16ptr_t(const wchar_t* aPtr) : mPtr(reinterpret_cast<const char16_t*>(aPtr)) {} operator const char16_t*() const { return mPtr; } operator const wchar_t*() const { return reinterpret_cast<const wchar_t*>(mPtr); } operator std::wstring() const { return std::wstring(static_cast<const wchar_t*>(*this)); } /* Explicit cast operators to allow things like (char16_t*)str. */ explicit operator char16_t*() const { return const_cast<char16_t*>(mPtr); } explicit operator wchar_t*() const { return const_cast<wchar_t*>(static_cast<const wchar_t*>(*this)); } explicit operator const char*() const { return reinterpret_cast<const char*>(mPtr); } explicit operator const unsigned char*() const { return reinterpret_cast<const unsigned char*>(mPtr); } explicit operator unsigned char*() const { return const_cast<unsigned char*>(reinterpret_cast<const unsigned char*>(mPtr)); } |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 24 10:45AM +0100 On Wed, 24 Sep 2014 04:00:49 +0200 > return const_cast<unsigned char*>(reinterpret_cast<const unsigned > char*>(mPtr)); > } The conversion operators to char*/unsigned char*/const char* do not break the strict aliasing rule by definition. Apart from the operator std::wstring method, the others might break strict aliasing, depending on the circumstances in which the returned pointer is dereferenced. The conversion operator to std::wstring does appear to break strict aliasing unless when used the source of the char16ptr_t argument was originally a wchar_t string which had been cast to char16ptr_t. (You can cast from pointer to one type to a pointer to another type, then cast back to pointer to the original type and then dereference that.) Encouraging casting like this seems somewhat undesirable (a programmer should I think be forced to think about what she is doing with respect to aliasing when type punning). However, even though the standard states that wchar_t, char16_t and char32_t are distinct types, it would not surprise me if compilers in fact permit type punning between char16_t* and wchar_t* (for 16 bit wchar_t) or char32_t* and wchar_t* (for 32 bit wchar_t), as well as between them and their underlying integral types. In practice you will also get away with it if the pointer casts are to arguments of functions in different compilation units. Chris |
| 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