153 reputation
28
bio website alfps.wordpress.com
location Norway
age 52
visits member for 2 years, 11 months
seen Aug 15 at 15:36

I have a pretty good sense of quality.

I'm one of the moderators of the comp.lang.c++.moderated Usenet group.

I'm about the 75th recipient of the C++ gold badge here on Stack Overflow.

My contributions to the C++ FAQ are numerous, but I think my main contribution is the FAQ item about dynamic binding during initialization, DBDI, "Okay, but is there a way to simulate that behavior as if dynamic binding worked on the this object within my base class's constructor?". The text is Marshall Cline’s, not my original proposal. But I convinced him, through a lengthy e-mail discussion, to include that item, so I think of it as “my” FAQ item…

I’m sometimes present in the C++ lounge chat room here on Stack Overflow.


Nov
14
comment Most common encoding for strings in C++ in Linux (and Unix?)
Version 2 of boost.filesystem supported Unicode filenames also for opening C++ level ifstreams. Version 3 currently supports this only for Microsoft's Visual C++ compiler, which provides extra wide character based constructors and open functions. The version 2 workaround for g++, using Windows short names, was not brought over to version 3. However, there is a ticket opened by me on that, and Beman promised to fix it sooner or later, perhaps later though. Until then one fix is to implement the g++ workaround oneself, and another is to use the old version 2 of boost.filesystem.
Nov
13
comment Most common encoding for strings in C++ in Linux (and Unix?)
i'll kill that cat... :-)
Nov
13
comment Most common encoding for strings in C++ in Linux (and Unix?)
thanks, it is about as I expected. I hadn't thought about the nullbyte/terminator issue before, interesting! In the other direction, one of the "a few Microsoft applications" is the Visual C++ compiler, which still as of version 10.0 uses the BOM to identify UTF-8 as such, and now that g++ no longer chokes on BOM it is possible to encode a source file that includes non-ASCII characters, such that both compilers can digest it (namely, UTF-8 with BOM). I agree that "BOM" is an unfortunate term since it only associates to part of the function, but then, Unicode and terminology... ;-)
Nov
13
comment Most common encoding for strings in C++ in Linux (and Unix?)
Ah, thanks, that works both in Ubuntu and Windows. It failed to report that it did not recognize the option (a lesser bug). I just tried various syntaxes till it seemingly accepted it.
Nov
13
comment Most common encoding for strings in C++ in Linux (and Unix?)
the source file is encoded as UTF-8 with BOM. It should not matter as long as the compiler identifies it correctly. The resulting string, with execution character set Latin-1, should be just 1 character, and is just 1 character with Visual C++. I pasted the Ubuntu test here: pastebin.com/nJQJDCWV
Nov
13
comment Most common encoding for strings in C++ in Linux (and Unix?)
Again, thanks for this information. However, with both MinGW g++ 4.4.1 in Windows, and Ubuntu g++ 4.6.1 in Ubuntu, the static assertion in the code in the question, fires even when the execution character set is set to Latin-1 (option -exec-charset:"ISO−8859−1"". This is a bug in the g++ compiler version 4.6 and earlier (I don't know about 4.7). In short, it's unreliable. But I'm pleased to learn that these options now are accepted and work, I didn't know that. So, thanks.
Nov
13
comment Most common encoding for strings in C++ in Linux (and Unix?)
@KerrekSB: thanks for the info.
Nov
13
comment Most common encoding for strings in C++ in Linux (and Unix?)
@KerrekSB: they didn't work with MinGW g++ last time I checked. but that was a couple of years ago. maybe it's been fixed in the meantime (along with no-choke-on-BOM support and wide stream support)?
Nov
13
comment Most common encoding for strings in C++ in Linux (and Unix?)
@Mat: thanks. if you put that as an answer, and there is no clear disagreement, i will likely select it as "solution". even though it means that my assumption about this was wrong... :-(
Nov
13
comment Most common encoding for strings in C++ in Linux (and Unix?)
@KerrekSB: re the possibility of compiler options (which you added while I responded to the first 2 sentences): in Windows one does usually not build the compiler. Visual C++ infers the encoding from the file contents, with Windows ANSI as default, and MinGW g++ blindly assumes UTF-8, but, happily for novices who serve it Windows ANSI source code, it doesn't validate narrow literals... ;-)
Nov
13
comment Most common encoding for strings in C++ in Linux (and Unix?)
@KerrekSB: yes, that's what the question is about.
Nov
12
comment AltGr keys don't work with Ubuntu in VirtualBox
Well, it still works after renaming that file and rebooting. And the terminal still remembers old command history after reboot. With silly persistent dynamic states like that, I think it must be rather difficult to hunt down bugs: they can't be reliably reproduced in such an interfering environment. I think further evidence of that is how the bug about AltGr has gone yoyo: closed as resolved, re-opened, closed as resolved, re-opened, so on and on. So I think it would be a Good Idea(TM) to severely punish the person who introduced that persistence of settings & state. :-)
Nov
12
comment AltGr keys don't work with Ubuntu in VirtualBox
It is an interesting answer, using keycode 66. In my comment before you posted this answer, I noted that keycode 113, which I just copied and pasted from the net, works for that line. Now when I run xevas you suggest, it reports keycode 108. Yet the line I copied from the net works. So it apparently has nothing to do with the keycode. I changed it to 66, just for fun, and rebooted: it still works. So I conclude it's not something technically accurate at all, but evidently a Heisenbug in Ubuntu.
Nov
12
comment AltGr keys don't work with Ubuntu in VirtualBox
I got the AltGr key working in Ubuntu. I just had to know that I should create a file called ".Xmodmap" and add this line: "keycode 113 = Mode_switch Multi_key". Which I found in a bug report about a similar issue, at bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/349487/…