Thursday, November 28, 2019

Digest for comp.lang.c++@googlegroups.com - 16 updates in 8 topics

Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 28 12:19PM -0800

> unanticipated effects and confusion in clumsy hands. However for
> teams that manage to hire members with godly hands macros are
> fine. :D
 
This doesn't answer my question. I understand that macros have
shortcomings in some applications. The question is why do C++
fans hate using macros even when, like here, the shortcomings
don't apply?
Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 28 12:27PM -0800


> A. But, but, with signed integers, there are different
> representations, so that on some hardware it does not actually wrap!
 
> B. Ouch, my head is hurting. Just declare it undefined then!
 
I believe your view of the history doesn't match what actually
occurred. I don't propose attempting to resolve the matter; I
just wanted to be clear that I think I see what you're saying
even though I believe some of your premises don't match the
historical facts.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 29 12:14AM +0100

On 28.11.2019 21:19, Tim Rentsch wrote:
>> teams that manage to hire members with godly hands macros are
>> fine. :D
 
> [snip] here, the shortcomings [of macros] don't apply?
 
They do.
 
For example, regarding what was mentioned about scope, you generally
can't have two libraries that both define `ONESCOMPLEMENT`. Perhaps
library A defines it as above but library B defines it to produce a
one's complement. Perhaps both define it as above but using library B
you get a redefinition warning.
 
And for example, regarding the so far not mentioned visual impact, the
shouting uppercase is an annoying eyesore.
 
 
- Alf
woodbrian77@gmail.com: Nov 28 11:29AM -0800

Shalom, comp.lang.c++,
 
I think my work in terms of on-line services is
in pretty good shape, but I'll let you be the judge:
 
https://github.com/Ebenezer-group/onwards
 
https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/genz.cc
https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc
 
If you have suggestions on how to improve things, please
let me know.
 
 
Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net
"Öö Tiib" <ootiib@hot.ee>: Nov 28 03:02PM -0800

> Shalom, comp.lang.c++,
 
> I think my work in terms of on-line services is
> in pretty good shape,
 
Ok.
 
> but I'll let you be the judge:
 
> https://github.com/Ebenezer-group/onwards
 
> https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/genz.cc
 
Strange little piece of code. What it does?
Why "::exit(EXIT_SUCCESS);" is better than "return EXIT_SUCCESS;"
in main()?
Also I would manually inline the "leave" since its name
and all the missing comments hide that it was a failure.
 
> https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc
 
C++17 features seem to be used just to make it harder
to read like:
 
if(auto ind=buf.reserveBytes(1);!buf.receive(ind,marshalFile(mdlFile,buf)))
receive(buf,mdlFile,1);
 
60 lines feels bit too long for a conversion constructor. Is
ambassador destructively constructing itself into that
"config"? Or why else conversion constructor has a mutable
parameter?
 
> If you have suggestions on how to improve things, please
> let me know.
 
Unsure. Does it have some benefits over Protobufs, Flatbuffers, Cereal,
Cap'n Proto, Bond, Apache Avro, Thrift, MessagePack etc etc?
 
With every other serialization library it takes about 15 minutes from
downloading or cloning to get something to work with no any external
aid needed. Here it is building some kind of 4 executables that are
needed to be registered somewhere even to try.
Robert Wessel <robertwessel2@yahoo.com>: Nov 28 02:04PM -0600

On Thu, 28 Nov 2019 11:58:40 +0100, Bo Persson <bo@bo-persson.se>
wrote:
 
>00007FF6BB091000 mov eax,1
>}
>00007FF6BB091005 ret
 
 
I've noticed the same effect a number of times - MSVC has, for quite a
while, tends to generate somewhat naive code for the basic function in
some cases, while going to town on optimization for inlined versions.
Not always, just sometimes, I've never quite figured out why - I've
usually assumed better parameter aliasing resolution for the inlined
version, although that would hardly apply to this example.
 
 
>/Fo"x64\Release\" /Ot /Fp"x64\Release\quick_test_ms.pch"
>/diagnostics:column
 
>Don't know exactly which one makes the difference. :-)
 
 
Almost certainly /W4 instead of /Wall. The latter is pretty unusable.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 28 01:52PM -0800


> Is it reasonable that vs2019 produces a warning
 
> warning C4127: conditional expression is constant
> consider using 'if constexpr' statement instead
 
Let me rephrase your question as a multiple choice:
 
"A compiler operating under default option settings
produces this warning message for the above program.
Would you be more likely to describe this choice as
 
(A) reasonable, or
 
(B) monumentally stupid?"
 
Asked like this, my answer would be (B).
 
There are, I am sure, a large number of related questions,
for which I expect I would give various answers depending
on the particular question.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 28 01:44PM -0800


> Okay I guessed that much, but why can't the compiler do the latter when
> there is only one pair of braces? The error message clearly indicates
> that an initializer list is considered.
 
I don't have anything to add about why this example behaves as it
does, but I have two related comments. One, it doesn't surprise
me at all that two pairs are braces are needed. Two, I'm not
sure having it work with only one pair of braces is a good idea;
if anything I suspect it would be more confusing than helpful.
My analogy is initializing structs (for C, I don't know if C++
might have changed here): I know there are rules for omitting
braces in some cases when initializing structs with nested arrays
or nested structs, but it seems insane to take advantage of those
rules. Presumably they were put in for compatibility with early
C code, which makes sense, but not continuing to use them going
forward. Returning to the C++ example, having two pairs of
braces matches my understanding of what's going on; allowing
only one pair of braces to do the same thing would mean I have
to create a more elaborate and more complicated mental model to
understand what the program is doing and how the language works.
I would much rather not to have to create these more elaborate
models. Do you see what I mean?
Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 28 12:51PM -0800


> I said that wrong. Unless all members of the struct have the maximum
> alignment requirement, it's possible that such an implementation would
> have to put padding at the end.
 
Don't you mean, unless the last member of a struct has the
maximum alignment requirement, it's possible such an
implementation would have to put padding at the end.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 28 01:21PM -0800


> long ago CHAR was 8 bit wide, but now it seems to be platform
> dependent, and more often "a word" wide.
 
> QT has its explicitely sized integers (even if no 8-bit sized)
 
I would offer an alternate set of suggestions.
 
First, pick a name for the type you will use in your code. For
example, in this case, you might pick 'GamByte' as the type
name you will be using.
 
Second, see if the library being used (Gambas) supplies a name
for its type in one of its headers. If it does, define your
type name in terms of that. These names might even be the same,
except they might be declared in different namespaces.
 
Third, if the library being used does not supply a name for the
type it is using, but just spells out the concrete type in its
function declarations, etc, define your type name as that, eg,
 
using GamByte = unsigned char; // for use with Gambas
 
where 'unsigned char' is meant to be the type given in Gambas
header files, assuming there is one.
 
Fourth, if the library being used does NOT have the type in
question appear in any of its header files, use 'unsigned char'.
If it's important to guarantee that the type is exactly eight
bits, use a static assertion that CHAR_BIT == 8. The reason
is that 'unsigned char' is guaranteed to work, if any type
is, and if for any reason it doesn't work then the error message
produced by the static assertion will be more easily understood
than, eg, a syntax error trying to use a non-existent uint8_t.
 
Fifth, if you never need individual 8-bit bytes in isolation, but
only in aggregates (arrays or array-like), you might consider
defining the aggregate type as a struct inside a template, which
externally could look like an array of 8-bit types even though
internally it might be, eg, 32-bit unsigned words used to hold
four 8-bit values.
Frederick Gotham <cauldwell.thomas@gmail.com>: Nov 28 07:58AM -0800

I have two programs that I need to obfuscate.
 
The first one is just two source files and doesn't link with any 3rd party libraries, so I just went through the code line by line and tagged each function with "__attribute__((always_inline))". This worked fine.
 
The second program is more complicated. It is linked statically with a 3rd party library that I have the source code for. I could go through the code for the 3rd party library and tag each function with 'always_inline' but I'm looking for a cleaner and handier solution.
 
If I take the assembler for my second program, or even the binary executable file in ELF format, then I could manipulate the assembler (or machine code) in order to remove all function calls (and also unroll all loops if possible). Is there a tool for doing this?
 
I suppose another thing I could do is compile the 3rd party library with some sort of global setting that every function has the attribute "always_inline".
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 28 07:47PM +0100

On 28.11.2019 16:58, Frederick Gotham wrote:
 
> The second program is more complicated. It is linked statically with a 3rd party library that I have the source code for. I could go through the code for the 3rd party library and tag each function with 'always_inline' but I'm looking for a cleaner and handier solution.
 
> If I take the assembler for my second program, or even the binary executable file in ELF format, then I could manipulate the assembler (or machine code) in order to remove all function calls (and also unroll all loops if possible). Is there a tool for doing this?
 
> I suppose another thing I could do is compile the 3rd party library with some sort of global setting that every function has the attribute "always_inline".
 
https://en.wikipedia.org/wiki/AARD_code
 
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: Nov 28 11:19AM -0800

On Thursday, 28 November 2019 17:59:10 UTC+2, Frederick Gotham wrote:
 
> The second program is more complicated. It is linked statically with a 3rd party library that I have the source code for. I could go through the code for the 3rd party library and tag each function with 'always_inline' but I'm looking for a cleaner and handier solution.
 
Obfuscation won't hide that you use General Public License
library in your closed source product. If anyone cares then
they wait a bit and then suggest the copyright holders to sue you
with license agreement violation.
Frederick Gotham <cauldwell.thomas@gmail.com>: Nov 28 01:10PM -0800

"Obfuscation won't hide that you use General Public License library in your closed source product. If anyone cares then they wait a bit and then suggest the copyright holders to sue you with license agreement violation."
 
I'm not.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 28 12:46PM -0800


> I tend to agree. I use auto, but try to be careful so it won't be a
> problem when I revisit the code, like my duck typing exercises are in
> Python.
 
I don't have a lot of experience with "auto" in C++, but a fair
amount of experience with type inference (and not needing type
annotations in many cases) in other programming languages. I
don't have any hard and fast rule, but generally I find it works
well to give an explicit type annotation only in those cases
where it's important to know exactly what the type is. Probably
this rule carries over into C++ reasonably well, although the
two situations are not completely parallel. In particular, C++
doesn't have partial types, except maybe for arrays -- it's
pretty much all or nothing, either a completely specified type
or none at all; there is no way in C++ to say a type is "a list
of something, but I won't say what the something is". But I
think the general rule is still good in the C++ domain.
Soviet_Mario <SovietMario@CCCP.MIR>: Nov 23 01:17PM +0100

I have realized I don't know an aspect of padding vs packing
management.
 
In the other thread I have been explained of the aspects of
padding/packing INSIDE a given structure/class/union and
similar.
 
But now I realize I know nothing for sure about packing in
between different element within arrays of such
structure/class/union and similar.
 
for a start I haven't found a documentation about the
#pragma pack directive applied to a whole array
 
is it possible (and how) to suggest the compiler to pack
items ? (*)
Are there differences in the outcome of such hints depending
on actual size of the packed structures ?
I am figuring out a packed struct of ODD total size, when
allocated in an array, it could lead to either non packed
array or to addresses in ODD/EVEN pattern (is it possible ?
Non asking if efficient, just possible).
 
 
secondly, how much is it, reasonably, the no-padding
threshold in an array of class/struct/union objects ?
 
There is some criterion, preferably less restrictive than
"powers of two" size of objects" ?
 
I feel quite sure that 64 bit multiple are packed without
any suggestion.
But, for example, 32 bit ? 16 bit ?
 
The hardware per se has no problem : in fact it can manage
COMPACT arrays of native types (int, short int) without
memory waste. I would hope that the same could hold for
structured types of the same size, but not so sure.
What is the truth ?
 
 
Could packing (assuming it is possible to force the compiler
to do it) lead to addressing problems (of the contained data
member) ?
I am not speaking about SLOWING problems, but strictly
crashes or silent wrong addressing or ... dunno !
 
TY
 
 
 
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
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)