comp.lang.c++.moderated Google Group

Re: Fastest way to parse strings from a very big file!

2009-11-24T05:52:48Z

Get the code correct first, and then worry about "efficiency". And
BENCHMARK BENCHMARK BENCHMARK before you do "efficiency" tweaks.
I'd use your first method -- read line by line into a std::string.
If benchmarking/profiling then shows that 1) you're too slow, and 2)
the
bottleneck is in the parsing; then -- and ONLY THEN -- should you look

Re: (Inherited) Member access requires "this"

2009-11-24T05:57:20Z

This will not compile with _any_ compiler. You don't have any 'm_p'
declared anywhere. Your 'forward1' has a member named 'p', not 'm_p'.
Apparently, you were compiling something different with GCC. In any
case, try posting more or less _real_ code.
The reason for this is that the inner class 'forward1' is actually just

Re: (Inherited) Member access requires "this"

2009-11-24T05:53:32Z

Microsoft's behavior is actually wrong and GCC's is right. I can't
remember the exact details but there is actually an edge case where
the compiler actually cannot know the right thing to do and so
Microsoft makes an assumption that is unwarranted in the general
case. As a rule, GCC is going to go more by the standard exactly,

Re: Trying to come to terms with typecasting operators

2009-11-24T05:51:40Z

Hm.
Wrote the code and the post in parallel, so I lost the
point first time around.
In the code below is the test using reinterpret_cast<>
added, along with the corresponding added output.
As can be seen, each char value is preceeded by a number
of leading zeros that I am unable to get rid of. I assume

Re: (Inherited) Member access requires "this"

2009-11-24T05:52:28Z

See FAQ 35.19 [link]
Basically, because forward1 is a member of a template, it becomes a
dependent base
class. You need to use one of the two constructs you've already
found.

Re: Trying to come to terms with typecasting operators

2009-11-24T05:53:10Z

What has memory footprint got to do with static_cast<> ?
int main() {
// Hex values of digits: 0 1 2 3
unsigned char c[] = {0x30,0x31,0x32,0x33};
std::cout << "Using static_cast<> " << std::endl;
for (size_t n = 0; n != 4; ++n) {
std::cout << std::hex << static_cast<unsigned int> (c[n])

Re: Trying to come to terms with typecasting operators

2009-11-24T05:50:19Z

Yes, this is intended behavior.
So, why not using a static_cast then?
No. What is your hesitation about a static_cast? You could
also simply rely on implicit conversion with a very tiny helper
function:
inline int to_int(char c) { return c; }
You could also easily define your own IO manipulator, which

Re: Fastest way to parse strings from a very big file!

2009-11-24T05:52:04Z

I suggest using std::string.getline() to read a line into a
std::string from an istream and then parse the string into fields.
Reading the entire file into a buffer uses more space than reading
line by line. Also, you will be able catch lines errors such as wrong
number of fields this way. Reading the entire file at once won't

Re: (Inherited) Member access requires "this"

2009-11-24T05:50:38Z

The clue here is that everything compiles fine in gcc also if you remove the
template<class T> on class outer. It has everything to do with dependant names
and thus the rules of "dependent name lookup." Note that gcc is compiling this
correctly here, and you will see the same failure of your code if you pass it

Re: Memberwise copying?

2009-11-24T05:55:36Z

Borland Turbo C++, Microsoft Visual C++ starting at 1.5, 1992-1995...
probably a Visual C++ bug that I've just remembered...

Re: Fastest way to parse strings from a very big file!

2009-11-24T05:54:32Z

In your case I'd probably just read the file line by line. I make my
case as follows.
1) You probably wouldn't notice the optimization. 40,000 records
really isn't all that much data and whatever efficiency you might gain
from blobbing it up and trying to parse it all in RAM will be hard to
detect
2) You may not get the optimization you think. The object of blobbing

Re: Question on goto with try/catch

2009-11-24T05:40:21Z

Nick Hounsome <nick.houns...@googlemail.com> wrote in
Oh, I know I can't do much there......
mostly just wanted to hit the log to say
"can't happen trap".

Re: removing from set - does it have to be so ugly?

2009-11-24T05:41:34Z

Seems you are goddam right
but ouch I can't still tell the difference
and personally I'd better use the commented method:
using namespace std;
void print(int elem) {cout << elem << endl;}
bool is_odd(int x) {return x % 2 != 0;}
int main() {
set<int> r;
int tmp[] = {0,1,-5,-3,8,3,2,4,5,6,7,8,9,1 1,22,44,55};

Re: Fastest way to parse strings from a very big file!

2009-11-24T05:37:08Z

I answered a similar question to this on StackOverflow a while back
(which of course I can't find at the moment) by posting the results of
some tests I did that showed that reading into a large buffer was about
twice as fast as reading line by line into a string. You will have to
decide if a 2x increase in code speed (which isn't all that much) is

Re: Memberwise copying?

2009-11-24T05:30:54Z

Your assumptions as expressed literally are incorrect as long
as the original 1998 C++ standard has been published
(ISO/IEC 14882:1998(E)), but I don't know much about the pre-
standard era. The relevant quote here is 12.8 [class.copy]/8
for the copy c'tor:
"The implicitly defined copy constructor for class X performs a