Friday, January 22, 2016

Digest for comp.lang.c++@googlegroups.com - 12 updates in 4 topics

bleachbot <bleachbot@httrack.com>: Jan 22 08:02PM +0100

Ramine <ramine@1.1>: Jan 22 02:04PM -0800

Hello...............
 
 
Quantum computing will change lives, society and the economy and a
working system is expected to be developed by 2020 according to a
leading figure in the world of quantum computing, who will talk tomorrow
Jan. 21, 2016 at the World Economic Forum (WEF) in Davos, Switzerland.
 
Professor O'Brien said: "In less than ten years quantum computers will
begin to outperform everyday computers, leading to breakthroughs in
artificial intelligence, the discovery of new pharmaceuticals and beyond."
 
 
Read more here:
 
http://www.sciencedaily.com/releases/2016/01/160120120127.htm
 
 
 
Merci,
Amine Moulay Ramdane.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 22 12:45AM +0100

On 1/22/2016 12:23 AM, Dmitry Chichkov wrote:
 
> Yes, it is still necessary to select the correct platform-specific
> headers. And the tool like cmake, omake, etc would be the standard
> way of doing it. The problem is, after you've included a
 
Please don't top
 
> platform-specific definition - for example arm/math.h, you have
> duplicate function/type/template definitions in the common code (for
 
post.
 
> function in every platform-specific file, redirecting every
> unimplemented call to common routine. But if the number of supported
> platforms is large, this adds a lot of code/maintenance. There are
 
It's not how things are
 
> ways to address that with preprocessor or templates, but it either
> forces one to mangle function names or it supports C++ only and
> requires to template every function/type, etc. It seems like this
 
done on Use
 
> inline namespace trick gives cleaner alternative, but I haven't seen
> it in practice, and I'm not sure what are the potential pitfalls...
 
> Cheers, Dmitry
 
net.
 
See e.g. <url:
http://www.csse.monash.edu.au/courseware/cse3400/2006/c++-faq/how-to-post.html#faq-5.4>
for more info about how to post. In particular check out the 4th bullet
point.
 
That said, I have never had a problem with platform-specific headers
colliding with headers used by general code. There have been problems
like ungood macros and such, handled by the usual compiler firewall
technique. But nothing like a platform specific <math.h> colliding with
the standard <math.h>.
 
Cheers & hth.,
 
- Alf
Dmitry Chichkov <dchichkov@gmail.com>: Jan 21 05:48PM -0800

On Thursday, January 21, 2016 at 3:46:14 PM UTC-8, Alf P. Steinbach wrote:
> the standard <math.h>.
 
> Cheers & hth.,
 
> - Alf
 
I'm sorry if the answer to that is obvious, but what usual compiler firewall technique do you have in mind? Would it support inlining?
 
Dmitry
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 22 03:07AM +0100

On 1/22/2016 2:48 AM, Dmitry Chichkov wrote:
> wrote:
>> See e.g. <url:
>> http://www.csse.monash.edu.au/courseware/cse3400/2006/c++-faq/how-to-post.html#faq-5.4>
 
for more info about how to post. In particular check out the 4th bullet
 
>> - Alf
 
> I'm sorry if the answer to that is obvious, but what usual compiler
> firewall technique do you have in mind?
 
Just separate compilation, including the troublesome headers in
separately compiled sources.
 
The pimpl idiom (see <url: http://www.gotw.ca/publications/mill05.htm>)
is in support of a special case of that.
 
One doesn't need to use pimpl, however, to have a compilation firewall.
 
The main thing is that all those implementation details are isolated,
not visible to the rest of the system.
 
For example, one may express a template in terms of a non-template
implementation. Client code then uses the type safe template code
provided by a clean header. The not so type safe implementation, that
instead relies on conventions etc., is separately compiled.
 
 
 
> Would it support inlining?
 
Nope, not all the way. :(
 
It's possible that whole program optimization, a.k.a. link time
optimization, now supported by at least g++ and MSVC, can help further
with the optimization.
 
But as with any optimization issue, it can be a good idea to MEASURE
first, and only if that says it's necessary, expend a lot of work on the
optimization.
 
 
Cheers & hth.,
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: Jan 21 11:41PM -0800

On Friday, 22 January 2016 04:08:04 UTC+2, Alf P. Steinbach wrote:
 
> One doesn't need to use pimpl, however, to have a compilation firewall.
 
Yes, the opaque types are also used in C.
 
In C++ we can use opaque inner or friend class to remove the declarations
of private member functions from header file. It is useful when
additional indirection from pimpl is unneeded and we do not care
of fire-walling declarations of data members.
 
Inlining depends if linker does it or does not so it is quality of
implementation issue. The keyword 'inline' is unfortunately misleading.
dmitry.chichkov@daqri.com: Jan 22 10:39AM -0800

On Thursday, January 21, 2016 at 6:08:04 PM UTC-8, Alf P. Steinbach wrote:
> optimization.
 
> Cheers & hth.,
 
> - Alf
 
Let's narrow it down to the case then the *design spec* *requires* static linking / reasonably efficient inlining of platform-specific code. And specifically *excludes* solutions that expect the compiler to use optimization hacks to statically resolve virtual/pimpl calls at a compile time.
 
There are 'CRTP' and 'traits' patterns that allow one to do it in C++. And preprocessor hacks. It looks like this inline namespace trick described here could be an alternative to these approaches. Question - does anyone see any potential pitfalls with this technique?
"Öö Tiib" <ootiib@hot.ee>: Jan 21 11:21PM -0800

> for file name extensions, but three radix-50 characters don't fit in
> 16 bits. The limit would be three radix-40 characters, or a mixed
> representation that had restrictions on character combinations.
 
There are AFAIK no such thing as "Radix-40". The term "Radix-50" means
that there are 40 characters. The "50" in its name is octal number.
Blame who named it, wasn't me. Terms mean what those mean, (not what
you think those mean) and so 3 Radix-50 characters fit into 16 bits.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 22 11:27AM +0100

On 1/22/2016 8:21 AM, Öö Tiib wrote:
> that there are 40 characters. The "50" in its name is octal number.
> Blame who named it, wasn't me. Terms mean what those mean, (not what
> you think those mean) and so 3 Radix-50 characters fit into 16 bits.
 
https://en.wikipedia.org/wiki/DEC_Radix-50
 
"The actual encoding differed between the 36-bit and 16-bit systems"
 
Hah, good joke. :)
 
A modern variant is Windows' [1] GetProcAddress API function, whose
argument, if it is a text string, is encoded as Windows ANSI, which at
least for other functions depends on the configuration of the system the
program runs on. And if so (the details are now undocumented stuff),
then for the general case hardcoded literals won't work. It's all the
more baffling as the data structures it accesses use UTF-8...
 
 
Cheers,
 
- Alf
 
Notes:
[1] <url:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683212%28v=vs.85%29.aspx>
Paavo Helde <myfirstname@osa.pri.ee>: Jan 22 01:24PM +0200

On 22.01.2016 12:27, Alf P. Steinbach wrote:
> program runs on. And if so (the details are now undocumented stuff),
> then for the general case hardcoded literals won't work. It's all the
> more baffling as the data structures it accesses use UTF-8...
 
This is most interesting, care to provide some links (about the UTF-8
connotations)? I had an impression GetProcAddress deals with mangled
linker symbols which I assumed are normalized to ASCII anyway, aren't they?
 
Cheers
Paavo
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 22 01:21PM +0100

On 1/22/2016 12:24 PM, Paavo Helde wrote:
 
> This is most interesting, care to provide some links (about the UTF-8
> connotations)? I had an impression GetProcAddress deals with mangled
> linker symbols which I assumed are normalized to ASCII anyway, aren't they?
 
The data structures are well documented, but AFAIK the encodings are
not. Mangling and using ASCII could have worked, with some special
mangle convention for non-ASCII characters. But it's just UTF-8 for the
characters, plus by default mangling to encode the signature etc..
 
I found out about the UTF-8 encoding once when I coded up some traversal
of the structures for an SO answer, but my google-foo now fails me: I
can't find it again.
 
But here's a simple example, using Microsoft's toolchain. Here `chcp` is
a command to change the console window's active codepage, cl is the
Visual C++ compiler, probably named for its ancestor Lattice C, and
dumpbin is Microsofts binary dump utility, corresponding to gcc's
objdump. And as you can see, under the assumption that dumbin dumps the
raw bytes of the name (and yes it does), the name is UTF-8 encoded:
 
 
<example>
C:\my\forums\clc++\018> chcp 1252
Active code page: 1252
 
C:\my\forums\clc++\018> type dll.cpp
#include <windows.h>
 
__declspec( dllexport )
void bare_blåbærtøys()
{ MessageBoxW( 0, L"Oi", L"Message:", MB_SETFOREGROUND ); }
 
C:\my\forums\clc++\018> type name_in_utf8.txt
bare_blåbærtøys
 
C:\my\forums\clc++\018> cl dll.cpp user32.lib /LD
dll.cpp
Creating library dll.lib and object dll.exp
 
C:\my\forums\clc++\018> dumpbin /exports dll.dll | find "bare"
1 0 00001260 ?bare_blåbærtøys@@YAXXZ
 
C:\my\forums\clc++\018> _
</example>
 
 
• • •
 
Standard C++ allows the Norwegian Æ, Ø and Å (lowercase æ, ø, and å) in
identifiers, as used above, but g++ doesn't accept them, at least not by
default :( :
 
 
<example>
C:\my\forums\clc++\018> g++ -c dll.cpp -finput-charset=cp1252
dll.cpp:4:1: error: stray '\303' in program
void bare_blåbærtøys()
^
dll.cpp:4:1: error: stray '\245' in program
dll.cpp:4:1: error: stray '\303' in program
dll.cpp:4:1: error: stray '\246' in program
dll.cpp:4:1: error: stray '\303' in program
dll.cpp:4:1: error: stray '\270' in program
dll.cpp:4:15: error: expected initializer before 'b'
void bare_blåbærtøys()
^
 
C:\my\forums\clc++\018> g++ --version | find "++"
g++ (tdm64-1) 5.1.0
 
C:\my\forums\clc++\018> _
</example>
 
 
There are no errors (i.e. MinGW g++ understands the Microsoft `declspec`
directive) when the file only contains ASCII characters. I'm at a loss
at how the compiler ends up with the specific values in the error
messages. They are not the raw encoding values, but there are only three
distinct values, presumably corresponding to æ, ø and å, and they look
as if they're scooped from a translation to UTF-8.
 
Anyway, due to g++'s lack of support for non-ASCII function names, I
can't show the DLL example with the GNU toolchain, sorry.
 
Cheers & hth.,
 
Alf
Paavo Helde <myfirstname@osa.pri.ee>: Jan 22 03:19PM +0200

On 22.01.2016 14:21, Alf P. Steinbach wrote:
 
> Creating library dll.lib and object dll.exp
 
> C:\my\forums\clc++\018> dumpbin /exports dll.dll | find "bare"
> 1 0 00001260 ?bare_blåbærtøys@@YAXXZ
 
Wow, it seems for once Microsoft has made a sane decision about software
design! Of course this does not align well with their corporate image,
so they have left it hidden and undocumented ;-)
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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)