Thursday, March 5, 2015

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

Christopher Pisz <nospam@notanaddress.com>: Mar 05 02:10PM -0600

I know there exists a way to copy a filestream into a string in one
line, using iterators, because I've seen it before on this newsgroup.
I looked up the documentation, but can't seem to get the syntax right.
 
My attempt:
 
std::ifstream("test.txt");
if( !file )
{
// Error
}
 
std::string textToParse;
 
textToParse.assign(std::istreambuf_iterator<char>(file),
std::istream_iterator<char>());
Foo(textToParse);
 
 
A colleague of mine mentioned that this is a much more inefficient way
of doing it, so I wanted to test for funsies compared to:
 
std::ifstream("test.txt");
if( !file )
{
// Error
}
 
std::stringstream textToParse;
textToParse << file.rdbuf();
Foo(textToParse.str());
 
 
 
What's the syntax for the assign-range?
Is there any reason one way should be better than the other?
 
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
Christopher Pisz <nospam@notanaddress.com>: Mar 05 02:16PM -0600

On 3/5/2015 2:10 PM, Christopher Pisz wrote:
 
> What's the syntax for the assign-range?
> Is there any reason one way should be better than the other?
 
Whoops, lets name the ifstream file...
Working on a compilable example, but can't get the assign-range right.
Sorry.
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
Ben Bacarisse <ben.usenet@bsb.me.uk>: Mar 05 09:35PM


> std::string textToParse;
 
> textToParse.assign(std::istreambuf_iterator<char>(file),
> std::istream_iterator<char>());
 
Did you mean something like this:
 
file >> std::noskipws;
std::copy(std::istream_iterator<char>(file),
std::istream_iterator<char>(),
std::inserter(textToParse, textToParse.begin()));
 
?
 
<snip>
--
Ben.
Christopher Pisz <nospam@notanaddress.com>: Mar 05 04:17PM -0600

On 3/5/2015 3:35 PM, Ben Bacarisse wrote:
> std::inserter(textToParse, textToParse.begin()));
 
> ?
 
> <snip>
 
Indeed!
 
Full listing (make your own timer and exception classes):
 
// Shared Includes
#include "Exception.h"
#include "PerformanceTimer.h"
 
// Standard Includes
#include <iostream>
#include <fstream>
#include <sstream>
#include <string>
 
//--------------------------------------------------------------------------------------------------
void Method1()
{
std::ifstream file("test.txt");
if( !file )
{
// Error
throw Shared::Exception(__FILE__, __LINE__, "Cannot open test
file");
}
 
std::string textToParse;
 
file >> std::noskipws;
std::copy(std::istream_iterator<char>(file),
std::istream_iterator<char>(),
std::inserter(textToParse, textToParse.begin()));
 
file.close();
}
 
//--------------------------------------------------------------------------------------------------
void Method2()
{
std::ifstream file("test.txt");
if( !file )
{
// Error
throw Shared::Exception(__FILE__, __LINE__, "Cannot open test
file");
}
 
std::stringstream textToParse;
textToParse << file.rdbuf();
 
file.close();
}
 
//--------------------------------------------------------------------------------------------------
int main()
{
Shared::PerformanceTimer timer;
Method1();
std::cout << "Method 1 :" << timer.Stop() << std::endl;
 
timer.Start();
Method2();
std::cout << "Method 2 :" << timer.Stop() << std::endl;
 
}
 
Output:
Method 1 :0.283209
Method 2 :0.0216563
 
 
That's quite a difference! What's going on under the hood with the
iterator method?
 
 
 
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
Victor Bazarov <v.bazarov@comcast.invalid>: Mar 05 05:26PM -0500

On 3/5/2015 5:17 PM, Christopher Pisz wrote:
> Method 2 :0.0216563
 
> That's quite a difference! What's going on under the hood with the
> iterator method?
 
I don't see any proof of the equality of the result of two different
methods...
 
Inserting into a text string, one character at a time, at the beginning,
most likely involves too many reallocations and too many copy
operations. Have you tried profiling your program?
 
V
--
I do not respond to top-posted replies, please don't ask
"Öö Tiib" <ootiib@hot.ee>: Mar 04 11:43PM -0800

On Wednesday, 4 March 2015 23:26:00 UTC+2, JiiPee wrote:
> > practicing to output ASCII texts ... "Hello World!" and from there
> > perhaps Visual Basic, PHP ... no way C++. ;)
 
> hmmm, are you mocking PHP?? :) They would not like it...
 
Oh, indeed, not nice of me. Perhaps I had one beer too many. :D
JiiPee <no@notvalid.com>: Mar 05 08:00AM

On 05/03/2015 07:43, Öö Tiib wrote:
>>> perhaps Visual Basic, PHP ... no way C++. ;)
>> hmmm, are you mocking PHP?? :) They would not like it...
> Oh, indeed, not nice of me. Perhaps I had one beer too many. :D
 
I am a C++ guy, but I do couple of others as well... I actually like a
bit PHP, its simple to learn and easy to use, I like that with internet
programming. Good tool for that purpose, although some complain its not
so safe but donno.
"Fred.Zwarts" <F.Zwarts@KVI.nl>: Mar 05 09:33AM +0100

"Geoff" schreef in bericht
news:g6hefa98cd8bboqe4u4fj8rocnvkv1q6cc@4ax.com...
 
>sex, GPA, ID_Number, etc.
 
>It's a design choice that is dictated by the scope of the program and
>it's goals.
 
I think it is not only the complexity, but indeed also the scope/locality of
an object.
If you need an age for only four of five lines of code for a few operation
and then discard it, it can be modeled with an int, but if an object
representing an age is used everywhere in a big program and passed to many
different functions (maybe written by other authors) then it may be wise to
restrict is usage (like its range) and put it in an more complex class.
The same considerations as for variables in a function are valid for members
of a class. An age within a class can sometimes be modeled with an int, but
often one needs a subclass.
Juha Nieminen <nospam@thanks.invalid>: Mar 05 09:29AM

> int age = 35;
> std::cout<<"My age is "<<age;
> }
 
I'd say that unless this is a small throw-away program, the best way is:
 
typedef int Age_t; // this somewhere, usually some header file
 
...
 
Age_t age = 35;
// etc
 
This way Age_t can be easily changed into a class if needed. (Thanks to
operator overloading, the usage syntax doesn't need to take the
possibility into account.)
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
JiiPee <no@notvalid.com>: Mar 05 09:33AM

On 05/03/2015 09:29, Juha Nieminen wrote:
> operator overloading, the usage syntax doesn't need to take the
> possibility into account.)
 
> --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
 
Everybody stucks to "age" issue here although it was not meant to be
like that :)
 
I meant, any integer, like:
 
int b;
b = 55;
 
age was not the point here.
JiiPee <no@notvalid.com>: Mar 05 09:35AM

On 05/03/2015 09:29, Juha Nieminen wrote:
> operator overloading, the usage syntax doesn't need to take the
> possibility into account.)
 
> --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
 
yes true. So no need to deside at this moment whether age needs to be a
class or just an int, can be changed later.
David Brown <david.brown@hesbynett.no>: Mar 05 12:34PM +0100

On 04/03/15 18:39, Mr Flibble wrote:
 
> Member variables need only be private if they contribute to the class
> invariant. The coordinates/point class in the OP as it stands has no
> class invariant so making the member variables public is perfectly fine.
 
I think this is the critical issue. If the member variable has some
invariant beyond its data type (such as limited range, or a specified
relationship with other data), then it needs to be private. If not,
then it doesn't /need/ to be private, but you might want to anyway (for
example, to limit access).
 
There is no need to use a getter function just in case you need it later
- it should not be hard to change from direct member access to getters
and setters, unless you try hard to write risky changes (such as making
a getter have the same name as the original public member).
JiiPee <no@notvalid.com>: Mar 05 01:49PM

On 05/03/2015 11:34, David Brown wrote:
> - it should not be hard to change from direct member access to getters
> and setters, unless you try hard to write risky changes (such as making
> a getter have the same name as the original public member).
 
yes. If after long thinking I see that there is no need for
getters-functionality (as I think it is with Point-class) then no need
for getters... and can always then change later if needs, which is very
unlikely though.
woodbrian77@gmail.com: Mar 05 11:44AM -0800

On Wednesday, March 4, 2015 at 2:21:39 PM UTC-6, Öö Tiib wrote:
> someone will born in the future. Longest documented human age is
> 122 years and 164 days. Oldest fictional human Methuselah lived
> 969 years.
 
Oldest human was Methuselah. They knew how to take
care of themselves and others.
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
"Öö Tiib" <ootiib@hot.ee>: Mar 05 11:58AM -0800

On Thursday, 5 March 2015 10:00:16 UTC+2, JiiPee wrote:
> bit PHP, its simple to learn and easy to use, I like that with internet
> programming. Good tool for that purpose, although some complain its not
> so safe but donno.
 
My attitude towards PHP is because in every other programming language
that I can read I know code of very different quality. Not so in PHP.
In PHP I have seen only bad or very bad quality code. So it must be
it is typically written by likes of Peter of yours. ;)
"Öö Tiib" <ootiib@hot.ee>: Mar 05 12:54PM -0800

On Thursday, 5 March 2015 11:33:17 UTC+2, JiiPee wrote:
 
> int b;
> b = 55;
 
> age was not the point here.
 
Yes, but what was the point? In actual programs we rarely deal with
"any integers". Numeric data in actual programs usually consists of
meaningful quantities that are interrelated in problem domain of
the program.
 
Lets say you got exceptional case where your problem domain is
actually dealing with 'int'. Say it really asks for two 'int's
and just adds those together. It is still not an obvious task:
 
#include <climits>
#include <iostream>
 
int main()
{
std::cout << "enter first int:";
int first;
std::cin >> first;
std::cout << "first int is " << first << "\n";
std::cout << "enter second int:";
int second;
std::cin >> second;
std::cout << "second int is " << second << "\n";
std::cout << "sum of first and second int is ";
 
// you think first + second ???
// WRONG !!!
 
if ((first > 0) && (second > INT_MAX - first))
std::cout << "overflow" << std::endl;
else if ((first < 0) && (second < INT_MIN - first))
std::cout << "underflow" << std::endl;
else
std::cout << first + second << std::endl;
}
 
So if you need to add up the 'int's in more than in one location
of your program or even need to do other arithmetic operations
with 'int's too then you start soon to see why you better make a
class around that 'int' to whose members to put that logic of
operating with 'int's.
 
Or if you don't do it but simply write 'first + second' then it
is PHP ... plain mess of ugly security vulnerabilities.
scott@slp53.sl.home (Scott Lurndal): Mar 05 10:00PM

>> 969 years.=20
 
>Oldest human was Methuselah. They knew how to take=20
>care of themselves and others.
 
There was no such person. Nor did the patriarchs live
for more than 3 score and 10.
 
All myths.
Christopher Pisz <nospam@notanaddress.com>: Mar 05 04:12PM -0600

On 3/5/2015 4:00 PM, Scott Lurndal wrote:
 
> There was no such person. Nor did the patriarchs live
> for more than 3 score and 10.
 
> All myths.
 
It was before high fructose corn syrup.
 
 
--
I have chosen to troll filter/ignore all subthreads containing the
words: "Rick C. Hodgins", "Flibble", and "Islam"
So, I won't be able to see or respond to any such messages
---
ram@zedat.fu-berlin.de (Stefan Ram): Mar 05 01:57PM

>getters-functionality (as I think it is with Point-class) then no need
>for getters... and can always then change later if needs, which is very
>unlikely though.
 
In a certain application, a point might be rotated very
often, but set/get only very rarely. In such cases, it
might speed up the program to change the internal format into
polar coordinates r and phi, but keep the x-y interface.
 
But this would make no sense in the case of the semantics
to be just a double pair, not a point in the plane. Without
an interface definition (contract) one cannot tell the diffence.
Luca Risolia <luca.risolia@linux-projects.org>: Mar 05 02:46AM +0100

Il 04/03/2015 14:24, Glen Stark ha scritto:
> void fun();
> int m_val;
> };
 
^^^^^
 
> }
 
> Is there a solution to this? I'd also be interested in hearing why the
> above isn't allowed.
 
One solution in C++14 is to use generalized lambda captures:
 
auto non_matching_foo = [m_val = m_val](Foo f){return (f.m_val != m_val);};
 
The reason why your code does not compile is that a lambda can capture
non-static local variables only. any "m_val" implicitly means
"this->m_val" for the compiler: if capturing were allowed, the Foo's
this pointer would be copied in the closure derived from the lambda,
resulting in the closure's viability obscurely tied to the Foo object's
lifetime, which is, honestly, undesirable.
Luca Risolia <luca.risolia@linux-projects.org>: Mar 05 02:54AM +0100

Il 04/03/2015 21:20, Chris Vine ha scritto:
 
> auto non_matching_foo = [m_val=this->m_val](Foo f){
^^^^^^
 
"this->" is superfluous and ugly.
"Charles J. Daniels" <chajadan@gmail.com>: Mar 04 06:23PM -0800

On Wednesday, March 4, 2015 at 5:24:50 AM UTC-8, Glen Stark wrote:
> above isn't allowed.
 
> Thanks
 
> Glen
 
Capturing this is cheap. Hard to do better. Without an explicitly demonstrated need to optimize this section of your code, I wouldn't even waste the time thinking of alternate approaches.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Mar 05 10:12AM

On Thu, 05 Mar 2015 02:54:16 +0100
 
> > auto non_matching_foo = [m_val=this->m_val](Foo f){
> ^^^^^^
 
> "this->" is superfluous and ugly.
 
It is clearer what it is doing. Whether it is "ugly" is in the eye of
the beholder.
 
Chris
jt@toerring.de (Jens Thoms Toerring): Mar 05 01:00AM

> I've decided to try to use the C++-style casts. But they look ugly!
 
They're supposed to look ugly! In most cases you don't need casts
and if they are really required this is typically a point in the
code that needs to stand out. So an ugly and easily to find cast
is a rather good idea in my book. In such places something happens
where the author states "I know better than the compiler" - and I
have seen too many places where this wasn't true...
 
> The best I have managed so far is to add spaces to give:
> ti.lpszText = const_cast <LPTSTR> (text);
 
That's a typical cast that would raise an eyebrow: why do you
cast away the const-ness of 'text'? Probably there was some
reason why it was declared as constant? By casting away the
const-ness you just opened a hole for a lot of new bugs. So,
instead of trying to hide the cast you should better add a
long comment why this was unavoidable and leave the cast in
in all it's ugliness for you and others to find easily should
anything go wrong!
 
> anyone have anything better? Or is it the case, as one tutorial seemed to
> hint, that the casts are deliberately ugly to dissuade people from writing
> code that uses them?
 
Well, don't use casts unless they're really required. And if a
cast is needed anyway but it's benign (but you should be absolutely
sure of that, it shouldn't just be something to make the compiler
stop whining) you can still use C-style casts which stand out less
(but don't explain what kind of cast it is):
 
ti.lpszText = (LPTSTR) text;
 
But, repeating myself, the ugliness isn't in the cast itself but
in the design (your's or some library's you may have to use) that
requires the cast.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
Robert Wessel <robertwessel2@yahoo.com>: Mar 04 07:21PM -0600

On Wed, 4 Mar 2015 14:48:29 -0800 (PST), Paul N <gw7rib@aol.com>
wrote:
 
>I've decided to try to use the C++-style casts. But they look ugly! The best I have managed so far is to add spaces to give:
 
>ti.lpszText = const_cast <LPTSTR> (text);
 
>But this is still ugly, and is difficult to read - the round brackets look like an optional extra instead of being an essential part of the cast. Does anyone have anything better? Or is it the case, as one tutorial seemed to hint, that the casts are deliberately ugly to dissuade people from writing code that uses them?
 
 
I think if you have enough casts that their ugliness is an issue, you
have far too many, and you need to rethink your design.
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)