Tuesday, February 13, 2018

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

G B <gb@gb.com>: Feb 13 01:35AM

Who can provide a two or three liner code in C or C++ to create a clock
like the one shown in this video?
 
<https://youtu.be/SVxcpL4AJGs>
 
Please watch it is full screen to know what I am asking about.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Feb 13 02:02AM


> Who can provide a two or three liner code in C or C++ to create a
 
Cross posting between C and C++ can lead to some... disagreements. I
read this in comp.lang.c first and my answer pertains to C.
 
> clock like the one shown in this video?
 
> <https://youtu.be/SVxcpL4AJGs>
 
For the time part, lookup the functions time, localtime and strftime in
whatever C reference you like to use.
 
For the output part, lookup fputs (or printf), fflush and the meaning of
the special character denoted by the escape sequence \r.
 
Enough hints? (I'm avoiding spoilers because I'm guessing this is some
sort of homework or assignment, and if not, at least some challenge
you've set for yourself.)
 
--
Ben.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 13 03:53AM +0100

On 13.02.2018 03:02, Ben Bacarisse wrote:
 
> Enough hints? (I'm avoiding spoilers because I'm guessing this is some
> sort of homework or assignment, and if not, at least some challenge
> you've set for yourself.)
 
In addition toe Ben's hints, check out `std::this_thread` for means to
avoid using all too much CPU time.
 
Cheers & hth.,
 
- Alf
bartc <bc@freeuk.com>: Feb 13 11:50AM

On 13/02/2018 01:35, G B wrote:
> like the one shown in this video?
 
> <https://youtu.be/SVxcpL4AJGs>
 
> Please watch it is full screen to know what I am asking about.
 
Why does it have to be 3 lines?
 
Anyway this is something I tried in Windows, to do the kind of display
shown in the video. I couldn't be bothered dealing with actual time:
 
#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
 
int main(void) {
int n=0;
 
system("cls");
 
while (1) {
printf("%d\r",n);
++n;
Sleep(1000);
}
}
 
 
(This assumes the value being displayed will never get shorter. It will
do eventually but it will be decades hence. A time display however will
be probably always be the same width.)
 
--
bartc
Egor <egor@ruby.local>: Feb 13 01:56PM +0200

> Who can provide a two or three liner code in C or C++ to create a clock
> like the one shown in this video?
 
Here's how it's done on windows. If you need a different time format
you'll need to use localtime and strftime.
 
#include <stdio.h>
#include <time.h>
#include <windows.h>
int main() {
for(;;) {
time_t t = time(NULL);
char *str = ctime(&t);
str[24] = '\0'; /* remove the newline from string */
printf("\r%s", str);
fflush(stdout);
Sleep(500);
}
}
 
To sleep on unix, use the following code (requires time.h):
struct timespec ts;
ts.tv_sec = 0;
ts.tv_nsec = 500000000L; /* 500 million ns = 500 ms */
nanosleep(&ts, NULL);
"Öö Tiib" <ootiib@hot.ee>: Feb 13 12:49PM -0800

On Tuesday, 13 February 2018 03:29:17 UTC+2, G B wrote:
> like the one shown in this video?
 
> <https://youtu.be/SVxcpL4AJGs>
 
> Please watch it is full screen to know what I am asking about.
 
Who needs C or C++ for task like that?
Make a clock.bat file, something like that perhaps:
 
@echo off
setlocal enableextensions enabledelayedexpansion
for /F %%a in ('echo prompt $H ^| cmd') do set "BS=%%a"
:loop
timeout /t 1 > nul
set /p "=%date% %time%!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!
 
BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!!BS!" <NUL
goto loop
 
 
Then run it.
legalize+jeeves@mail.xmission.com (Richard): Feb 13 09:34PM

[Please do not mail me a copy of your followup]
 
bartc <bc@freeuk.com> spake the secret code
 
> system("cls");
 
If you watch the video, it doesn't clear the screen.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
bartc <bc@freeuk.com>: Feb 13 10:01PM

On 13/02/2018 21:34, Richard wrote:
> <fiAgC.671$3X6.107@fx22.am4> thusly:
 
>> system("cls");
 
> If you watch the video, it doesn't clear the screen.
 
Well, the screen was cleared at one point, if not by the program.
Perhaps the OP wanted the screen cleared completely and didn't know how.
 
Anyway it's an easy fix; just delete that line.
 
--
bartc
William Ahern <william@25thandClement.com>: Feb 12 07:28PM -0800


> Unicode has been spiraling out of control. Looks like their end goal
> is setting mankind 4000 years back.
 
> https://en.wikipedia.org/wiki/Egyptian_hieroglyphs
 
I think their end goal is relevance, not so much natural language relevance
as technical relevance. The emoji phenomenon has, probably more than any
other single factor, motivated the adoption and maintenance of proper
Unicode text support at both the platform and application layers.
 
Executives, managers, and engineers who once only paid lip service to I18N
support were feverishly concerned with supporting emoji, addressing alot of
lingering technical debt up and down the software stack. It was Apple and
Google who pushed Unicode to establish a process for incorporating emoji. As
a technical matter supporting emoji is first and foremost a matter of text
processing, which as a practical matter is for them equivalent to matters of
Unicode and UTF-8 processing. American companies were never invested in
Asian encodings like Shift JIS, which I think is where emoji first emerged.
The upshot is that American companies had more to lose from a fragmented
I18N ecosystem compared to Japanese companies more accustomed to such
complexity.
 
Where emoji goes so too go vendors and developers. If the Unicode Consortium
doesn't own emoji, there'll be a de facto fork of Unicode as a standard and
as an ecosystem. (Similar to WHATWG snatching HTML away from W3C.) Before
Unicode began officially incorporating emoji an industry standard was
emerging around glyphs assigned within the private use range. I think
Unicode is still making up for lost ground in that regard.
Lynn McGuire <lynnmcguire5@gmail.com>: Feb 13 01:50PM -0600

On 2/12/2018 9:28 PM, William Ahern wrote:
> Unicode began officially incorporating emoji an industry standard was
> emerging around glyphs assigned within the private use range. I think
> Unicode is still making up for lost ground in that regard.
 
So the xkcd war analogy is appropriate. Interesting.
 
Thanks,
Lynn
wij@totalbb.net.tw: Feb 12 08:38PM -0800

The compiled program dosn't indicate sin2 is the same as ::sin
 
---------- file.cpp ---------
#include <iostream>
#include <cmath>
 
inline __attribute__((always_inline))
double sin2(double x) { return ::sin(x); }
 
int main()
{
std::cout << (void*)::sin << std::endl;
std::cout << (void*)sin2 << std::endl;
return 0;
}
-----------------------------
 
$ g++ file.cpp
$ ./a.out
0x400680
0x40085d
 
Why is that? How to fix it?
Ian Collins <ian-news@hotmail.com>: Feb 13 06:40PM +1300

> 0x400680
> 0x40085d
 
> Why is that? How to fix it?
 
Nothing is broken - you can't take the address of something that has
been inlined. Even if it were, gcc won't inline functions without
optimisation enabled.
 
--
Ian.
Christian Gollwitzer <auriocus@gmx.de>: Feb 13 06:45AM +0100

> 0x400680
> 0x40085d
 
> Why is that? How to fix it?
 
Because you are taking the address of it. The address will always be
different and no indicator for inlining. If you want to check inlining,
you should check the assembly output of code invoking the function (-S
switch)
 
Furthermore, if you compile with optimizations, the call to "sin" might
decay into a special instruction depending on your platform, with no
"call" instruction visible at all.
 
If you want to create a symbol alias, use "using".

 
Christian
Juha Nieminen <nospam@thanks.invalid>: Feb 13 07:00AM

> The compiled program dosn't indicate sin2 is the same as ::sin
 
Firstly, 'inline' is a linker instruction, and nowadays has nothing to do
with actual inlining, as strange as it might sound. (It tells the compiler
that if the implementation of the function appears in more than one
compilation unit, ie. more than one object file, for the linker to merge
them, ie. use only one of them and make everything call that one.)
It might have affected compiler behavior in terms of actual inlining
in the distant past, but nowadays most compilers probably just ignore
it completely when making inlining decisions.
 
Secondly, taking the address of an "inline" function will create an
actual instance of the function, because the address to that function
has to point somewhere, and it has to be unique. (Although I could be
talking out of my ass here, since I don't know what the standard says
about inline functions and taking their addresses.) However, just
because you took the address of the function, forcing the compiler
to actually instantiate it, that doesn't stop the compiler from
still inlining it. The implementation of the function could exist
in the final executable, yet it could have still been inlined
everywhere where it was called. So execution never actually jumps
to the function. It's just that when you took the address, it has
to point somewhere that actually exists. It has to be able to use
that address (eg. to print it).
David Brown <david.brown@hesbynett.no>: Feb 13 09:25AM +0100

On 13/02/18 06:40, Ian Collins wrote:
 
> Nothing is broken - you can't take the address of something that has
> been inlined. Even if it were, gcc won't inline functions without
> optimisation enabled.
 
gcc /will/ inline functions that have __attribute__((always_inline)),
even without optimisations enabled.
 
But of course it can't inline a function when you take the address of
that function. (It will still inline calls to sin2 from elsewhere in
the code.)
David Brown <david.brown@hesbynett.no>: Feb 13 09:39AM +0100

On 13/02/18 08:00, Juha Nieminen wrote:
> It might have affected compiler behavior in terms of actual inlining
> in the distant past, but nowadays most compilers probably just ignore
> it completely when making inlining decisions.
 
That is a somewhat true, but not entirely accurate. If a non-static
function (or variable, in C++17) is marked "inline" then you can have
more than one definition for the function in different translation units
in the program, but they must all be identical. If the function's
address is taken, you get the same address in all translation units.
 
It does not mean that the function must be inlined - but many compilers
take it as a strong hint that the function should be inlined, depending
on optimisation levels. It is common not to do any inlining when using
no optimisation, to treat it as a hint when doing some optimisation, and
to ignore it for heavy optimisation (when the compiler does much more
analysis). The gcc attribute "always_inline", however, tells the
compiler to inline the function whenever it is legally possible.
 
If the compiler does not need a non-inlined version of the function
(because all calls in the current translation unit get inlined, and you
don't take its address), then it does not need to generate the
non-inlined version, even if the function has external linkage.
 
> has to point somewhere, and it has to be unique. (Although I could be
> talking out of my ass here, since I don't know what the standard says
> about inline functions and taking their addresses.)
 
AFAIK, you are correct here.
 
> because you took the address of the function, forcing the compiler
> to actually instantiate it, that doesn't stop the compiler from
> still inlining it.
 
Correct. The compiler can inline some uses of the function while using
a non-inlined version in other cases.
 
> to the function. It's just that when you took the address, it has
> to point somewhere that actually exists. It has to be able to use
> that address (eg. to print it).
 
(I think technically that the compiler does not have to generate a
non-inlined version even if you have taken its address - if the compiler
is sure you never call it via that address, such as in this sample
program. All that is needed then is the program-wide unique address,
not the function implementation. But I think that would take a lot of
sophistication and link-time optimisation to achieve.)
Paavo Helde <myfirstname@osa.pri.ee>: Feb 13 03:15PM +0200

> std::cout << (void*)sin2 << std::endl;
> return 0;
> }
 
While others have explained why the addresses appear different, I would
also like to add a remark that inlining is most probably irrelevant for
such a function (taking a single argument and calling sin()). This is
because sine calculation is a pretty heavyweight operation, so any
potential performance gain from inlining would probably turn out
unmeasurable.
 
Of course, if you want to put that function in a header then inline is
needed for avoiding linker errors. But this has actually nothing to do
with inlining.
 
hth
Paavo
David Brown <david.brown@hesbynett.no>: Feb 13 02:30PM +0100

On 13/02/18 14:15, Paavo Helde wrote:
> because sine calculation is a pretty heavyweight operation, so any
> potential performance gain from inlining would probably turn out
> unmeasurable.
 
It is a good point to consider - certainly if you are thinking of
"inline" to improve speed, you need to look at the bigger picture.
However, it is not quite as simple as you suggest here.
 
First - clearly you need to enable optimisation if you are at all
concerned about performance. And if floating point performance is
important, "-ffast-math" can make a big difference.
 
Secondly, inlined code (whether due to "inline", or by making the
function "static" and letting the compiler figure it out) can have other
optimisation effects. Even if the call to the library sin() function
(or x86 sin opcode, which may or may not be faster) takes longer, having
the code inlined lets the compiler re-arrange instructions around the
calculation. The sine calculation may take 100 clock cycles - but
fetching of data from main memory can twice that, and inlining may let
the compiler start a fetch while the calculation is in progress.
 
 
> Of course, if you want to put that function in a header then inline is
> needed for avoiding linker errors. But this has actually nothing to do
> with inlining.
 
It is also best to make it "static inline", rather than just "inline".
You don't actually want it to be a symbol with external linkage.
"James R. Kuyper" <jameskuyper@verizon.net>: Feb 13 11:33AM -0500

> #include <cmath>
 
> inline __attribute__((always_inline))
> double sin2(double x) { return ::sin(x); }
 
Note: ::sin() is declared in <math.h>; <cmath> declares std::sin(). That
your code compiled successfully implies that <cmath> also declares
::sin(), but that is not required by the standard, and you shouldn't
write code that depends upon it.
 
> int main()
> {
> std::cout << (void*)::sin << std::endl;
 
Only pointers to object types can be converted to (void*) with defined
behavior.
 
> std::cout << (void*)sin2 << std::endl;
 
What you can do, instead of printing out those pointers, is simply
indicate whether they compare equal:
 
std::cout << (sin2 == ::sin) << std::endl;
 
> 0x400680
> 0x40085d
 
> Why is that? How to fix it?
 
Others have told you that you can't inline functions that you've taken
the address of. That's not quite the right way to describe the problem.
The problem is that an inlined function doesn't have an address, so if
you request the address of an inlined function, by that very act, you
are also requesting that the compiler generate an actual function that
the address can point to. This doesn't prevent calls to sin2() from
being inlined, and they probably will be, because gcc promises so when
you use the always_inlined attribute.
 
sin2() is a separate function from ::sin(), regardless of inlining. You
seem to have been expecting the compiler to notice that sin2() happens
to be a complete wrapper for ::sin(), and therefore equivalent to it.
That's not how it works.
If you want sin2 to be an expression that points to the same function as
::sin, that's easy to arrange:
 
auto const sin2 = ::sin;
Paavo Helde <myfirstname@osa.pri.ee>: Feb 13 06:49PM +0200

On 13.02.2018 15:30, David Brown wrote:
 
> calculation. The sine calculation may take 100 clock cycles - but
> fetching of data from main memory can twice that, and inlining may let
> the compiler start a fetch while the calculation is in progress.
 
Point taken.
 
 
> It is also best to make it "static inline", rather than just "inline".
> You don't actually want it to be a symbol with external linkage.
 
I have understood that "static" is not needed for inlining to happen,
isn't this so? The compiler can both inline the function and generate an
external linkage version of it as well (which may be later discarded by
the linker if it is not used).
 
And should we not prefer anonymous namespace to static in C++?
 
cheers
paavo
Christiano <christiano@engineer.com>: Feb 13 12:43AM -0200

See the following statement:
std::cout << "\105ba" << std::endl;
 
In the ascii table 105 octal means 'E', so the result is: "Eba"
 
I want to do the same thing using hexadecimal escape sequence
 
std::cout << "\x45ba" << std::endl;
 
And the result is:
 
$ CC a.cpp
a.cpp:7:16: error: hex escape sequence out of range
std::cout << "\x45ba" << std::endl;
^~~~~~
1 error generated.
 
The book C++ Primer Fifth edition - Stanley Lippman - in the page 39 says:
 
""""" C++ Primer 5th, page 39 """""""""""""""""""""""""""""""""
"We can also write a generalized escape sequence , which is \x followed
by one or more hexadecimal digits or a \ followed be one, two, or three
octal digits. The value represents the numerical value of the character."
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
My question is:
How can I write the sequence \x45 + b + a ("Eba") without the compiler
understanding 'b' and 'a' as hexadecimal characters ?
 
In Octal this problem doesn't exist, example:
std::cout << "\10510" << std::endl;
will print "E10", that is, '1'+'0' will not be interpreted as octal
characters.
Reinhardt Behm <rbehm@hushmail.com>: Feb 13 10:48AM +0800

AT Tuesday 13 February 2018 10:43, Christiano wrote:
 
> std::cout << "\10510" << std::endl;
> will print "E10", that is, '1'+'0' will not be interpreted as octal
> characters.
 
write it as "\x45" "ba" (not tested)
 
--
Reinhardt
Christiano <christiano@engineer.com>: Feb 13 12:55AM -0200

On 02/13/2018 00:48, Reinhardt Behm wrote:
>> will print "E10", that is, '1'+'0' will not be interpreted as octal
>> characters.
 
> write it as "\x45" "ba" (not tested)
 
It works.
std::cout << "\x45""ba" << std::endl;
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)