comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* implicit passing by reference - 7 messages, 6 authors
http://groups.google.com/group/comp.lang.c++/t/dddf6db3d26e03e4?hl=en
* Working with Large Values (double) - 9 messages, 6 authors
http://groups.google.com/group/comp.lang.c++/t/e42843c9cdf13724?hl=en
* shared_ptr and unique_ptr related question - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/ae1f30d2345574fe?hl=en
* OT: Problem building libc++ - 2 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/177ee9b847d7540f?hl=en
* RICHARD LEAKEY IN PRISON -- THE THRINAXODON TIMES - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/b39dd6c751c33948?hl=en
* hw to get started - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/1a1994fe83f96e2f?hl=en
* IO problem - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/1627ad3e27ed2570?hl=en
==============================================================================
TOPIC: implicit passing by reference
http://groups.google.com/group/comp.lang.c++/t/dddf6db3d26e03e4?hl=en
==============================================================================
== 1 of 7 ==
Date: Fri, Feb 21 2014 4:21 pm
From: Ian Collins
red floyd wrote:
> On 2/21/2014 2:43 PM, Victor Bazarov wrote:
>
>> I did? Damn... I thought he was replying to Paavo. Ah, no matter.
>> Sorry! My fault! I really regret this! Etc. etc.
>>
>
> You are hereby sentenced to 200 hours of listening to Justin Bieber
> albums.
That, being a cruel and inhumane punishment, would be considered a
breach of Victor's human rights by the European court :)
--
Ian Collins
== 2 of 7 ==
Date: Fri, Feb 21 2014 4:47 pm
From: Victor Bazarov
On 2/21/2014 7:21 PM, Ian Collins wrote:
> red floyd wrote:
>> On 2/21/2014 2:43 PM, Victor Bazarov wrote:
>>
>>> I did? Damn... I thought he was replying to Paavo. Ah, no matter.
>>> Sorry! My fault! I really regret this! Etc. etc.
>>>
>>
>> You are hereby sentenced to 200 hours of listening to Justin Bieber
>> albums.
>
> That, being a cruel and inhumane punishment, would be considered a
> breach of Victor's human rights by the European court :)
I still probably deserve it. Besides, I don't reside in the
jurisdiction of the European court :-[
V
--
I do not respond to top-posted replies, please don't ask
== 3 of 7 ==
Date: Fri, Feb 21 2014 10:40 pm
From: red floyd
On 2/21/2014 4:47 PM, Victor Bazarov wrote:
> On 2/21/2014 7:21 PM, Ian Collins wrote:
>> red floyd wrote:
>>> On 2/21/2014 2:43 PM, Victor Bazarov wrote:
>>>
>>>> I did? Damn... I thought he was replying to Paavo. Ah, no matter.
>>>> Sorry! My fault! I really regret this! Etc. etc.
>>>>
>>>
>>> You are hereby sentenced to 200 hours of listening to Justin Bieber
>>> albums.
>>
>> That, being a cruel and inhumane punishment, would be considered a
>> breach of Victor's human rights by the European court :)
>
> I still probably deserve it. Besides, I don't reside in the
> jurisdiction of the European court :-[
Just giving you a hard time, Victor. The opportunity was too good
to pass up. :-D
== 4 of 7 ==
Date: Sat, Feb 22 2014 12:25 am
From: Jorgen Grahn
On Fri, 2014-02-21, Marcel Müller wrote:
> On 21.02.14 12.44, Jorgen Grahn wrote:
>> On Fri, 2014-02-21, Paavo Helde wrote:
>>> In C++ the function declarations specify exactly if the pass is by value
>>> or by reference.
>>
>> Or you could say it's always by value -- but you can choose to pass a
>> reference or pointer to some object.
>
> Strictly speaking it is up to the platform how references are
> implemented. The option that they are binary compatible to pointers is
> only a common solution.
Of course. Note that I didn't imply that references are pointers --
just that both can be used if you want "pass by reference" semantics.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 5 of 7 ==
Date: Sun, Feb 23 2014 6:13 am
From: James Kanze
On Friday, February 21, 2014 5:42:57 AM UTC, Paavo Helde wrote:
> Do not take stackoverflow too seriously, the
> answers there are ranked by the person least qualified to judge the
> correctness.
You've noticed that too. The highest ranked answers are rarely
the correct ones.
--
James
== 6 of 7 ==
Date: Sun, Feb 23 2014 6:16 am
From: James Kanze
On Friday, February 21, 2014 11:44:54 AM UTC, Jorgen Grahn wrote:
> On Fri, 2014-02-21, Paavo Helde wrote:
> I tell my coworkers to avoid stackoverflow because of stuff like
> this.
It's harder to do if you work in an investment bank, where NNTP
is blocked by the firewall, as is Google Groups. (I have yet to
figure out the reasoning behind it, but it seems to be some
legal requirement, since it is univeral, at least in London
banks.)
--
James
== 7 of 7 ==
Date: Sun, Feb 23 2014 6:29 am
From: ram@zedat.fu-berlin.de (Stefan Ram)
James Kanze <james.kanze@gmail.com> writes:
>On Friday, February 21, 2014 5:42:57 AM UTC, Paavo Helde wrote:
>>Do not take stackoverflow too seriously, the
>>answers there are ranked by the person least qualified to judge the
>>correctness.
>You've noticed that too. The highest ranked answers are rarely
>the correct ones.
Read the post »Welcome Slashdot refugees!« of February 6 in
the newsgroup »comp.misc« and the following posts to witness
the return of Slashdot users to Usenet.
==============================================================================
TOPIC: Working with Large Values (double)
http://groups.google.com/group/comp.lang.c++/t/e42843c9cdf13724?hl=en
==============================================================================
== 1 of 9 ==
Date: Fri, Feb 21 2014 5:28 pm
From: Robert Wessel
On Fri, 21 Feb 2014 13:14:58 -0800, Geoff <geoff@invalid.invalid>
wrote:
>On Fri, 21 Feb 2014 14:20:42 -0600, Paavo Helde
><myfirstname@osa.pri.ee> wrote:
>
>>jacob navia <jacob@spamsink.net> wrote in
>>news:le8a54$8rn$1@speranza.aioe.org:
>>>>
>>>> #include <iostream>
>>>> #include <sstream>
>>>> #include <iomanip>
>>>>
>>>> int main() {
>>>> double x = 10000.3e+34;
>>>>
>>>> std::ostringstream oss;
>>>> oss << std::fixed << std::setprecision(100) << x;
>>>> std::string s = oss.str();
>>>>
>>>> std::cout << s << "\n";
>>>> }
>>>>
>>>> This prints:
>>>> "100003000000000000000000000000000000000.00000000000000000000000000000
>>>> 0000000000000000000000000000000000000000000000000000000000000000000000
>>>> "
>>>>
>>>> hth
>>>> Paavo
>>>>
>>>
>>> Sorry but compiling with gcc gives
>>> 100002999999999994323893219714356215808.0000000000000000000000000000000
>>> 000000000000000000000000000000000000000000000000000000000000000000000
>>>
>>> Which compiler did you use?
>>
>>Microsoft VS2012 Professional, 64-bit mode.
>>
>>I guess both compilers produce correct output. I like gcc behavior more,
>>it shows better what one can get when blindly following a whim like "I
>>don't like scientific notation".
>>
>
>Copeland is writing a check writing program, I think scientific
>notation might not work in that case. :)
Attempting to use FP to represent currency is fundamentally doomed to
failure. I didn't see that that's what the OP was doing, but if it
is, he should definitely reconsider, unless he doesn't actually care
about the actual results (which may well be the case if this something
like a homework assignment).
== 2 of 9 ==
Date: Sat, Feb 22 2014 3:50 pm
From: mrc2323@cox.net (Mike Copeland)
> > Doubles are floating point and are inherently "in" scientific
> > notation.
> >
> > But if you've converted a double to a character format, you can
> > usually specify a precision, if the default (commonly 6) is not what
> > you want. With streams, for example, you can use std::setprecision().
>
> Yes, a combination of fixed, setw and setprecision do what I want:
> double inVal = 10000000.3;
> ostringstream ossw;
> ossw.str(""), ossw << fixed << setw(10) << setprecision(2) << inVal;
> str = ossw.str();
Actually, the "setw(10)" isn't needed.
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
== 3 of 9 ==
Date: Sun, Feb 23 2014 12:41 am
From: jacob navia
Le 22/02/2014 02:28, Robert Wessel a écrit :
> On Fri, 21 Feb 2014 13:14:58 -0800, Geoff <geoff@invalid.invalid>
> wrote:
>> Copeland is writing a check writing program, I think scientific
>> notation might not work in that case. :)
>
>
> Attempting to use FP to represent currency is fundamentally doomed to
> failure. I didn't see that that's what the OP was doing, but if it
> is, he should definitely reconsider, unless he doesn't actually care
> about the actual results (which may well be the case if this something
> like a homework assignment).
>
Writing a check of 10000.3e+34 dollars???????????
WOW, I think that goes even beyond the U.S. TOTAL debt!
== 4 of 9 ==
Date: Sun, Feb 23 2014 5:53 am
From: James Kanze
On Saturday, February 22, 2014 1:28:32 AM UTC, robert...@yahoo.com wrote:
> Attempting to use FP to represent currency is fundamentally doomed to
> failure.
That depends on what you are doing. If you're doing
risk analysis on futures contracts, for example, it's
perfectly appropriate (and you probably can't afford
the loss of performance a decimal solution would cost
you). After all, any rounding errors will be much
less than the variance of the Monte Carlo simulation
anyway.
If you're doing anything even closely related to
legally required bookkeeping, however (and I would
imagine writing checks comes into that providence),
then using machine floating point is probably illegal,
and could, in many jurisdictions, send you to jail.
Note that I say "machine floating point", and not just
FP. There's no problem with a well written decimal
floating point package here. For that matter, it's
possible to use machine floating point, *if* you scale
so that all actual values are exactly representable
whole numbers, and take the proper precautions. It's
anything but trivial, however, and I'd probably go
with a decimal package, even if I had to write it
myself, as being a lot simpler.
--
James
== 5 of 9 ==
Date: Sun, Feb 23 2014 5:57 am
From: James Kanze
On Friday, February 21, 2014 6:00:10 AM UTC, robert...@yahoo.com wrote:
> On Thu, 20 Feb 2014 17:25:50 -0700, mrc2323@cox.net (Mike Copeland)
> wrote:
> > How can I express a large value as a double? (e.g. 1000000.3) Whereas
> > this compiles and executes, when I try to convert it to a
> >string value it converts as a scientific string (e.g. "1e+006", not
> >"1000000.3"). I want to process all the characters of the value of the data
> >as a std::string. Or is there a way to convert the double to assure it's
> >not expressed in scientific notation? TIA
> Doubles are floating point and are inherently "in" scientific
> notation.
No. Scientific notation, like pratically all other text
formats, is base 10. None of the floating point formats I know
of that are in use today are base 10. And the way machine
floating point typically represents the exponent is not
scientific notation either.
> But if you've converted a double to a character format, you can
> usually specify a precision, if the default (commonly 6) is not what
> you want. With streams, for example, you can use std::setprecision().
Or just call `precision` on the stream itself. (I don't think
I've ever `std::setprecision()`.)
--
James
== 6 of 9 ==
Date: Sun, Feb 23 2014 5:59 am
From: James Kanze
On Friday, February 21, 2014 2:51:27 PM UTC, Scott Lurndal wrote:
> man 3 snprintf
>
> (Yes, it works fine in C++)
Funny, because it never worked "fine" in C. In C, you use it,
because there's not really anything else, but C formatted output
has to be one of the worst designs ever.
--
James
== 7 of 9 ==
Date: Sun, Feb 23 2014 6:26 am
From: ram@zedat.fu-berlin.de (Stefan Ram)
James Kanze <james.kanze@gmail.com> writes:
>No. Scientific notation, like pratically all other text
>formats, is base 10. None of the floating point formats I know
>of that are in use today are base 10. And the way machine
It seems the Windows GUI calculator programm uses base 10
(as other pocket calculators?), and also java.math.BigDecimal
uses base 10. C# has a decimal type: »decimal myMoney=300.5m;«.
C++ now has custom literals, so we might be able to copy this.
Maybe Mathematica / Wolfram Alpha uses decimal too.
== 8 of 9 ==
Date: Sun, Feb 23 2014 6:46 am
From: jacob navia
Le 23/02/2014 14:59, James Kanze a écrit :
> On Friday, February 21, 2014 2:51:27 PM UTC, Scott Lurndal wrote:
>
>> man 3 snprintf
>>
>> (Yes, it works fine in C++)
>
> Funny, because it never worked "fine" in C. In C, you use it,
> because there's not really anything else, but C formatted output
> has to be one of the worst designs ever.
>
Of course. For instance in the evil C language you use:
printf("0x%08x\n", x);
In the much more advanced C++ language you use:
std::cout << std::hex << std::setfill('0') << std::setw(8) << x <<
std::dec << std::endl;
Of course C has ONE of the worst designs. But C++ has THE WORST!
:-)
jacob
== 9 of 9 ==
Date: Sun, Feb 23 2014 10:09 am
From: woodbrian77@gmail.com
On Sunday, February 23, 2014 8:46:10 AM UTC-6, jacob navia wrote:
> Le 23/02/2014 14:59, James Kanze a écrit :
>
> > On Friday, February 21, 2014 2:51:27 PM UTC, Scott Lurndal wrote:
>
> >
>
> >> man 3 snprintf
>
> >>
>
> >> (Yes, it works fine in C++)
>
> >
>
> > Funny, because it never worked "fine" in C. In C, you use it,
>
> > because there's not really anything else, but C formatted output
>
> > has to be one of the worst designs ever.
>
> >
>
>
>
> Of course. For instance in the evil C language you use:
>
> printf("0x%08x\n", x);
>
> In the much more advanced C++ language you use:
>
> std::cout << std::hex << std::setfill('0') << std::setw(8) << x <<
>
> std::dec << std::endl;
>
> Of course C has ONE of the worst designs. But C++ has THE WORST!
>
We've discussed this a hundred times. They both have
weaknesses. The poor performance of iostream implementations
is on my list as far as the C++ weaknesses.
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
==============================================================================
TOPIC: shared_ptr and unique_ptr related question
http://groups.google.com/group/comp.lang.c++/t/ae1f30d2345574fe?hl=en
==============================================================================
== 1 of 3 ==
Date: Fri, Feb 21 2014 5:28 pm
From: somenath
To get some understanding of shared_ptr and unique_ptr I wrote the following naive implementation of linked list.
#include<memory>
using namespace std;
template <class T>
class List {
private:
class ListItem {
public:
ListItem( T Val );
shared_ptr <ListItem > Next;
T Data;
};
shared_ptr< ListItem >Head;
public:
int CreateNode();
List() {
Head.reset();
}
void PushBack(T Val);
void Dump();
};
template<class T>
List<T>::ListItem::ListItem( T Val):Data(Val) {
Next.reset();
}
template<class T>
void List<T>::PushBack( T val)
{
unique_ptr<ListItem > NewItem (new ListItem(val));
if (!Head ) {
Head = move(NewItem);
}
else {
shared_ptr<ListItem> Curr(Head);
shared_ptr<ListItem> Prev(Head);
while( (Curr) ) {
Prev = Curr;
Curr = Curr->Next;
}
Prev->Next = move(NewItem);
}
}
template<class T>
void List<T>::Dump() {
shared_ptr<ListItem > Curr(Head);
while ( Curr) {
cout<<"Val = "<<Curr->Data<<endl;;
Curr = Curr->Next;
}
}
But I am not very clear of the correct uses of shared_ptr and auto_ptr yet. Could you please comment on the uses of smart pointers in the context of my linked list code. According to my understanding where I do not need to assign smart pointers to other one I use unique_ptr . Is this understanding correct?
Also I am not able to get convinced the benefit of shared_ptr and unique_ptr in the context of my code. I could have used even raw pointers to implement the same without losing much benefit . Is it not the case here?
I can use the above code as
int main(int argc,char *argv[] )
{
unique_ptr< List <int> > ilst (new List<int>());
ilst->PushBack(5);
ilst->PushBack(15);
ilst->PushBack(25);
ilst->Dump();
return 0;
}
Is the benefit of using smart pointers is, ilst need to be freed manually?
Please point me to some real code where smart pointers has been heavily used.
--
Somenath
== 2 of 3 ==
Date: Sat, Feb 22 2014 1:09 am
From: Paavo Helde
somenath <somenathpal@gmail.com> wrote in
news:1b336c7c-f523-4bd8-9ecb-b13145ff6ed1@googlegroups.com:
> class ListItem {
> public:
> ListItem( T Val );
> shared_ptr <ListItem > Next;
> T Data;
>
> };
[...]
> Also I am not able to get convinced the benefit of shared_ptr and
> unique_ptr in the context of my code. I could have used even raw
> pointers to implement the same without losing much benefit . Is it not
> the case here?
Shared pointers are useful when you need to refer to the same object from
different places and you don't have good or natural control over the
lifetime of the object otherwise. So, using them in an implementation
*inside* of a list of items is pretty pointless, as you have noticed
yourself.
A need to refer to the same object from different places in this way
arises only if these are so-called entity objects (maintaining a changing
state) or they are too expensive or too large to copy casually. In both
cases the copy ctor and assignment operator should be absent or at least
not readily accessible, which is in direct violation with your code where
T objects are passed and held by value and copied all over the place.
> Please point me to some real code where smart pointers has been
> heavily used.
Our codebase uses them extensively, but the code is proprietary, sorry.
Mostly it is about maintaining data items in a script language
interpreter.
But take any look of some Windows C++ code using COM (or whatever it is
called this year). The COM objects are reference counted and disposed
when the last reference drops. There is a _com_ptr_t class template
which is used for defining smartpointers, starting from IUnknownPtr and
up to things like MSHTML::IHTMLDocument2Ptr. Any C++ code should use
those smartpointers for accessing COM interfaces (it is possible to do it
the hard C way as well, but this is error-prone, especially when mixed
with C++ exceptions).
Cheers
Paavo
== 3 of 3 ==
Date: Sun, Feb 23 2014 6:10 am
From: James Kanze
On Saturday, February 22, 2014 1:28:19 AM UTC, somenath wrote:
> To get some understanding of shared_ptr and unique_ptr I wrote
> the following naive implementation of linked list.
> #include<memory>
> using namespace std;
> template <class T>
> class List {
> private:
> class ListItem {
> public:
> ListItem( T Val );
> shared_ptr <ListItem > Next;
> T Data;
> };
> shared_ptr< ListItem >Head;
> public:
> int CreateNode();
> List() {
> Head.reset();
> }
> void PushBack(T Val);
> void Dump();
> };
> template<class T>
> List<T>::ListItem::ListItem( T Val):Data(Val) {
> Next.reset();
> }
> template<class T>
> void List<T>::PushBack( T val)
> {
> unique_ptr<ListItem > NewItem (new ListItem(val));
> if (!Head ) {
> Head = move(NewItem);
> }
> else {
> shared_ptr<ListItem> Curr(Head);
> shared_ptr<ListItem> Prev(Head);
> while( (Curr) ) {
> Prev = Curr;
> Curr = Curr->Next;
> }
> Prev->Next = move(NewItem);
> }
> }
> template<class T>
> void List<T>::Dump() {
> shared_ptr<ListItem > Curr(Head);
> while ( Curr) {
> cout<<"Val = "<<Curr->Data<<endl;;
> Curr = Curr->Next;
> }
> }
> But I am not very clear of the correct uses of shared_ptr and
> auto_ptr yet.
Then don't use them. They're useful for some special cases; if
your use corresponds to one of those special cases, fine, but if
not, don't use them. Using them for memory contained in a
larger entity, like a list, is an anti-pattern.
Take a look at the implementations of the standard containers.
None of them use any classical smart pointers. (Most do use
private base classes to ensure correct destruction of partially
constructed objects. This is another technique, perhaps more
applicable to container classes in general.)
--
James
==============================================================================
TOPIC: OT: Problem building libc++
http://groups.google.com/group/comp.lang.c++/t/177ee9b847d7540f?hl=en
==============================================================================
== 1 of 2 ==
Date: Sat, Feb 22 2014 12:01 pm
From: woodbrian77@gmail.com
On Friday, February 21, 2014 8:50:41 AM UTC-6, Scott Lurndal wrote:
> >http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCYQFjAA&url=http%3A%2F%2Fwiki.osdev.org%2FLibsupcxx&ei=o2YHU72EO4ex2wX2koDAAQ&usg=AFQjCNF6KTOFeb5SBX6SBywdREYfhy63ng
>
> http://webcache.googleusercontent.com/search?q=cache:4D214uOlD3QJ:wiki.osdev.org/Libsupcxx+
>
> $ locate libsup
> /usr/lib/gcc/x86_64-redhat-linux/4.4.4/libsupc++.a
>
OK, thanks. I looked at that and wasn't making much
progress with it so I decided to install Arch linux.
That was a little bit of a pain, but I got it and
it has clang 3.4 as it's default version.
== 2 of 2 ==
Date: Sat, Feb 22 2014 2:34 pm
From: woodbrian77@gmail.com
On Saturday, February 22, 2014 2:01:50 PM UTC-6, woodb...@gmail.com wrote:
>
> OK, thanks. I looked at that and wasn't making much
> progress with it so I decided to install Arch linux.
> That was a little bit of a pain, but I got it and
> it has clang 3.4 as it's default version.
This tripped me up so am adding a note about it here.
It wasn't enough to do
pacman -S clang
. I also had to do
pacman -S libc++
and link with libc++abi (-lc++abi)
.
Tomorrow I may try installing gcc 4.9. Previously
when installing a gcc snapshot, I'd install gmp,
mpfr and mpc. Now it looks like there's another
library called "elf" that needs to be installed?
Brian
Ebenezer Enterprises - Remembering the Alamo.
http://webEbenezer.net
==============================================================================
TOPIC: RICHARD LEAKEY IN PRISON -- THE THRINAXODON TIMES
http://groups.google.com/group/comp.lang.c++/t/b39dd6c751c33948?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Feb 22 2014 5:47 pm
From: "TERMINATOR OF TALK.ORIGINS"
==================
> BREAKING NEWS!!!!
==================
>
RICHARD LEAKEY RECENTLY SENT TO PRISON AFTER BEING CAUGHT SCAMMING
MILLIONS OF YOUNG PEOPLE INTO THE SCAM OF EVOLUTION.
>
THRINAXODON, WHO WAS THE LEAD PROSECUTOR SAID THIS TO THE NY TIMES:
It strikes me silly that one of the world's leading
evolutionary charlatans finally get put into the place they deserve: PRISON
I've been trying FOR YEARS TO GET THESE BASTARDS (LEAKEY, DAWKINS, ETC.)
FOR YEARS INTO TOP-MAX PRISONS. ONE HAS FINALLY BEEN SENT, RICHARD
LEAKEY. May the rest of the charlatans fall? Who knows. But, this is a
warning to all con artists making a buck out of taking peoples souls
(e.g. evolutionary bullshit).
>
LEAKEY WAS SENTENCED TO THREE LIFE SENTENCES AND NO CHANCE OF BAIL.
THRINAXODON LED A MOB OF 3,000,000 PEOPLE TO THE PRISON, AND WE ALL
CHEERED WITH HAPPINESS THAT OUR KIDS WILL NO LONGER BE FORCED-FED BULLSHIT!
>
======================================
EVIDENCE THAT HUMANS LIVED IN THE DEVONIAN:
https://groups.google.com/group/sci.bio.paleontology/browse_thread/thread/6f501c469c7af24f#
https://groups.google.com/group/sci.bio.paleontology/browse_thread/thread/3aad75c16afb0b82#
====================================
http://thrinaxodon.wordpress.com/
===================================
THRINAXODON ONLY HAD THIS TO SAY:
"I..I...I...Can't believe it. This completely disproved Darwinian
orthodoxy."
===================================
THE BASTARDS AT THE SMITHSONIAN, AND THE LEAKEY FOUNDATION ARE ERODING
WITH FEAR.
===========================
THESE ASSHOLES ARE GOING TO DIE:
THOMAS AQUINAS;
ALDOUS HUXLEY;
BOB CASANVOVA;
SkyEyes;
DAVID IAIN GRIEG;
MARK ISAAK;
JOHN HARSHAM;
RICHARD NORMAN;
DR. DOOLITTLE;
CHARLES DARWIN;
MARK HORTON;
ERIK SIMPSON;
HYPATIAB7;
PAUL J. GANS;
JILLERY;
WIKI TRIK;
THRINAXODON;
PETER NYIKOS;
RON OKIMOTO;
JOHN S. WILKINS
===========================
THRINAXODON WAS SCOURING ANOTHER DEVONIAN FOSSIL BED, AND FOUND A
HUMAN SKULL, AND A HUMAN FEMUR. HE ANALYSED THE FINDS, AND SAW THAT
THEY WERE NOT NORMAL ROCKS. THESE WERE FOSSILIZED BONES. THEY EVEN HAD
TOOTH MARKS ON THEM. SO, THRINAXODON BROUGHT THEM TO THE LEAKEY
FOUNDATION, THEY UTTERLY DISMISSED IT, AND SAID, "We want to keep
people thinking that humans evolved 2 Ma." THRINAXODON BROUGHT HIS
SWORD, AND SAID, "SCIENCE CORRECTS ITSELF." RICHARD LEAKEY SAID, "That
is a myth, for people to believe in science." THRINAXODON PLANS TO
BRING DOOM TO SCIENCE, ITSELF.
============================
THRINAXODON IS NOW ON TWITTER
--
Thrinaxodon, the ultimate defender of USENET.
==============================================================================
TOPIC: hw to get started
http://groups.google.com/group/comp.lang.c++/t/1a1994fe83f96e2f?hl=en
==============================================================================
== 1 of 3 ==
Date: Sun, Feb 23 2014 1:20 am
From: erson212
Please can some 1 tell me hw to get started with c++, first tin to du
== 2 of 3 ==
Date: Sun, Feb 23 2014 7:12 am
From: Victor Bazarov
On 2/23/2014 4:20 AM, erson212 wrote:
> Please can some 1 tell me hw to get started with c++, first tin to du
>
Since C++ is an exact language (has a grammar, keywords that need to be
spelled correctly, and is case-sensitive), the first thing to do is to
*commit* to doing it and doing it *properly*. You can demonstrate that
you have achieved the first stage when you learn to use proper grammar,
syntax, punctuation in *all* that you write, *including* any posts on
Usenet. Can you do that?
V
--
I do not respond to top-posted replies, please don't ask
== 3 of 3 ==
Date: Sun, Feb 23 2014 9:49 am
From: woodbrian77@gmail.com
On Sunday, February 23, 2014 3:20:06 AM UTC-6, erson212 wrote:
> Please can some 1 tell me hw to get started with c++, first tin to du
Buy a book or two. Get access to at least one C++ compiler.
Linux makes it fairly easy to use several compilers. You're
also welcome to download the archive on my website;
http://webEbenezer.net/build_integration.html
I've been working on the software there since 1999.
I recall Jorgen mentioning in a similar question the need
to write and read a lot of software. That's right I suppose.
Brian
Ebenezer Enterprises - So far G-d has helped us.
http://webEbenezer.net
==============================================================================
TOPIC: IO problem
http://groups.google.com/group/comp.lang.c++/t/1627ad3e27ed2570?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Feb 23 2014 6:39 am
From: James Kanze
On Wednesday, February 19, 2014 2:29:18 PM UTC, nvangogh wrote:
> I have come to a question in C++ Primer (p 314 , exercise 8.1) that is
> not clear to me.
> "Write a function that takes and returns an istream&. The function
> should read the stream until it hits end-of-file. The function should
> print what it reads to the standard output. Reset the stream so that it
> is valid before returning the stream."
This doesn't sound to clear to me either. For the most part,
istream input is formatted, so a lot of the characters don't
appear. I'm not too sure what you're supposed to be reading.
If it's ints, for example:
int i;
while ( file >> i && ! file.eof() ) {
if ( ! file ) {
file.clear();
file.ignore(); // but what, and how far?
} else {
std::cout << i << std::endl;
}
}
But of course, this will not reproduce the white space of the
original file. Otherwise:
std::cout << file.rdbuf();
sounds like the complete solution to the problem (but it's not
the sort of answer I'd expect from an introductory text).
> Breaking this down, the function has to do three things:
> 1. Read a stream until it hits end-of-file
Which is already a bit questionable. Normally, you read until
the read fails. Which can be because of end-of-file, but can
also be for other reasons.
> So the >> operator reads input from an istream object - cin.
> This stream's end of file can be interrogated by
> cin.eof().
Not really. The eof function is a bit tricky, in that its
return value reflects, or can reflect, internal state which
isn't well defined. Generally, you would never use cin.eof()
until input had failed.
> This returns true if the end of file bit is set which can be
> tested with a bool variable
> bool on = false;
> on = cin.eof();
> if(on == true)
> // end of file is reached, else
> if(on ==false)
> // keep reading cin
> I don't believe that this is completely correct so can someone show me
> how this code should be presented?
It's not completely correct, or at least, it's not complete.
cin.eof() does return the status of the eofbit. But when the
eofbit is set depends on a number of things, and it isn't
reliable unless an input has failed (and not always then).
The usual idiom is:
while ( std::cin >> something ) // ...
or (for lines):
while ( std::getline( std::cin, line ) // ...
(where line has type std::string).
After failure, you can use std::cin.eof() to determine whether
the failure is due to end of file, or something else. (In the
case of std::getline, it will almost certainly be end of file.)
> 2. Print what is read to the standard output
> I can only imagine this to be cout << ? But am lost from here
std::cout << will do the trick. But in the two while loops
above, the >> operator or getline will have removed characters
(white space or the new line character )from the input, that you
won't ever see.
The one exception is << from a streambuf. Using it is the
idiomatic way of copying one stream to another in C++. But it
represents a special case, which violates most of the usual
rules.
> 3. Reset the stream so it is valid before returning the stream
> This section of the problem again defeats me.
Again, it's not clear what this is supposed to mean. If the
input stream is a file (e.g. std::cin), there's practically no
way of doing this. std::cin.clear() will set the state to
good(), but since you've seen end of file, the next read will
immediately fail (or not, depending on the
implementation---there's a lot which isn't well defined here).
Or... it may mean you have to rewind (seek to the beginning of
the file). But this won't be possible if the input is from a
keyboard. And of course, if you've used std::cout <<
file.rdbuf(), the input stream won't have seen anything, and
will still be in its orginal state (but trying to read from it
will still fail, because the underlying streambuf is at end of
file).
--
James
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en
To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment