Thursday, July 30, 2020

Digest for comp.lang.c++@googlegroups.com - 10 updates in 2 topics

Melzzzzz <Melzzzzz@zzzzz.com>: Jul 30 04:11AM

> * pipes
> * named pipes
> * even signals...
memory mapped files...
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jul 30 07:33AM

On Wed, 2020-07-29, Jorgen Grahn wrote:
> thread listed many different technologies, but the thing about these
> is they are applicable in different situations, for different
> problems.
 
And reading closer, Felix Palmen pointed that out already:
 
> What's the "right way" to do it depends on the scenario [...]
> and of course, the actual design and purpose of your programs).
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
IOP <iop@und.com>: Jul 30 05:33PM


> What's the "right way" to do it depends on the scenario (target
> operating systems, languages involved, and of course, the actual design
> and purpose of your programs).
 
Thank you. This thread has been very informative. Other posters have
referenced the book UNIX Network Programming by Stevens, and it seems
like this might also give me an idea of a lot of the content that you
mention here. I intend to read that book (so far, I've only read the
TOC). But if you had any other suggestions that you thought I should
look at, I'd be interested.
 
Thanks - IOP
IOP <iop@und.com>: Jul 30 05:37PM

> Python interpreter in a C++ program, and vice versa, you can implement
> new Python modules in C++. This would not be trivial though, and might
> mean too tight encapsulation.
 
I've heard this before, but I suppose I don't really understand what
means (or how to go about) embedding a python interpreter in C++. In the
past I have written some python modules in C++ and C, but that's the
only sort of thing I've done in that direction.
 
> Boost.ASIO library (https://en.wikipedia.org/wiki/Asio_C%2B%2B_library).
> There is some chance it will be included into the C++ standard at some
> point in the future.
 
Thank you! I'll examine Boos.ASIO too.
 
- IOP
IOP <iop@und.com>: Jul 30 05:40PM

> engine and, indeed, you can usually freely add new engines to it, and they
> will work with it. You can even write your own UCI chess engine and use it
> with that GUI if you want. No need for plugins or dlls or whatever.
 
This sounds like a very interesting example. I looked into the UCI spec
a bit and it seems like a lot is passed around using plaintext directly
through stdin and stdout. This sounds very interesting, and this is
definitely something that I would like to better understand.
Fortunately, google shows a wealth of resources concerning UCI and these
engines, so perhaps I'll find something that makes sense to me.
 
Thank you - IOP
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jul 30 07:45PM

On Thu, 2020-07-30, IOP wrote:
> mention here. I intend to read that book (so far, I've only read the
> TOC). But if you had any other suggestions that you thought I should
> look at, I'd be interested.
 
Eric S. Raymond
The Art of Unix Programming
chapter 7: Multiprograming
 
http://www.catb.org/esr/writings/taoup/html/multiprogramchapter.html
 
Note that he's defending what he thinks are classic Unix paradigms,
so a lot of people probably disagree with him.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Frederick Gotham <cauldwell.thomas@gmail.com>: Jul 30 02:09AM -0700

This week I'm working on two different products that link with the same library, however one product links with a newer version of the library. The older library has a struct like this:
 
typedef struct {
u16 scale;
u8 window;
u8 a;
u8 b;
u8 c;
float x;
float y;
float z;
u32 reserved[4];
} Manager;
 
 
And the newer library has the same struct like this:
 
typedef struct {
u16 scale;
u8 window;
u8 a;
u8 b;
u8 c;
float x;
float y;
float z;
s8 offset;
u8 transparent : 1;
u8 reserved0 : 7;
u8 reserved1[2];
u32 reserved2[3];
} Manager;
 
I want to set the member "transparent" on both platforms, and so I started out with code like this:
 
void Set_Flag_For_Transparency(Manager &e)
{
float *const p_z = &e.z;
u8 *const p_offset = reinterpret_cast<u8*>(p_z + 1u);
u8 *const p_byte_containing_transparent = p_offset + 1u;
*p_byte_containing_transparent |= 0x80; //Set the high bit
}
 
After doing a little reading up on bitfields, it seems that ISO/ANSI standards give compilers a lot of freedom as to how bitfields are implemented -- so much freedom in fact that they don't have much use in portable code. For example, in my function just above, the 'transparent' bit might be 0x80 or it might be 0x01. Bits might not straddle bytes, and really the only thing that's guaranteed is the number of bits of precision (e.g. if it's 3 bits then the max value is 7).
 
Are bitfields pretty much useless other than for limiting the max value of an integer type (e.g. 3 bits for 7, 4 bits for 15, 5 bits for 31)?
 
The people who wrote the library I'm working with either:
(A) Expect me to use the same compiler as them
(B) Expect me to use a compiler that implements bitfields the same way
(C) Don't know that bitfields aren't portable for this purpose
Bo Persson <bo@bo-persson.se>: Jul 30 11:36AM +0200

On 2020-07-30 at 11:09, Frederick Gotham wrote:
> (A) Expect me to use the same compiler as them
> (B) Expect me to use a compiler that implements bitfields the same way
> (C) Don't know that bitfields aren't portable for this purpose
 
or (D) Don't use an older library when there is an new and improved one
 
Note that the ISO standard doesn't require a compiler to have 8, 16, or
32 bit integer types, and doesn't say what size a float is. Or if there
are padding between members. So this is totally non-portable anyway.
 
And it definitely doesn't give any meaning to
 
reinterpret_cast<u8*>(p_z + 1u)
 
so don't do that.
 
The only portable way to set the transparent bit is
 
e.transparent = 1;
 
 
If you just *have* set a byte in the reserved area, you could do
 
#if defined SOME_OLD_SYSTEM
e.reserved[0] = transparent_hack_value;
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)