Thursday, December 24, 2015

Digest for comp.lang.c++@googlegroups.com - 17 updates in 6 topics

Paul <pepstein5@gmail.com>: Dec 24 02:59PM -0800

I'm confused about when conversions between types are allowed.
int* z = new int(3);
char* x= (char*)z; //works fine.
 
However, if the second line is replaced by char* x = char*(z); I get "expected primary expression before char" compile error. I was anticipating that I can cast from int* to char* this way in the same way that you can cast 5.3 to int by writing int(5.3);
 
If the second line is replaced by char*x = z; I get an error -- "can not convert from char* to int* in initialization" How could I have know that such an initialization is illegal, given that the cast of the form char* x = (char*)z; is ok ?
 
Paul
Paavo Helde <myfirstname@osa.pri.ee>: Dec 24 05:34PM -0600

Paul <pepstein5@gmail.com> wrote in
> "expected primary expression before char" compile error. I was
> anticipating that I can cast from int* to char* this way in the same
> way that you can cast 5.3 to int by writing int(5.3);
 
This is a lexical issue, it just does not make sense to multiply a type
char with something. Change it to
 
char* x = reinterpret_cast<char*>(z);
 
or
 
char* x = (char*)(z);
 
or
 
typedef char* charPtr;
charPtr x = charPtr(z);
 
Note that only the first one is really C++.
 
> not convert from char* to int* in initialization" How could I have
> know that such an initialization is illegal, given that the cast of
> the form char* x = (char*)z; is ok ?
 
By reading and understanding the language rules?
 
hth
Paavo
Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Dec 23 08:33PM -0700

On 23 Dec 2015 16:20:40 GMT, ram@zedat.fu-berlin.de (Stefan Ram)
wrote:
 
<snip>
> ++q; ++p; }}}}
 
> You might find my placements of »if( i )« strange, but apart
> from the the formatting, are there any deficits in the code?
 
More conventional formatting might have saved you from what looks like
a bug: You're incrementing q whether or not you've assigned anything
to *q.
 
Louis
mark <mark@invalid.invalid>: Dec 24 02:11PM +0100

On 2015-12-23 20:52, Ian Collins wrote:
 
> Without measuring, I wouldn't make that claim. During some earlier
> testing, I found using streambuf iterators to be an efficient way to
> read through a file.
 
Efficient??? What??? Streams suck.
 
GCC 5.2 (g++ -O2 -std=c++14):
fread Elapsed: 213.867 ms
fread Transfer rate: 1943.43 MB/s
streambuf_iterator Elapsed: 3875 ms
streambuf_iterator Transfer rate: 107.261 MB/s
 
VC++ 2015 (cl -O2):
fread Elapsed: 223.228 ms
fread Transfer rate: 1861.93 MB/s
streambuf_iterator Elapsed: 7184.81 ms
streambuf_iterator Transfer rate: 57.8492 MB/s
 
 
 
 
#include <string>
#include <cstdio>
#include <cerrno>
#include <chrono>
#include <iostream>
#include <algorithm>
#include <iterator>
#include <fstream>
#include <streambuf>
 
// code from
// http://insanecoding.blogspot.de/2011/11/how-to-read-in-file-in-c.html
 
std::string get_file_contents_fread(const char *filename) {
std::FILE *fp = std::fopen(filename, "rb");
if(fp) {
std::string contents;
std::fseek(fp, 0, SEEK_END);
contents.resize(std::ftell(fp));
std::rewind(fp);
std::fread(&contents[0], 1, contents.size(), fp);
std::fclose(fp);
return(contents);
}
throw(errno);
}
 
std::string get_file_contents_stream(const char *filename) {
std::ifstream in(filename, std::ios::in | std::ios::binary);
if(in) {
std::string contents;
in.seekg(0, std::ios::end);
contents.reserve(in.tellg());
in.seekg(0, std::ios::beg);
std::copy((std::istreambuf_iterator<char>(in)),
std::istreambuf_iterator<char>(),
std::back_inserter(contents));
in.close();
return(contents);
}
throw(errno);
}
 
auto time_fn = [](auto fn, const char* desc, const char* filename) {
typedef std::chrono::high_resolution_clock clock;
typedef std::chrono::duration<float, std::milli> duration;
clock::time_point start = clock::now();
auto res = fn(filename);
duration elapsed = clock::now() - start;
std::cout << desc << " Elapsed: " << elapsed.count() << " ms\n"
<< desc << " Transfer rate: "
<< res.size() / (1000.0* elapsed.count())
<< " MB/s\n";
};
 
int main() {
auto filename = "testfile.txt";
time_fn(get_file_contents_fread, "fread", filename);
time_fn(get_file_contents_stream, "streambuf_iterator", filename);
return 0;
}
Daniel <danielaparker@gmail.com>: Dec 24 07:48AM -0800

On Thursday, December 24, 2015 at 8:11:23 AM UTC-5, mark wrote:
 
> I found using streambuf iterators to be an efficient way to
> > read through a file.
 
> Efficient??? What??? Streams suck.
 
Indeed :-) C++ streams appear to be an argument in favor of "premature optimization", as they appear to be intrinsically slow by design, and there appears to be nothing much implementations can do about it. The picture is even worse comparing std::istringstream and strtod, or std::ostringstream and sprintf. There is certainly no concept of "you don't pay for what you don't use" with streams.
 
Daniel
Ian Collins <ian-news@hotmail.com>: Dec 25 09:00AM +1300

mark wrote:
>> testing, I found using streambuf iterators to be an efficient way to
>> read through a file.
 
> Efficient??? What??? Streams suck.
 
Modify your code to solve the original problem rather than doing a file
copy. Then run in on a file bigger than half of your RAM.
 
--
Ian Collins
Louis Krupp <lkrupp@nospam.pssw.com.invalid>: Dec 24 03:10PM -0700

On 24 Dec 2015 20:13:22 GMT, ram@zedat.fu-berlin.de (Stefan Ram)
wrote:
 
> and the code is equivalent to
 
>if( ch != 'x' )q = ch;
>++p;
 
I had no idea it worked like that, but it makes sense.
 
Thank you.
 
Louis
Paavo Helde <myfirstname@osa.pri.ee>: Dec 24 05:18PM -0600

Ian Collins <ian-news@hotmail.com> wrote in
 
>> Efficient??? What??? Streams suck.
 
> Modify your code to solve the original problem rather than doing a
> file copy. Then run in on a file bigger than half of your RAM.
 
You mean, a file larger than 6 GB? Don't have so many text files like
that, sorry.
 
BTW, I see your moves with getline and fread, and raise you mmap(). No
numbers and non-standard, but if you care about file I/O performance
that's the way to go. Doesn't consume RAM either.
 
Cheers
Paavo
Mr Flibble <flibble@i42.co.uk>: Dec 24 07:26PM

Merry Winterval Sausages!
 
/Flibble
Gareth Owen <gwowen@gmail.com>: Dec 24 08:46PM


> Merry Winterval Sausages!
 
Happy Festivus Sausages
Ian Collins <ian-news@hotmail.com>: Dec 25 10:18AM +1300

Gareth Owen wrote:
> Mr Flibble <flibble@i42.co.uk> writes:
 
>> Merry Winterval Sausages!
 
> Happy Festivus Sausages
 
Don't forget those Christmas Breakfast Sausages :)
 
I enjoyed mine!
 
--
Ian Collins
ram@zedat.fu-berlin.de (Stefan Ram): Dec 24 08:13PM

>More conventional formatting might have saved you from what looks like
>a bug: You're incrementing q whether or not you've assigned anything
>to *q.
 
It is a bug with regard to the intended source text
in terms of readability. You are right. What I did
intend to say, was indeed:
 
if( ch != 'x' )*q++ = ch;
++p;
 
. It is not a bug with regard to the actual program
execution, because for an »ostreambuf_iterator« object both
»*« and »++« are actually NOPs (pure identity functions),
and the code is equivalent to
 
if( ch != 'x' )q = ch;
++p;
 
. Still, your remark was very helpful as I indeed will
change my source to use »*q++« to convey my intentions.
 
I'd like to thank you all for this and other answers to
my OP in this newsgroup.
Bo Persson <bop@gmb.dk>: Dec 24 11:46AM +0100

On 2015-12-23 22:21, Paavo Helde wrote:
>> </quote>
 
>> I think reporting one or two compiler bugs each week is ridiculous.
 
> Why? If nobody is reporting, the bugs don't get fixed.
 
Some of us might have expected an Update 1 to have fewer bugs than the
initial release. :-)
 
 
Bo Persson
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 23 09:49PM +0100

https://connect.microsoft.com/VisualStudio/feedback/details/2163090/internal-compiler-error-on-some-sfinae-code
 
Code that crashes the Visual C++ 2015 update 1 compiler, written for a
Stack Overflow answer, (http://stackoverflow.com/a/20819867/464581):
 
 
<code>
#ifndef DO_BAD
# define DO_GOOD
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)