Wednesday, April 17, 2019

Digest for comp.lang.c++@googlegroups.com - 23 updates in 7 topics

Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 17 11:36AM

On Wed, 2019-04-17, Juha Nieminen wrote:
> people just hate namespace prefixes in C++, and go to great lengths
> to avoid them and will rabidly defend this practice, and oppose their
> use. No amoung of argumentation will convince them otherwise.
 
I think c.l.c++ posters are atypical C++ users these days. In real
life I've never met anyone who avoids prefixes that way. So in that
sense it's a non-issue ... I try not to worry about it.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Robert Wessel <robertwessel2@yahoo.com>: Apr 17 09:58AM -0500

On Wed, 17 Apr 2019 07:06:48 -0000 (UTC), Juha Nieminen
 
>I bet that if they didn't know that writing namespace prefixes is
>optional, that you can bypass it with a `using` expression, they
>would not protest having to write it.
 
 
While I rarely use "using", I suspect it's more that people dislike
the prefix std:: in particular. There seems to be a lot less
resistance to using it for non-core libraries. There's a least
something of a point there. The considerable proliferation of
"std::"s for those core functions doesn't appear to add much for most
programs.
 
C and C++ have much of what would be core functionality in other
languages defined in their libraries, so for things like string and
complex std:: arguably adds nothing but clutter.
 
OTOH, I don't think there's that much objection to requiring it on the
more obscure corners of the library.
Manfred <noname@add.invalid>: Apr 17 06:07PM +0200

On 4/17/2019 9:06 AM, Juha Nieminen wrote:
> some peculiar reason they hate having to write "prefix::name()", and will
> get rid of having to do it.
 
> What's the difference?
No definite answer, obviously, since this is mostly a matter of taste,
and.. de gustibus non disputandum est.
 
One difference I may see is right as you mention that the namespaces
come with C++ libraries, while it is C libraries that come with
prefixes, which tends to bias the kind of user.
In C naming conventions are far more important that in C++, so for C
programming attention to prefixes is simply good discipline that makes
life easier.
 
In C++, having scope delimiters like namespaces and classes, the
importance of the single identifier is less critical, which possibly
feeds the aversion you see.
 
But, FWIW, I don't share such aversion and I easily tend to prefer std::
prefixes to using directives. I think that such a decoration of the name
with its source makes the code tidier.
Even more with third party libraries.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 17 01:15PM

On Wed, 2019-04-17, Fred.Zwarts wrote:
>>can't tell at a glance what code is standard and what code is non-standard.
 
>>/Leigh
 
> If somebody missed the fact that string is defined in the std:: namespace,
 
It's not, not necessarily. I may want to use the name "string"
locally, and don't expect such a name to conflict with the standard
library. Not to mention names like find().
 
> than he is probably a very inexperienced C++ programmer. For most C++
> programmers, std:: adds nothing as a prefix to string in terms of
> readability.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Juha Nieminen <nospam@thanks.invalid>: Apr 17 04:57PM

> Another reason, in particular for names that are used very often, is that in
> complex expressions 'string' is easier to read than 'std::string', because
> it is easier to keep the expressions short.
 
If you use a C library like for example libpng, most names declared
in that library have the prefix "png_". Do you go your way to create
aliases for those names (eg. using macros of whatever) that have that
prefix removed?
 
If not, then what's the difference? Why does it not bother you to
have to write a prefix like for example "png_", but it does bother
you to have to write a prefix like for example "std::"?
 
I'm honestly curious to know.
Daniel <danielaparker@gmail.com>: Apr 17 01:36PM -0700


> I suspect it's more that people dislike the prefix std::
 
"std" was a rather uninspired choice as a namespace name, in contrast with
other languages that have well thought out divisions of namespaces, C++
chose to put almost everything into one big garbage dump. Although this does
seem to be changing, with some of the recent additions.
 
Daniel
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 17 04:24PM +0200

On 17.04.2019 16:15, Alf P. Steinbach wrote:
> last semicolon.
 
> The perhaps currently cryptic JavaScript-like start and end of that code
> is a pattern that one might as well get used to.
 
Oh, sorry, for the start I meant
 
[&](){
 
capturing reference to the variables.
 
And also failed to mention, as before in this thread, the multi-line
lambda indicates to me that it should probably be a named function.
 
 
Cheers!,
 
- Alf
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 17 10:55AM -0400

On 4/17/2019 10:05 AM, Bart wrote:
 
> Another point is that as written, 'sw' has to be known outside so cannot be
> local to the loop. (In my example, the code to be executed can be brought
> inside the loop body; sometimes it can't. But 'found' needs to be outside.)
 
In CAlive, I have setup flow control blocks for this type of logic. It
prevents many types of temporary variables, and allows structured flow
movement without using gotos or something else complex:
 
bool found = false;
int sw;
 
flow
{
for (sw = 0; sw < len; sw++
{
if (strcmp(name, options[sw]) == 0)
flowto found;
}
 
} found {
do_option(sw, value);
}
 
If you need to return back to where you were after "calling found," you
would use the () syntax. You can also pass in parameters if they are
defined:
 
flowto found(); // Run the code, and return
 
--
Rick C. Hodgin
David Brown <david.brown@hesbynett.no>: Apr 17 02:05PM +0200

On 17/04/2019 12:38, Bart wrote:
>>> convincing but exactly opposite notions of what `else` should mean if it
>>> were introduced as an extension to `for`...
 
> Its use in Python is not hard to understand.
 
That is debatable. But I agree it is easier (and more useful) than
Rick's suggestion.
 
>         println "Unknown option:",name
>         stop 1
>     od
 
bool found = false;
int sw;
for (sw = 0; sw < len; sw++) {
if (strcmp(name, options[sw]) == 0) {
found = true;
break;
}
}
if (found) {
do_option(sw, value);
} else {
printf("Unknown option: %s\r\n", name);
stop(1);
}
 
The "for else" construct is not necessary, and the bool flag solution
will be just as efficient. Structuring the code as "try to find the
match, then handle the result" is arguably neater (and by "arguably", I
don't mean it is /definitely/ neater). It also makes it easier to
refactor the code if you have a different way of searching, perhaps as a
separate function.
 
 
>     fi
 
> I must have written a thousand such loops; the for-else feature provides
> a welcome respite, as well as a self-contained solution in one statement.
 
A smaller and more compact solution could be nice - but that would, as
you say, require a higher level language.
 
 
> The flag version introduces a new variable that demands an extra, wider
> scope, something at odds with your preference for narrower block scopes.
 
I have a preference for narrower scopes, all else being equal. But if
the data is needed over a wider range, then a wider scope is the answer.
David Brown <david.brown@hesbynett.no>: Apr 17 05:51PM +0200

On 17/04/2019 16:16, Bart wrote:
>>         do_option(optionnames[name], value);
 
> You're doing a double lookup, one with "in", and one with [], which
> latter would require optionnames to be a dict. It gets messy.
 
Depending on the data structure, the double lookup would often be fast
and simple. In a compiled language with an optimising compiler,
especially in a language which emphasises immutable data (as most modern
languages do), this could be optimised.
 
However, this is just sample code in an imaginary language - not
something we need to figure out in detail.
 
>> confusion - I think its use would be rare, and alternative simple and
>> clear solutions are easily available.
 
> It's rare partly because languages don't have it!
 
Mostly it is rare because you don't usually need it.
 
David Brown <david.brown@hesbynett.no>: Apr 17 05:55PM +0200

On 17/04/2019 16:15, Alf P. Steinbach wrote:
>     } else {
>         my::fail( ""s + __func__ + " - unknown option '" + name + "'" );
>     }
 
Maybe a std::optional would be a nicer choice here, rather than having
to manipulate the index number?
Bart <bc@freeuk.com>: Apr 17 01:57PM +0100

On 17/04/2019 13:05, David Brown wrote:
>>>> were introduced as an extension to `for`...
 
>> Its use in Python is not hard to understand.
 
> That is debatable.
 
The controversy is with the use of the 'else' keyword. The idea of
having code executed only on normal loop termination, not so much.
 
> }
 
> The "for else" construct is not necessary, and the bool flag solution
> will be just as efficient.
 
So why not:
 
if (found) {
do_option(sw, value);
}
if (!found) {
printf("Unknown option: %s\r\n", name);
exit(1);
}
 
We don't really need 'if else' either. (I'm sure I didn't have that in
Fortran years ago.)
 
 
> A smaller and more compact solution could be nice - but that would, as
> you say, require a higher level language.
 
By higher level I mean something like:
 
do_option(name in optionnames, value)
 
'in' would return 1..len or 0, so do_option would have to deal with a
option code of 0, to keep it simple.
 
Higher level code tends not to have so many explicit loops, but so long
as for-loops /are/ still used, then an 'else' clause containing
dedicated code for a normal termination rather than a break will still
be useful.
Bart <bc@freeuk.com>: Apr 17 05:44PM +0100

On 17/04/2019 15:15, Alf P. Steinbach wrote:
>> option code of 0, to keep it simple.
 
> That places responsibility for dealing with an unknown option down in
> `do_option`, via an `if` or `switch` or something.
 
Yeah, I forgot about the error message. Then do_option can just return
the option number (or a status), and it becomes necessary to wrap withe
do_option call with an 'if'.
 
Dealing with option 0 inside do_option is not an issue (in my code it
means adding one line 'when 0 then' to ignore that option number).
 
> }();
 
> `return` is a nice statement; here it returns to the point after the
> last semicolon.
 
So, defining an anonymous function, immediately calling it, and using
'return' to provide the alternate exit path from the loop that is required.
 
Clever, but the kind of cleverness that obscures the mundane task that
we are actually trying to do [in this case].
 
As a reminder, here's my original for-else example in a bigger context:
 
https://pastebin.com/Yv6xQg92
 
(This processes command-line options and filenames for a C compiler, but
the same pattern is used in several programs.)
 
This bit doesn't need to be fast, and it doesn't need to be clever.
Bart <bc@freeuk.com>: Apr 17 05:48PM +0100

On 17/04/2019 17:44, Bart wrote:
 
> As a reminder, here's my original for-else example in a bigger context:
 
>   https://pastebin.com/Yv6xQg92
 
(That guest paste doesn't seem to work. Try:
 
https://pastebin.com/raw/bNUNjk4K)
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 17 08:43PM +0100

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
<cut>
> Going back even further historically, C's parent language BCPL had a
> construct that one can think of as "arithmetic blocks", like a curly
> braces compound statement that could return a value.
 
Yes. VALOF $( ... RESULTIS exp ... $) to be precise, with later
versions permitting { } in place of $( $). And of course gcc has
statement expressions as an extension, though you can't "return" from
them at arbitrary points -- the last expression is the value.
 
> if( not loop_body_executed ) {
> // The logical "else" part.
> }
 
This is not the example I had, so the bool is not well named as it is
not always set true when the loop body executes.
 
I can't think of a neat way to avoid using the flag variable, even
using BCPL-style VALOF:
 
IF NOT VALOF $(
LET loop_body_executed = FALSE
FOR N = 1 TO MAX DO $(
code; code; loop_body_executed := TRUE
$)
RESULTIS loop_body_executed
$) DO $(
// original else part
$)
 
But there's a bigger problem with both this and the lambda version:
neither abstracts over the loop code. You write it fresh each time.
And you can't even cut and paste the loop code because 'break's have to
turn into 'return true'.
 
In Lisp you could write a macro for both meanings where the user simply
has to supply the loop code and the 'else' code.
 
> -> decltype(( f() ))
> { return f(); }
> } // namespace lambda_support
 
This seems to be getting close to what I'd call lambda abuse. Is it
worth it to avoid the () that you'd otherwise need? I realise I may be
missing the point, though.
 
<cut>
--
Ben.
Horizon68 <horizon@horizon.com>: Apr 17 11:50AM -0700

Hello..
 
 
More about Energy efficiency..
 
You have to be aware that parallelization of the software
can lower power consumption, and here is the formula
that permits you to calculate the power consumption of
"parallel" software programs:
 
Power consumption of the total cores = (The number of cores) * (
1/(Parallel speedup))^3) * (Power consumption of the single core).
 
 
Also read the following about energy efficiency:
 
Energy efficiency isn't just a hardware problem. Your programming
language choices can have serious effects on the efficiency of your
energy consumption. We dive deep into what makes a programming language
energy efficient.
 
As the researchers discovered, the CPU-based energy consumption always
represents the majority of the energy consumed.
 
What Pereira et. al. found wasn't entirely surprising: speed does not
always equate energy efficiency. Compiled languages like C, C++, Rust,
and Ada ranked as some of the most energy efficient languages out there,
and Java and FreePascal are also good at Energy efficiency.
 
Read more here:
 
https://jaxenter.com/energy-efficient-programming-languages-137264.html
 
RAM is still expensive and slow, relative to CPUs
 
And "memory" usage efficiency is important for mobile devices.
 
So Delphi and FreePascal compilers are also still "useful" for mobile
devices, because Delphi and FreePascal are good if you are considering
time and memory or energy and memory, and the following pascal benchmark
was done with FreePascal, and the benchmark shows that C, Go and Pascal
do rather better if you're considering languages based on time and
memory or energy and memory.
 
Read again here to notice it:
 
https://jaxenter.com/energy-efficient-programming-languages-137264.html
 
 
 
Thank you,
Amine Moulay Ramdane.
Horizon68 <horizon@horizon.com>: Apr 17 11:32AM -0700

Hello..
 
 
I have implemented a C++ MemPool for real-time systems
 
You can read about it and download from my website here:
 
https://sites.google.com/site/scalable68/c-mempool-for-real-time-systems
 
 
Thank you,
Amine Moulay Ramdane.
Horizon68 <horizon@horizon.com>: Apr 17 11:44AM -0700

On 4/17/2019 11:32 AM, Horizon68 wrote:
 
> https://sites.google.com/site/scalable68/c-mempool-for-real-time-systems
 
> Thank you,
> Amine Moulay Ramdane.
 
 
 
You can find my Delphi and Freepascal MemPool for realtime systems here:
 
https://sites.google.com/site/scalable68/mempool-for-realtime-systems
 
 
 
Thank you,
Amine Moulay Ramdane.
Horizon68 <horizon@horizon.com>: Apr 17 11:28AM -0700

Hello...
 
Read this:
 
 
Parallel C++ Conjugate Gradient Linear System Solver Library that scales
very well version 1.76
 
Author: Amine Moulay Ramdane
 
Description:
 
This library contains a Parallel implementation of Conjugate Gradient
Dense Linear System Solver library that is NUMA-aware and cache-aware
that scales very well, and it contains also a Parallel implementation of
Conjugate Gradient Sparse Linear System Solver library that is
cache-aware that scales very well.
 
Sparse linear system solvers are ubiquitous in high performance
computing (HPC) and often are the most computational intensive parts in
scientific computing codes. A few of the many applications relying on
sparse linear solvers include fusion energy simulation, space weather
simulation, climate modeling, and environmental modeling, and finite
element method, and large-scale reservoir simulations to enhance oil
recovery by the oil and gas industry.
 
Conjugate Gradient is known to converge to the exact solution in n steps
for a matrix of size n, and was historically first seen as a direct
method because of this. However, after a while people figured out that
it works really well if you just stop the iteration much earlier - often
you will get a very good approximation after much fewer than n steps. In
fact, we can analyze how fast Conjugate gradient converges. The end
result is that Conjugate gradient is used as an iterative method for
large linear systems today.
 
 
You can download it from:
 
https://sites.google.com/site/scalable68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library
 
 
Thank you,
Amine Moulay Ramdane.
Horizon68 <horizon@horizon.com>: Apr 17 11:27AM -0700

Hello...
 
 
I have just implemented a Getmem_aligned and Freemem_aligned for Delphi
and FreePascal, you can port it to C++ if you want, here it is:
 
https://sites.google.com/site/scalable68/getmem_aligned-for-delphi-and-freepascal
 
 
Thank you,
Amine Moulay Ramdane.
Horizon68 <horizon@horizon.com>: Apr 17 10:23AM -0700

Hello,
 
Read this:
 
 
What tool can decompile a DLL into C++ source code?
 
This might be impossible or at least very hard. The DLL's contents don't
depend (a lot) on it being written in C++; it's all machine code. That
code might have been optimized so a lot of information that was present
in the original source code is simply gone.
 
About obfuscation for FreePascal / Lazarus and Delphi compiled files
 
Just compiling with optimizations (-O2 and up) and stripping all debug
and profile information, and apply smartlinking, will make it almost
un-decompilable. Not only FPC, but also Delphi. I remember using
Delphi decompilers for Delphi 6 and they were unable to decompile any
actual code except resources.
 
 
Thank you,
Amine Moulay Ramdane.
Bonita Montero <Bonita.Montero@gmail.com>: Apr 17 07:32PM +0200

I don't believe that a C++-decompiler would make sense because the
metainformation about classes, templates, exceptions and whatever
can't be regained from the machine code.
The only decompiler I know is the IDA decompiler and it decompiles
into C-code.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 17 10:37AM -0700

On Wednesday, April 17, 2019 at 1:23:46 PM UTC-4, Horizon68 wrote:
> What tool can decompile a DLL into C++ source code?
 
A recent tool released by the NSA may be a good place to start.
I've only read summaries about it, but if it lives up to the
hype...:
 
Article about Ghidra:
https://www.nsa.gov/News-Features/News-Stories/Article-View/Article/1775584/ghidra-the-software-reverse-engineering-tool-youve-been-waiting-for-is-here/
 
Download:
https://www.nsa.gov/resources/everyone/ghidra/
 
Highlight:
 
"One of Ghidra's most noteworthy features is a processor
modeling language called Sleigh that specifies how machine
language instructions are dissembled and transformed into
the tool's intermediate representation called P-code.
Other significant functions are an undo/redo feature, multi-
user collaboration repository, and scripting."
 
"Ghidra is a software reverse engineering (SRE) framework
developed by NSA's Research Directorate for NSA's cybersecurity
mission. It helps analyze malicious code and malware like
viruses, and can give cybersecurity professionals a better
understanding of potential vulnerabilities in their networks
and systems."
 
"We look forward to ideas and contributions from the community!"
 
--
Rick C. Hodgin
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)