Thursday, May 31, 2018

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

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 31 08:19PM +0100

On 30/05/2018 14:35, Scott Lurndal wrote:
> #define ASTERISK *
> char ASTERISK p
 
> who cares?
 
There is an even simpler (and better) solution: DON'T DECLARE MULTIPLE
VARIABLES ON THE SAME LINE.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
bart4858@gmail.com: May 31 02:30PM -0700

On Thursday, 31 May 2018 20:20:06 UTC+1, Mr Flibble wrote:
 
> There is an even simpler (and better) solution: DON'T DECLARE MULTIPLE
> VARIABLES ON THE SAME LINE.
 
That's not a solution, it's a workaround. And comes with a disadvantage; suppose that T includes any pointer, array, or function pointer modifiers, then instead of writing:
 
T x, y, z;
 
which tells you that these variables are likely related, and they have a common type which is automatically kept in sync, you have to write:
 
T x;
T y;
T z;
 
Then that relationship is lost, and it will need more maintenance to ensure they stay the same type.
 
So declaring several names with the same type spec is useful.
 
The original C syntax however allows you to declare several names together but with *different* types (and they can be wildly different), which is not useful and is bad practice.
 
--
bart
David Brown <david.brown@hesbynett.no>: May 31 11:49PM +0200

(Please get a real news client, or fix your line endings if you have to
use Google's broken interface. It makes it a pain for others to sort
out your messed up line breaks.)
 
 
 
>> There is an even simpler (and better) solution: DON'T DECLARE
>> MULTIPLE VARIABLES ON THE SAME LINE.
 
> That's not a solution, it's a workaround.
 
It is a solution to the problem "how should I declare several pointer
variables in a way that won't be confusing?".
 
> T z;
 
> Then that relationship is lost, and it will need more maintenance to
> ensure they stay the same type.
 
That might, occasionally, be a relevant point. I can't speak for Mr.
Flibble, of course, but I would be okay with "T x, y, z;" in such simple
cases. But I am /not/ okay with "char* c, d;" or "char *c, d;" - it is
far too easy to misread these.
 
More commonly, however, you have longer type names (including
qualifiers), initialisers, descriptive variable names, comments, etc.,
which mean putting multiple object definitions on one line becomes a mess.
 
 
 
> So declaring several names with the same type spec is useful.
 
/Occasionally/ useful.
 
 
> The original C syntax however allows you to declare several names
> together but with *different* types (and they can be wildly
> different), which is not useful and is bad practice.
 
Agreed. And for me, that rule includes cases like the sample one here
with a "char" and a "char*".
Lynn McGuire <lynnmcguire5@gmail.com>: May 31 05:55PM -0500

On 5/31/2018 2:19 PM, Mr Flibble wrote:
 
> There is an even simpler (and better) solution: DON'T DECLARE MULTIPLE
> VARIABLES ON THE SAME LINE.
 
> /Flibble
 
+1,000,000
 
Lynn
scott@slp53.sl.home (Scott Lurndal): May 31 06:00PM

>then passes control to the exception handler in the naughty program.
>This will take quite a long time. IF you're really concerned about
>security your kernel will make sure it's a _loooooong_ time.
 
I don't have a lot of time to respond to this, but if you google search for
 
"timewarp: rethinking timekeeping and performance monitoring mechanisms to mitigate
side-channel attacks"
 
There are descriptions of and references to the various side-channel
attacks via cache timing et alia in that paper.
Vir Campestris <vir.campestris@invalid.invalid>: May 31 11:03PM +0100

On 31/05/2018 19:00, Scott Lurndal wrote:
> side-channel attacks"
 
> There are descriptions of and references to the various side-channel
> attacks via cache timing et alia in that paper.
 
This paper?
 
<http://www.cs.columbia.edu/~simha/preprint_isca12_tw.pdf>
 
That's a much more complete solution to a much wider range of problems,
but one that requires that the CPU is modified.
 
As they say you can't afford to cache flush on every context switch.
There's also no way to flush the branch predictor cache (which I'd
forgotten about TBH) but for the class of attacks which rely on the
pipeline pre-fetching stuff to which the program has no right of access,
which causes detectable changes in the cache, clearing the cache ought
to destroy all that side channel data. Leaving only the branch predictor
(which someone will of course use...)
 
I also feel that killing the process after a few exceptions would be a
good thing to do. Though no doubt there will be a way around that too.
 
After an exception for an illegal access the state of the cache (and the
branch predictor cache) will be different depending on whether the page
accessed did not exist or was blocked, and also depending on the
contents of that page.
 
The attacks I have read about rely on detecting the state of the cache
after the exception.
 
Flushing the cache after such an exception and before returning control
to the user program will destroy that information in the cache.
 
I do not see that such a change would be harmful, and it would block one
class of attacks.
 
Andy
bintom <binoythomas1108@gmail.com>: May 30 10:50PM -0700

I noticed that there are no library functions in Dev C++ to display a blinking message. So I wrote this function, which I hope does the job for any oneout there.
 
void Blink(char *str)
{ cout << "\n";
 
while(true)
{ cout << str;
for(long l1=0; l1<300000000; l1++);

for(int i=0; i<5; i++)
cout << "\b";
for(int i=0; i<5; i++)
cout << " ";

for(long l1=0; l1<300000000; l1++);
 
for(int i=0; i<5; i++)
cout << "\b";
}
}
 
int main()
{ Blink("Message"); }
"Öö Tiib" <ootiib@hot.ee>: May 30 11:15PM -0700

On Thursday, 31 May 2018 08:50:59 UTC+3, bintom wrote:
> }
 
> int main()
> { Blink("Message"); }
 
Seems waste of computing power. There is usually something more sane
than busy loop for delaying an action. That Dev C++ is AFAIK MinGW and
So you can use Windows functions like Sleep in it.
David Brown <david.brown@hesbynett.no>: May 31 09:33AM +0200

On 31/05/18 07:50, bintom wrote:
> I noticed that there are no library functions in Dev C++ to display
> a blinking message. So I wrote this function, which I hope does the job
> for any oneout there.
 
There are a number of "improvement opportunities" in this code. I don't
want to demoralise you by listing everything I can think of, especially
as that would also lead to discussions about details or alternative
constructions that are probably beyond what you are interested in at the
moment.
 
But there is a /big/ mistake here, IMHO - your delay loops. These are
bad for a number of reasons:
 
1. They are totally dependent on the individual computer for their
timing. Faster or slower processors will give you shorter or longer delays.
 
2. They are busy-waiting, blocking a cpu core while waiting.
 
3. The delays will vary according what else is going on in your machine.
 
4. If you change the optimisation level, or other compiler details, the
loops will change timings - the compiler is also free to see that the
loops are pointless and can be removed altogether.
 
So a "count for a bit" delay loop is almost never a good idea. (They do
see occasional use in embedded systems, for very specific purposes on
specific known chips for short delays. And even then, they are written
differently.)
 
Standard C++ libraries do not have a "wait a bit function". But every
multi-threaded or multi-processing OS has a "sleep" function of some
sort. If you are writing for a specific operating system, find out what
kind of "sleep" call it supports, and use it. If you are writing with a
cross-platform toolkit (like Qt, wxwidgets, etc.), then use the call
from those libraries.
 
 
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 31 09:53AM +0200

On 31.05.2018 09:33, David Brown wrote:
> [snip]
> Standard C++ libraries do not have a "wait a bit function".
 
std::this_thread::sleep_for
 
Docs at
 
<url: http://en.cppreference.com/w/cpp/thread/sleep_for>
 
Example usage,
 
sleep_for( 2s );
 
 
Cheers!,
 
- Alf
David Brown <david.brown@hesbynett.no>: May 31 10:12AM +0200

On 31/05/18 09:53, Alf P. Steinbach wrote:
 
> <url: http://en.cppreference.com/w/cpp/thread/sleep_for>
 
> Example usage,
 
> sleep_for( 2s );
 
Of course you are right.
 
Depending on the versions of his tools and libraries, he might not have
a C++11 threading implementation. But it should be the first thing to try.
Manfred <noname@invalid.add>: May 31 03:53PM +0200

On 5/31/2018 7:50 AM, bintom wrote:
> }
 
> int main()
> { Blink("Message"); }
 
Besides the loop counting problem, the above code doesn't display
anything on my terminal, due to the lack of any std::flush usage.
Moreover, the amount of '\b' outputs should match the message length.
 
More generally, text decoration is not really part of the language (and
I think it shouldn't); C++ inherits the very basic text rendering
features of C, which do not include things like blinking.
This sort of things falls more properly into the category of either
text-based or GUI-based text rendering.
 
If working with gcc (or other compiler that supports the \e escape
sequence) and an ECMA-48[*] compliant terminal (thanks to
https://stackoverflow.com/questions/26522542/nesting-text-decoration-using-vt100-escape-sequences)
the following will do (it is C code, but that's irrelevant here):
 
/* ----------------------------- */
#include <stdio.h>
 
int main()
{
puts("foo \e[05mbar\e[25m baz\e[m");
}
/* ----------------------------- */
 
Examples of terminals that will show the above properly include xterm
and putty, I didn't try any Windows native terminal.
 
Thanks to the OP, that re-awakened my curiosity about text-decorations
in terminal output.
 
[*]
https://www.ecma-international.org/publications/standards/Ecma-048.htm
bintom <binoythomas1108@gmail.com>: May 31 07:03AM -0700

On Thursday, May 31, 2018 at 1:03:21 PM UTC+5:30, David Brown wrote:
> > }
 
> > int main()
> > { Blink("Message"); }
 
Thanks to the guidance from the group, I found the Sleep() function in windows.h that does what I need.
bintom <binoythomas1108@gmail.com>: May 31 07:04AM -0700

On Thursday, May 31, 2018 at 1:23:25 PM UTC+5:30, Alf P. Steinbach wrote:
 
> sleep_for( 2s );
 
> Cheers!,
 
> - Alf
 
Dev C++, which we use does not support sleep_for() but I found Sleep() from windows.h which does the job. Thanks.
David Brown <david.brown@hesbynett.no>: May 31 04:13PM +0200

On 31/05/18 16:04, bintom wrote:
 
>> - Alf
 
> Dev C++, which we use does not support sleep_for() but I found
> Sleep() from windows.h which does the job. Thanks.
 
Dev C++ is an IDE, not a compiler - it supports whatever compiler you
want, with whatever options you want, whatever libraries you want and
whatever standards you want (though it has a preference for gcc
compilers, I believe).
 
If you are using an older compiler, or not enabling C++11 (or newer)
standards, then you won't have sleep_for(). You might conceivably have
tools that support C++11 in general, but not all of the C++11 libraries.
 
Unless you have very good reasons not to (and programmer knowledge and
experience might be a good reason), I'd recommend using at least C++11
standard for new code - it is a significant step up in the language.
Jorgen Grahn <grahn+nntp@snipabacken.se>: May 31 02:43PM

On Thu, 2018-05-31, David Brown wrote:
...
> Unless you have very good reasons not to (and programmer knowledge and
> experience might be a good reason), I'd recommend using at least C++11
> standard for new code - it is a significant step up in the language.
 
I don't think not knowing all of C++11 is a reason to tell the
compiler to use C++98. I don't know all of C++98 either ...
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Öö Tiib" <ootiib@hot.ee>: May 31 08:34AM -0700

On Thursday, 31 May 2018 17:13:36 UTC+3, David Brown wrote:
> want, with whatever options you want, whatever libraries you want and
> whatever standards you want (though it has a preference for gcc
> compilers, I believe).
 
That is ideal talk about normal IDE. ;) Just like it is tricky to
integrate something but Apple-approved-LLVM stuff into X-Code it is
tricky to integrate something but that outdated version of MinGW gcc
into that Dev C++.
 
 
> Unless you have very good reasons not to (and programmer knowledge and
> experience might be a good reason), I'd recommend using at least C++11
> standard for new code - it is a significant step up in the language.
 
There are number of other 0 price IDEs that are easier to deal with.
Eclipse CDT, NetBeans, Qt creator, even free vesions of MS VS are
relatively easy to to deal with. But one who has picked Dev C++ or
Code::Blocks should first just dump it if they want to use modern
compilers IMHO, YMMV.
woodbrian77@gmail.com: May 31 11:11AM -0700

On Thursday, May 31, 2018 at 9:43:34 AM UTC-5, Jorgen Grahn wrote:
> > standard for new code - it is a significant step up in the language.
 
> I don't think not knowing all of C++11 is a reason to tell the
> compiler to use C++98. I don't know all of C++98 either ...
 
Agreed. There's also an increasing amount of software
that you won't be to use if you don't take steps toward
2011 ++C. That includes code from an online code generator
that has been mentioned here previously.
 
 
Brian
Ebenezer Enterprises - Enjoying programming again.
https://github.com/Ebenezer-group/onwards
scott@slp53.sl.home (Scott Lurndal): May 31 06:29PM


>Agreed. There's also an increasing amount of software
>that you won't be to use if you don't take steps toward
>2011 ++C.
 
Actually, that precludes the use of such software in many cases
where moving to a newer compiler isn't feasible.
 
On-line code generators aren't a viable solution - who wants to
be dependent upon a third-party that may disappear tomorrow?
David Brown <david.brown@hesbynett.no>: May 31 08:53PM +0200

On 31/05/18 20:29, Scott Lurndal wrote:
> where moving to a newer compiler isn't feasible.
 
> On-line code generators aren't a viable solution - who wants to
> be dependent upon a third-party that may disappear tomorrow?
 
I have only dealt with one on-line code generator (for making customised
SDK's for a family of microcontrollers), and I agree entirely. I'd
rather have a large download giving a big, fat tree of all the files for
all the devices in the family - so that I can pick the ones I want, when
I want, copy them, compare them, archive them.
Ralf Goertz <me@myprovider.invalid>: May 31 02:55PM +0200

Hi,
 
I have a problem with a program implementing the backtracking algorithm
shown in <https://en.wikipedia.org/wiki/Backtracking>. Everything is
fine except for the fact that the program seems to be leaking. I use a
variant of the algorithm that finds all solutions (find_all=true). In my
case the memory usage still increases considerably although I already
found solutions and accordingly recursion_depth stays at or below its
maximum value of 65. According to my understanding this shouldn't
happen. The relevant snippets are:
 
struct BT {
…
void bt() { //the bt "procedure" from wikipedia
++recursion_depth; //global variable
static bool found(false);
if (reject()) {
--recursion_depth;
return;
}
if (accept()) {
found=true;
output();
if (find_all) solutions.push_back(state);
--recursion_depth;
return;
}
BT s=first();
while (s.isValid) {
s.bt();
if (found && ! find_all) break;
s.next();
}
--recursion_depth;
}
BT first() {
BT result(*this);
//modify result
return result;
}
bool accept();
bool reject();
void next();
}
 
first() creates a copy of its class variable, modifies it and returns
the copy by value. The variable "result" goes out of scope and gets
destroyed. In bt() the copy is assigned to s and then s itself calls
bt(). But s also gets destroyed when bt() returns. So where does the
leaking come from? (solutions.push_back() is not the problem, memory
gets consumed even though no new solutions are found.) Is it a problem
inherent to recursion?
Barry Schwarz <schwarzb@dqel.com>: May 31 09:13AM -0700

On Thu, 31 May 2018 14:55:50 +0200, Ralf Goertz
>found solutions and accordingly recursion_depth stays at or below its
>maximum value of 65. According to my understanding this shouldn't
>happen. The relevant snippets are:
 
If you don't where or why the problem is occurring, then what is your
basis for deciding what is relevant? We need to see a complete
compilable example that demonstrates the problem. We don't need all
the internal details. If your sample exhibits the undesired behavior,
we have enough. The code you showed for first() is a suitable stub
for the function details we don't need and can be used as a template
for accept, reject, isValid, etc. We also need to see the actual
constructor for BT
 
I don't know if it is related or not but only one copy of a member
function exists, not a new copy for each class object. Consequently,
the variable found is common to all the objects and is initialized
before program execution begins. Once set to true, it is never set
back to false.
 
--
Remove del for email
Paavo Helde <myfirstname@osa.pri.ee>: May 31 09:25PM +0300

On 31.05.2018 15:55, Ralf Goertz wrote:
> leaking come from? (solutions.push_back() is not the problem, memory
> gets consumed even though no new solutions are found.) Is it a problem
> inherent to recursion?
 
If you don't have a new (or malloc;-S) in your program then you cannot
have a memory leak in the classical sense that the memory is lost and
cannot be freed. You can have accumulation of data somewhere where it
should not be.
 
You can also see an effect of memory fragmentation. In case of memory
fragmentation the apparent memory growth should eventually slow down and
approach a more or less stable level. However, if you have no explicit
dynamic allocations in your code you probably won't have memory
fragmentation either.
 
In recursive programs what takes memory is the stack, but if you say the
recursion depth is limited then it should not grow either.
 
So I guess there is either a bug in the code you did not show, or a bug
in the compiler related to recursion (very unlikely).
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)