Tuesday, October 3, 2017

Digest for comp.lang.c++@googlegroups.com - 25 updates in 9 topics

asetofsymbols@gmail.com: Oct 03 11:56AM -0700

Is it possible write a double linked list, with type not the same?
 
Example
[1, "this", 1.23, [1,2,3], []]
asetofsymbols@gmail.com: Oct 03 11:59AM -0700

I have as the impression that the only implementation possible it is a double linked list where the node has a char*, pointed where store the different type element...
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 03 08:04PM +0100

On Tue, 3 Oct 2017 11:56:31 -0700 (PDT)
> Is it possible write a double linked list, with type not the same?
 
> Example
> [1, "this", 1.23, [1,2,3], []]
 
With C++17 you can use std::variant. Otherwise you are probably going
to have to implement your own hack with unions or using pointers with
run-time type introspection.
Jerry Stuckle <jstucklex@attglobal.net>: Oct 03 03:23PM -0400

On 10/3/2017 3:04 PM, Chris Vine wrote:
 
> With C++17 you can use std::variant. Otherwise you are probably going
> to have to implement your own hack with unions or using pointers with
> run-time type introspection.
 
Or create different classes derived from the same base class.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
"Öö Tiib" <ootiib@hot.ee>: Oct 03 01:59PM -0700

On Tuesday, 3 October 2017 22:04:39 UTC+3, Chris Vine wrote:
 
> With C++17 you can use std::variant. Otherwise you are probably going
> to have to implement your own hack with unions or using pointers with
> run-time type introspection.
 
With C++98 the linked lists were as rarely useful as these are
now. If one needed variant in C++ then it was usually better to
use some variant from library (like for example boost::variant or
QVariant) instead of hacking unions.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 03 10:23PM +0100

On Tue, 3 Oct 2017 15:23:48 -0400
> > going to have to implement your own hack with unions or using
> > pointers with run-time type introspection.
 
> Or create different classes derived from the same base class.
 
That would do it, although I guess that counts as "pointers with
run-time type introspection" (you have to hold the base type by
reference/pointer to avoid slicing). I try to avoid inheritance where
it doesn't directly model the problem space: but I make an exception
for type erasure, and you are right that it is probably the most
reasonable approach if unions are not suitable and a variant type is
not available.
Jerry Stuckle <jstucklex@attglobal.net>: Oct 03 02:47PM -0400

> it has one bit on or one element ==1
> or it is one value of one range,
> used to indicate that object is result of one error operation
 
You are calling it the wrong thing. It is an fstream object with an
error status.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
asetofsymbols@gmail.com: Oct 03 12:28PM -0700

Ok you are right until I write something that can run...
Possible the first implementation of this error propagation thru object
would be a general linked list in C++ with few function in it.
 
But something begin to be ok
 
f(){
T r;
 
// and the (void) constructor of r
//produce in r the error object
//Now r is the error object
// all obj build using r are error obj
 
r=b
 
// if b is not the error obj than r is ok
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 03 01:48PM +0100

On Tue, 03 Oct 2017 13:26:14 +0300
 
> Whether the result of 8/3 should be an integer or a floating-point
> number is another topic, greatly studied in Python2/Python3 wars if I
> have understood correctly.
 
Ideally the result of 8/3 would be stored as a rational if the
remainder is relevant to the calculation and floating point is not
good enough. Many languages have such an "exact" type built in: C and
C++ do not, although there are libraries available, for example
boost::rational for C++ and mpq in GMP for C.
 
Chris
Manfred <noname@invalid.add>: Oct 03 07:47PM +0200

On 10/3/2017 2:00 AM, Stefan Ram wrote:
> the default behavior in C++?
 
> (Is it possible than processors have instructions to
> truncate, but not to round? And if so, why?)
 
In the context of C++ the quick and simple answer is that this is the
rule of C, so for compatibility C++ follows the same rule.
 
More info could probably come from comp.lang.c, anyway what I would
first note is that truncation (and particularly truncation to zero) is a
trivial operation in binary terms, and implementing rounding based on
truncation is also a trivial operation in C code.
In other words, between truncation and rounding, I would also say
truncation is the "lower level" operation of the two, so having it as
the built-in operation in the language makes some sense.
A more relevant reason would be analogy with integer arithmetic, as fir
noted elsethread:
For n and m integers the integer operation n/m results in a truncated
quotient (and a remainder), so considering e.g. 8.2 as 82/10 would
result in 8 using integer division.
fir <profesor.fir@gmail.com>: Oct 03 11:50AM -0700

W dniu wtorek, 3 października 2017 19:48:09 UTC+2 użytkownik Manfred napisał:
> For n and m integers the integer operation n/m results in a truncated
> quotient (and a remainder), so considering e.g. 8.2 as 82/10 would
> result in 8 using integer division.
 
i must say i dont quite understood what you say i say
(weak english) but probably dont matter
 
rounding should be also easy in binary for example
 
1.1010101
1.0101010
 
.1 is 0.5
.0 is lack of .5
 
 
so
1.1xxx is 2
1.0xxx is 1
 
 
if so rounding dont seem harder,
 
imo there are soem cases where truncating asp truncating towards zero in both pluses and minuses works esp bad bad for example 2d perpixel drawing code below (*)
On other cases hovever just truncating topward zero is most practical (as i said in a calculations that mix integers with floats in general truncating and rounding should not appear as there just promotion to floats mostly works so truncating vs rounding shouldnt be even considered in such context as they both fail so bad) In a pack of normal usage case truncation to zero seems most usefull (becouse it works like that , "i care only for integral part")
 
 
 
*
DrawLine(-.99, -.99, .99, .99)
 
FillRectangle(-.99, -.99, .99, .99)
 
truncating toward zero will collapse rectangle that spans almost 4 piksels to
 
FillRectangle(0, 0, 0, 0)
 
//in general always drawing that crosses x and y axex cuts off just one row and one column of pixels
 
truncating down:
 
FillRectangle(-1, -1, 0, 0)
 
rounding:
 
FillRectangle(-1, -1, 1, 1)
 
 
in such 2d geometry rounding is imo best
fir <profesor.fir@gmail.com>: Oct 03 12:08PM -0700

W dniu wtorek, 3 października 2017 20:50:15 UTC+2 użytkownik fir napisał:
 
> rounding:
 
> FillRectangle(-1, -1, 1, 1)
 
> in such 2d geometry rounding is imo best
 
hovever this last one makes a rectangle that will span 9 piksels, where first makes only one and second makes four,
 
but that depends when you see centres of the pixels,
 
if see 0,0 as a centre between 4 pixels
or if see 0,0 as a centre of one pixel - im closer
to see 0,0 as a centre in pixels if so such
-.9 -.9 t0 .9 .9 rectangle lays on all 9 pixels though only one os fully covered 4 are covered in half and 4 are covered in 1/4, but nine are touched
 
in ce there is round() function afair - i remember in old pentium 4 there was drasrical eeficiency problem related to this as you would need to switch rounding mode of fpu to round butr on ssse i rememver there are special mnemonics that dont need to swich and that means one could use bith truncate and round with not much worry afair
fir <profesor.fir@gmail.com>: Oct 03 12:14PM -0700

W dniu wtorek, 3 października 2017 21:08:38 UTC+2 użytkownik fir napisał:
> or if see 0,0 as a centre of one pixel - im closer
> to see 0,0 as a centre in pixels if so such
> -.9 -.9 t0 .9 .9 rectangle lays on all 9 pixels though only one os fully covered 4 are covered in half and 4 are covered in 1/4, but nine are touched
 
one could also add hat the difference is that c casting is 'conservative' (cuts of all the fractional points) where in 2d graphics drawing is expected to be 'greedy' (even slightly taouched pixel is expected be set)
 
porparek@gmail.com: Oct 03 09:34AM -0700

Hi,
 
I have the following:
std::unordered_set<std::string*>
 
Will it hash by default (C++11 or higher) by address or by string ?
If so, is it the reasonably good solution to use the wrapper for std::hash<std::string> ?
 
thanks for clarification
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Oct 03 06:25PM +0100

On Tue, 3 Oct 2017 09:34:51 -0700 (PDT)
> If so, is it the reasonably good solution to use the wrapper for
> std::hash<std::string> ?
 
> thanks for clarification
 
The hash of a pointer is usually just a reinterpret_cast to std::size_t
(it is in gcc's libstdc++). Hashing by std::string does not look
sensible, but I don't know your use case nor what you want to be
clarified.
scott@slp53.sl.home (Scott Lurndal): Oct 03 01:20PM

>MT-safe std::shared_ptr in a situation which does not require MT-safety
>or shared ownership might indeed be slower than the ideal, but the
>solution is to use a more suitable smartpointer, not to throw them all away!
 
We have an application that has 24 to 96 cpu-bound threads and runs for
several days. Replacing the dogmatic C++ smart pointer style with
a more C style of element management improved performance by 40%, which
cut close to a day off the run time.
scott@slp53.sl.home (Scott Lurndal): Oct 03 01:22PM

>experience of people making stupid mistakes when they use malloc and
>free along with raw pointers directly instead of using standard
>containers and smart pointers.
 
Yet there are thousands of programmers who have successfully written
hundreds of thousands of applications using raw pointers and malloc/free without the
stupid mistakes.
 
Dogma.
Paavo Helde <myfirstname@osa.pri.ee>: Oct 03 06:12PM +0300

On 3.10.2017 16:20, Scott Lurndal wrote:
> several days. Replacing the dogmatic C++ smart pointer style with
> a more C style of element management improved performance by 40%, which
> cut close to a day off the run time.
 
So based on your single negative experience with a single smartpointer
type and a single special massively parallel application you apparently
feel entitled to claim that all smartpointers absolutely kill
performance for all people and for all applications. Sigh.
 
Out of curiosity, was this "dogmatic C++ smart pointer" std::shared_ptr
or a similar multithread-safe one (which involves thread synchronization
at each smartpointer copy)? IOW, was the day lost on needless thread
synchronization or on something else?
 
I am curious because I have been taking great care that our parallel
heavy worker threads only use single-threaded data structures and
single-threaded smart-pointers, with zero thread synchronization during
the active run. Would be good to have some confirmation my efforts are
not wasted.
 
Cheers
Paavo
legalize+jeeves@mail.xmission.com (Richard): Oct 03 05:24PM

[Please do not mail me a copy of your followup]
 
slp53@pacbell.net spake the secret code
>several days. Replacing the dogmatic C++ smart pointer style with
>a more C style of element management improved performance by 40%, which
>cut close to a day off the run time.
 
You seem to equate advice with dogma.
 
Any piece of reasonable advice can be turned into silly usage that is
obviously stupid.
 
It's like turning the advice "owning your own home is a good thing"
into taking out a variable rate mortgage with a massive balloon
payment and servicing that mortgage early on with 90% of your take
home pay. You took a piece of reasonable advice and turned it into a
hell of your own making.
 
The advice is to use smart pointers to declare explicitly who owns the
heap memory. Does that mean slavishly use shared_ptr every time you
pass one of these pointers around? No, and in fact, that's a bad idea
for performance, particularly if you didn't use make_shared to
construct the pointers in the first place. Passing around
shared_ptr<T> should be used to emphasize changing ownership. If you
just need access to the data, pass a plain pointer or a reference.
 
I once worked on a team that insisted that the arguments of deep call
chains should all be shared_ptr instead of just the raw pointer.
This resulted in lots of wasted time being spent incrementing and
decrementing the reference count, even though the called functions
didn't own any of the data they were being given. If make_shared
wasn't used to created these shared_ptrs, then you have potential
cache misses as well, stomping all over your performance by stalling
the processor.
 
I couldn't convince them that this was paying a cost for little to
no benefit, so I complied with their wishes. They kept arguing "well
what if someone stores that pointer inside the call chain?". To which
I would look at them like "what, strangers are committing to our code
base without our knowledge?" This was a team where every commit went
through peer code review, so we should have been addressing real problems
and not imaginary monsters in the closet that might come out at night.
If this kind of mindless "it has to be shared_ptr everywhere" simple
minded behavior is what you're talking about as "dogma", then surprise,
I agree with you.
 
However, if you watch Herb Sutter's talk, that isn't what he's been
saying. He's not issuing dogma. He is offering advice about how to
use heap memory in such a way that ownership is explicit by design and
leak-free by construction. He's talking about the data structures and
how declaring things as shared_ptr or unique_ptr in the data structure
makes them leak free by default and explicitly declares who owns the data.
From there you should program in such a way that uses of the raw pointer
don't have any implication about ownership, just access. This makes it
such that if I ever see a function taking a raw pointer, I know that
ownership isn't transferred, only access provided. The called code
never becomes an owner of the pointed to data.
 
With sufficient personal discipline, you can use raw pointers and C
style programming habits and make all of this work. However, I see no
reason to reject Herb's advice, because it is consistent with my own
programming experience. Once I started using smart pointers and standard
library containers to manage the ownership of resources, I stopped having
memory/resource leaks. An entire class of problems just went away and
I could focus on the logic in my problem domain and not resource leaks.
It's not that I can't make it work the C way, or that I don't know how
to write efficient code, it's that C++ lets me achieve the same
objective (leak safety without compromising efficiency) with less
work.
--
"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>
ram@zedat.fu-berlin.de (Stefan Ram): Oct 03 02:48PM

>io.tellp();
 
Works here without tellp. tellp has no documented effect.
 
#include <cctype>
#include <fstream>
#include <initializer_list>
#include <ios>
#include <iostream>
#include <ostream>
 
int main()
{ auto const flags
{ ::std::ios::in | ::std::ios::out | ::std::ios::ate };
auto stream = ::std::fstream{ R"(MyStory.txt)", flags };
stream.seekp( 0 );
while( stream )
{ auto ch{ stream.get() };
if( stream && ::std::islower( static_cast< unsigned char >( ch )))
{ ch = static_cast< decltype( ch )>
( ::std::toupper( static_cast< unsigned char >( ch )));
stream.seekp( -1, ::std::ios::cur ); stream.put( ch ); }}}
ram@zedat.fu-berlin.de (Stefan Ram): Oct 03 04:59PM

>std::unordered_set<std::string*>
>Will it hash by default (C++11 or higher) by address or by
>string ?
 
I have not read about it, but since it contains addresses,
I'd expect it to be a set of addresses.
 
>If so, is it the reasonably good solution to use the wrapper
>for std::hash<std::string> ?
 
Solution for which problem?
bintom <binoythomas1108@gmail.com>: Oct 03 07:22AM -0700

I have the following C++ program that uses an fstream object to read each character in a text file "MyStory.txt" and replace the lower-case alphabets with upper case.
 
It wasn't working initially, so I added a tellp() function call to tell me the position of the write pointer. And lo and behold, the program started working fine. But I have no clue at the rationale of this behaviour. Also, is there a better (more sensible) way of getting the program to do its job?
 
 
int main()
{ fstream io("MyStory.txt", ios::in | ios::out | ios::ate);
char ch;

io.seekg(0);
io.seekp(0);

while(io)
{ io.get(ch);
if(!io)
break;
if(islower(ch))
{ ch = toupper(ch);
io.seekp(-1, ios::cur);
io.put(ch);
io.tellp();
}
}

io.close();
}
Bo Persson <bop@gmb.dk>: Oct 03 05:25PM +0200

On 2017-10-03 16:22, bintom wrote:
> }
 
> io.close();
> }
 
When switching between reading and writing (in any direction) you have
to perform a seek. io.tellp() might do that for you.
 
 
Bo Persson
Bo Persson <bop@gmb.dk>: Oct 03 03:52PM +0200

> Yes as above ok..
> in x=f(a) in what I would know: f return one obj , = is executed, than would be called the destructor for tmp obj (returned from f)
> than the function that free the memory to the heap, free() says that the pointer is not right and it stop the program. I not understand why compile has to emit only one warning for that and not one error (at last for class obj)
 
if(operation(j))
{opera(&v);return v}
 
 
 
It's not an error if operation(j) happens to return true for some value
of j. The compiler might not be able to tell.
 
 
Bo Persson
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 03 08:24AM -0400

On 10/3/2017 2:44 AM, Juha Nieminen wrote:
>> and activities.
 
> I find it rather telling that honesty is among those. Which is quite
> telling given how dishonest you are.
 
I have said it in other posts, to other people who are attacking me as
you are here:
 

https://groups.google.com/d/msg/alt.os.development/XawaCBEClXE/zylVTZ_FCAAJ
 
-----[ Begin ]-----
 
The message I teach is this: There is coming a day when you will
then be removed from denial through sin, and forced into the realm
of true reality, whereby you will know on that day the reality of
realities ... that you have sin, that you are under judgment, that
you are being condemned, and that you will be tossed forever into
the eternal lake of fire where you will be tormented day and night.
 
The message I teach is this: Jesus doesn't want you to go there.
He's made the way out for you, and for everyone else. He's made
it free. He's having men and women like me go all over the whole
world teaching you about it. He gave you the Bible to learn and
study about Him so you can know for sure these teachings are not
our own. The Bible I teach from (King James Bible) was written
in 1611, long before anyone alive today became a concern to man.
 
Jesus changes souls from the inside out. It is that REAL CHANGE
that I am teaching you about, and pointing you toward.
 
I'm not asking you to join a religion. I'm not asking you to
join a church. I'm not asking you to send people money.
 
I am asking you to, quietly, when you're alone, no noise or any
distractions, the TV turned off, no music, no kids or family or
whatever ... just you and your silent contemplation, I am asking
you to ask Jesus to forgive your sin.
 
It is not about another man.
It is about Jesus.
 
It is not about any religion/religious doctrine.
It is about Jesus.
 
It is not about money or property or even our flesh.
It is about Jesus.
 
I'm not advocating any thing or work of man. I am only teaching
you that you need to go to Jesus and ask forgiveness for your
sin so that you can have eternal life.
 
Jesus will then begin working on your insides, turning your life
away from sin and toward His Kingdom and Kingdom purposes. It is,
at that point, only natural.
 
-----
Do not do false things.
Do not do wrong things.
Do not be a hypocrite.
Do not be a liar.
 
What I'm teaching you to do is ask forgiveness for your sin from
Jesus, and then live a proper and true life before Him.
 
It is His calling. It is His teaching. And He makes it possible
for all who will look up to Him in their lives, and then walk.
 
-----[ End ]-----
 
You misunderstand, Juha, because you are unwilling to hear the truth.
You purposefully misunderstand the message because you do not want
to hear it.
 
The message is there before you. And it is a proper message. And
if you don't believe the words I speak, then look at my life and see
where I am doing things other than I say. I have given all of my
excess labor away for free, and am continuing to do so year in,
year out:
 
http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/
 
I am trying to rally multiple men and women together to create a
full hardware stack devoted to the Lord. It will be for our use,
and we will design a proper system that works like other systems,
but the reason we're doing is a devotion to the Lord, and not a
plan to get rich on patents or unit sales. We are looking to reach
deep within ourselves and pull out the best we have to offer, and
to do so to make other people's lives better.
 
You conclude about me falsely, Juha, because you are unwilling to
hear or see the truth.
 
--
Thank you, | Indianapolis, Indiana | God is love -- 1 John 4:7-9
Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj
-------------------------------------------------------------------------
Software: LSA/C, Debi, RDC, CAlive, ES/2, VJr, VFrP, Logician, C90/99
Hardware:
Aroxda Desktop CPU -- 40-bit multi-core 80386 with many extensions
Arxita Embedded CPU -- Low power, low pin count 80386 w/128 registers
Arlina Compute FPGA -- Scalable compute cores, large GPIO pin count
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)