Monday, September 14, 2015

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

bleachbot <bleachbot@httrack.com>: Sep 15 12:01AM +0200

bleachbot <bleachbot@httrack.com>: Sep 15 12:09AM +0200

Ramine <ramine@1.1>: Sep 14 06:02PM -0700

Hello....
 
 
Please read the following about our future, it`s very interesting...
 
 
The AI Revolution: The Road to Superintelligence
 
Read here:
 
http://waitbutwhy.com/2015/01/artificial-intelligence-revolution-1.html
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Sep 14 06:10PM -0700

Hello...
 
 
And here is the part 2:
 
Read here:
 
http://waitbutwhy.com/2015/01/artificial-intelligence-revolution-2.html
 
 
Thank you,
Amine Moulay Ramdane.
mark <mark@invalid.invalid>: Sep 14 08:17PM +0200

I'm using a C library that is using void** arrays (array of pointers to
a struct).
 
Something like:
 
typedef struct {
void** data;
unsigned int length;
} Vector;
 
typedef struct {
...
} S1;
 
typedef struct {
...
} S2;
 
Vector::data is an array of S1* or S2*.
 
Is it safe to cast Vector::data to S1** / S2**?
Victor Bazarov <v.bazarov@comcast.invalid>: Sep 14 02:22PM -0400

On 9/14/2015 2:17 PM, mark wrote:
> } S2;
 
> Vector::data is an array of S1* or S2*.
 
> Is it safe to cast Vector::data to S1** / S2**?
 
Generally, no.
 
Are you required to be source-code compatible with C? If not, don't use
this stuff. Consider standard containers.
 
V
--
I do not respond to top-posted replies, please don't ask
mark <mark@invalid.invalid>: Sep 14 08:26PM +0200

On 2015-09-14 20:22, Victor Bazarov wrote:
 
> Generally, no.
 
> Are you required to be source-code compatible with C? If not, don't use
> this stuff. Consider standard containers.
 
I'm stuck with using that C library. Converting the data structures to
C++ ones is not an option.
 
How unsafe is it?
mark <mark@invalid.invalid>: Sep 14 08:37PM +0200

On 2015-09-14 20:26, mark wrote:
 
> I'm stuck with using that C library. Converting the data structures to
> C++ ones is not an option.
 
> How unsafe is it?
 
To clarify, it would be good enough if it is semi-portable to platforms
where sizeof(char*) == sizeof(int*) == sizeof(void*) == sizeof(S1*).
Luca Risolia <luca.risolia@linux-projects.org>: Sep 14 08:49PM +0200

Il 14/09/2015 20:26, mark ha scritto:
>>> Is it safe to cast Vector::data to S1** / S2**?
 
 
> How unsafe is it?
 
Different types may be aligned to different boundaries. Unless you know
what the original type being pointed is, accessing data members via such
casted pointers may crash your program (if you are lucky).
Martin Shobe <martin.shobe@yahoo.com>: Sep 14 02:17PM -0500

On 9/14/2015 1:17 PM, mark wrote:
> } S2;
 
> Vector::data is an array of S1* or S2*.
 
> Is it safe to cast Vector::data to S1** / S2**?
 
Technically no. Even getting data to point to an array of S1* or S2* is
already a problem. However, chances are if it works in that direction,
it will work in reverse and I don't see any better options. (Assuming
you can't fix the C library.)
 
Martin Shobe
Paavo Helde <myfirstname@osa.pri.ee>: Sep 14 03:08PM -0500


> To clarify, it would be good enough if it is semi-portable to
> platforms where sizeof(char*) == sizeof(int*) == sizeof(void*) ==
> sizeof(S1*).
 
In this case there is a good chance it might work. Maybe the C library is
itself already stepping over the line and using unportable casts, if so,
then there is not much point to avoid them in your code.
 
Cheers
Paavo
Christian Gollwitzer <auriocus@gmx.de>: Sep 14 08:09AM +0200

Am 13.09.15 um 22:13 schrieb mark:
 
> I don't think there is a 'sane' possibility. But, you if you don't care
> about sanity, you can evaluate a taylor series as constexpr:
> http://prosepoetrycode.potterpcs.net/2015/07/more-fun-with-constexpr/
 
A comment to this: it's fun to see how templates can be abused to
compute the cosine series. However you should be aware that there might
be precision problems. Serious implementations of trigonometric
functions can be precise to the last digit in floating point, but they
don't use the Taylor expansion, instead a minmax approximation is used.
cephes on netlib contains many special functions as pure C code, which
could probably be converted to constexpr.
 
http://www.netlib.org/cephes/cmath.tgz
 
sin and cos in double precision are here:
 
https://github.com/jeremybarnes/cephes/blob/master/cmath/sin.c
 
 
Christian
Nobody <nobody@nowhere.invalid>: Sep 14 08:14AM +0100

On Sun, 13 Sep 2015 22:13:21 +0200, mark wrote:
 
>> math functions like sin, cos?
 
> I don't think there is a 'sane' possibility. But, you if you don't care
> about sanity, you can evaluate a taylor series as constexpr:
 
Another option is a recursive approach based upon the sum/difference
formulae and half-angle formulae.
 
Corollary: for angles of the form pi*i/(2^n) where i and n are
integers (aka Binary Angular Measurements or BAMs for short), the sine,
cosine and tangent of such angles aren't transcendental but constructible,
i.e. can be evaluated using only +, -, *, / and sqrt(). Thus it's possible
to determine the nearest representable value using only rational
arithmetic (so no "table-maker's dilemma").
David Brown <david.brown@hesbynett.no>: Sep 14 09:59AM +0200

On 13/09/15 23:54, K. Frank wrote:
> evaluated at run time. (Although they should be equal
> up to some reasonable round-off error, where "reasonable"
> is a quality-of-implementation issue).
 
There /is/ a way to handle this - the compiler can have libraries that
emulate the target details. gcc (since 4.5) has used a library to do
this, and will happily and confidently handle constant compile-time
evaluation of floating point operations, and including transcendental
ones, including cross-compilation.
 
To help matters, if you are looking for "fast and correct for normal
code" rather than "follow IEEE to the letter and the last bit", you can
use the "-ffast-math" flag to tell gcc not to worry /too/ much about
such details. Other compilers may have something similar.
 
Christian Gollwitzer <auriocus@gmx.de>: Sep 14 09:20PM +0200

Am 14.09.15 um 09:14 schrieb Nobody:
>> about sanity, you can evaluate a taylor series as constexpr:
 
> Another option is a recursive approach based upon the sum/difference
> formulae and half-angle formulae.
 
which is usually called the CORDIC algorithm. It is simple enough to be
implemented in hardware (pocket calculators), but inferior in speed if a
fast multiplier is available. Of course, for compile-time copmutation
speed is probably the least important
 
https://en.wikipedia.org/wiki/CORDIC
 
Christian
scott@slp53.sl.home (Scott Lurndal): Sep 14 01:23PM

> int a;
> void change() { a = 5; }
>};
 
$ cat /tmp/a.c
 
struct A { int a; void change(void) { a = 5; } };
 
int main(int argc, const char **argv, const char **envp)
{
A a;
 
a.change();
 
return 0;
}
 
00000000004005d6 <A::change()>:
4005d6: 55 push %rbp
4005d7: 48 89 e5 mov %rsp,%rbp
4005da: 48 89 7d f8 mov %rdi,-0x8(%rbp)
4005de: 48 8b 45 f8 mov -0x8(%rbp),%rax
4005e2: c7 00 05 00 00 00 movl $0x5,(%rax)
4005e8: 5d pop %rbp
4005e9: c3 retq
4005ea: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
 
> X x;
> void change() { x.a = 5; }
>};
 
$ cat /tmp/a.c
 
struct X { int a; };
 
struct A { X x; void change(void) { x.a = 5; } };
 
int main(int argc, const char **argv, const char **envp)
{
A a;
 
a.change();
 
return 0;
}
 
00000000004005d6 <A::change()>:
4005d6: 55 push %rbp
4005d7: 48 89 e5 mov %rsp,%rbp
4005da: 48 89 7d f8 mov %rdi,-0x8(%rbp)
4005de: 48 8b 45 f8 mov -0x8(%rbp),%rax
4005e2: c7 00 05 00 00 00 movl $0x5,(%rax)
4005e8: 5d pop %rbp
4005e9: c3 retq
4005ea: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
 
 
Both varieties generate identical code.
JiiPee <no@notvalid.com>: Sep 14 06:24PM +0100

On 14/09/2015 14:23, Scott Lurndal wrote:
> JiiPee <no@notvalid.com> writes:
> Both varieties generate identical code.
 
thanks very much. I hope I learn to do this one day :). This is what I
wanted.... the fact about it, and there it is. So I guess we can
continue coding with good structures without fear of losing speed.
legalize+jeeves@mail.xmission.com (Richard): Sep 14 04:30PM

[Please do not mail me a copy of your followup]
 
Anand Hariharan <mailto.anand.hariharan@gmail.com> spake the secret code
 
>Imagine a legacy C code base that was strewn with 'gets' and 'asctime'.
>Would you not give the same advice? (Agreed the effort required in your
>case would be significantly more.)
 
For performing automated transformations on large code bases, I
recommend using the clang tooling infrastructure to create a custom
tool that performs the exact transformation you need.
 
"Large code base" in this instance means certainly more than a hundred
instances of the transformation to be applied. Depending on the
difficulty of the transformation (i.e. something where a simple
find/replace won't work), it can be worth making a custom tool for it.
 
If you wish to pursue this, look at my talk from C++ Now! 2014
"Create Your Own Refactoring Tool with Clang"
<https://github.com/boostcon/cppnow_presentations_2014>
<https://www.youtube.com/watch?v=8PndHo7jjHk>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Juha Nieminen <nospam@thanks.invalid>: Sep 14 08:21AM


> So we taking about a class for which moving is relatively expensive.
> And this is exactly the case when we want to avoid relocation.
> ;-)
 
If one is extremely worried about reallocations, then one can use
std::deque instead of std::vector.
 
No deallocations, but still a lot more efficient than a linked list.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
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)