- std::wstring considered useless - 3 Updates
- "Almost Always Auto" - 2 Updates
- "Almost Always Auto" - 2 Updates
- The "STL" - 1 Update
- Announce: standard stream output support in cppx lib at GitHub - 1 Update
| Christopher Pisz <nospam@notanaddress.com>: Jan 13 05:02PM -0600 On 1/13/2016 1:18 PM, Paavo Helde wrote: > to use std::wstring either, CString would probably be fine for them. > Cheers > Paavo So, then we can translate from CString used internally to std::strings used by every thrid party library? and be forced to include MFC in every project to have the craptastic CString in the first place? Then we can convert to BSTR for COM too while we're at it and back again, and leak memory everywhere. I use std::wstring for unicode and std::string for multibyte, because it works with every single third part libray in itself or through a call to c_str(). BSTR in COM is converted automitaclly for me from wachar_t *, and I the only conversion I ever have to worry about is wide to multibyte or the other way around. I've worked on enough windows services that spent 95% of thier processing converting strings to every silly type under the rainbow in Windows. Windows is going to convert everything to wide for you anyway on any API call, so just pass it wchar_t * obtained from std::wstring in most cases. |
| Paavo Helde <myfirstname@osa.pri.ee>: Jan 14 01:09AM +0200 On 13.01.2016 22:47, Richard wrote: >> programmers to use UTF-8 in their programs. Of course, they don't need >> to use std::wstring either, CString would probably be fine for them. > Nit: don't confuse "Windows-only programmers" with "MFC Programmers". I think there is some variant of CString (ATL CString?) which can be used in Windows C++ programs even without MFC. Not that I would advocate that. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 13 11:25PM On Wed, 2016-01-13, JiiPee wrote: >> Nit: don't confuse "Windows-only programmers" with "MFC Programmers". > why would somebody do windows only programming :)?? going back to C > language?? To be able to use the APIs and features which are unique to Windows, or which work differently on Windows -- because you want your programs to run there, and you want them to run well. Almost all my programming is Unix-specific for the same reason. But a lot of people have wasted a lot of time and money over the years, trying to get portability to platforms which they never used. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Ian Collins <ian-news@hotmail.com>: Jan 14 10:18AM +1300 Stefan Ram wrote: > and immediately got (for the line »{ auto s = scanner {};«): > internal compiler error: in gimplify_expr, at gimplify.c:8629 > from GCC 5.1.1. That's not fair! Fixed in more recent versions. -- Ian Collins |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 13 10:56PM On Wed, 2016-01-13, Stefan Ram wrote: > I just read a web page »Almost Always Auto« and wanted > to give it a try. http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/ Watched a video of him speak about it today, and it occured to me that if we go that way we'll regret it in a few years. The lack of explicit typing was one main reason I abandoned Python -- the code became too hard to read. I /do/ use auto a lot, I'm grateful for it, and I may use it more in the future (I only started writing C++11 code from scratch a month ago) but I don't think I'll ever try to use it in the extreme. And no, I won't switch to an IDE which tells me the types in my code, nor will I ask my potential readers switch to one. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| ram@zedat.fu-berlin.de (Stefan Ram): Jan 13 09:09PM >internal compiler error: in gimplify_expr, at gimplify.c:8629 However, rewriting the line with the »auto« to scanner s{}; still gives this compiler error, so it has nothing to do with »auto«. |
| ram@zedat.fu-berlin.de (Stefan Ram): Jan 13 09:11PM >scanner s{}; >still gives this compiler error, so it has nothing >to do with »auto«. If you're curios, I defeated the compiler error by scanner s; . |
| Gareth Owen <gwowen@gmail.com>: Jan 13 07:41PM > On Tuesday, January 12, 2016 at 1:42:47 PM UTC-6, gwowen wrote: > Please don't swear here. Hell, no. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 13 04:14PM +0100 On 1/4/2016 12:39 AM, Alf P. Steinbach wrote: > ... It's been several days (half a week? more?) since I did anything with the cppx code, but now I sat down and fixed two COMPILER-SPECIFIC issues: https://github.com/alf-p-steinbach/cppx/commit/40c9fb367a0c00479cdd374b0c7bba01fc5caef2 • g++, at least as of 4.8.2, has a compiler bug where it requires a template value parameter to be type size_t, no other type will do. • MSVC, at least as of 2015 update 1, has a library bug where after narrow string output to a wide stream, it fails to flush that output (e.g. when using std::flush or when input is performed). An additional issue with MSVC, that I've not yet coded up a fix for, concerns the translation of narrow characters to wide characters in wide stream output. g++, with the standard library implementation used for MinGW, gets this right, but MSVC acts as if directly copying the character code should work, and it doesn't. Well, later. I think that as of 2015 one really should not have to deal with such compiler-specific issues, /non-conformance in the basics/. Cheers, - 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