comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Boost - 12 messages, 5 authors
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
* goto label inside of if statement - 8 messages, 6 authors
http://groups.google.com/group/comp.lang.c++/t/7c222b0d5330287c?hl=en
* C++ is hard (Google game) - 6 messages, 5 authors
http://groups.google.com/group/comp.lang.c++/t/dac6864900693dc7?hl=en
==============================================================================
TOPIC: Boost
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
==============================================================================
== 1 of 12 ==
Date: Sat, Jan 25 2014 4:21 pm
From: Jorgen Grahn
On Sat, 2014-01-25, Öö Tiib wrote:
> On Saturday, 25 January 2014 18:57:08 UTC+2, Jorgen Grahn wrote:
...
>> It seems to me the way [many] Boost libraries fail to document
>> themselves is that the actual /work/ the library does is hard to
>> explain. It's not primarily about writing skills.
>
> Then it may help if you try to be more specific what you mean.
> See: http://www.boost.org/doc/libs/1_55_0/libs/libraries.htm
> What percentage of listed libraries is so difficult to understand
> like you describe?
I can't give you a percentage, but I note that I have Bjarne
Stroustrup on my side. See his FAQ.
> Can't be most of those. I also see that there
> are things with rare specific usage or things that are obsolete
> thanks to C++11. Rest of libraries still seem useful.
Oh, I don't claim they aren't /useful/. They probably are -- but
there are so many complications to get past!
I used to feel the same way about the STL, fifteen years ago or so.
Iterators, the begin--end idiom ... that was stuff that I needed to
think about for some weeks or months before I "got" it and could use
it. The difference being that's stuff that's useful daily, in any
program. I'd prefer not to spend that kind of effort on every Boost
library which might or might not be useful to me.
Perhaps there should be "for dummies" Boost interfaces which are
simpler and cover what 99% of us need to do. Then if we max our those
interfaces we can turn to the "real" ones.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 2 of 12 ==
Date: Sun, Jan 26 2014 1:02 am
From: "Alf P. Steinbach"
* Onoto Winnemucca a.k.a. user.speranza.aioe.org:
>
> Am I those people too?
To the casual reader:
The above was posted in reply to Jorgen Grahn's reply to Oscar Chesnutt
a.k.a. user.speranza.aioe.org, and looking at the article references all
the way up to the start of the thread, every second article is by
user.speranza.aioe.org, posting under various fictitious names.
So, we're dealing with a childish troll.
May be relevant, or not:
<url: https://www.google.com/search?q=Michael+"Snit"+Glasser>
Cheers & hth.,
- Alf
== 3 of 12 ==
Date: Sun, Jan 26 2014 1:34 am
From: Onoto Winnemucca
Alf P. Steinbach wrote:
> * Onoto Winnemucca a.k.a. user.speranza.aioe.org:
>>
>> Am I those people too?
>
> To the casual reader:
>
> The above was posted in reply to Jorgen Grahn's reply to Oscar Chesnutt
> a.k.a. user.speranza.aioe.org, and looking at the article references all
> the way up to the start of the thread, every second article is by
> user.speranza.aioe.org, posting under various fictitious names.
>
> So, we're dealing with a childish troll.
>
> May be relevant, or not:
>
> <url: https://www.google.com/search?q=Michael+"Snit"+Glasser>
Another smart-ass wannabe. I am you too. I am your clone. I have your eyes.
Have you a reading disability, not seeing they are completely different
users, different user-agents and other things, posting through aioe.org
public server? There are millions of them.
More likely you are just stupid, or convincingly try to mimic one.
== 4 of 12 ==
Date: Sun, Jan 26 2014 1:41 am
From: Onoto Winnemucca
Jorgen Grahn wrote:
>> You must be a big magician otherwise, with remote-viewing capabilities
>> and so on. Am I those people too?
>
> Yes, as far as I can tell you are -- your style shines through. Please
> stop doing this. You're not five years old; it's silly, and if you
> think about it, it doesn't help you or anyone else.
You looks like an idiot. I must be you too.
Sincerely, me.
== 5 of 12 ==
Date: Sun, Jan 26 2014 1:47 am
From: Onoto Winnemucca
Jorgen Grahn wrote:
>> Then it may help if you try to be more specific what you mean. See:
>> http://www.boost.org/doc/libs/1_55_0/libs/libraries.htm What percentage
>> of listed libraries is so difficult to understand like you describe?
>
> I can't give you a percentage, but I note that I have Bjarne Stroustrup
> on my side. See his FAQ.
I am convinced then. Who else do you know, Bill Gates, Linus Torvalds?
== 6 of 12 ==
Date: Sun, Jan 26 2014 6:59 am
From: Öö Tiib
On Sunday, 26 January 2014 02:21:00 UTC+2, Jorgen Grahn wrote:
> On Sat, 2014-01-25, Öö Tiib wrote:
>
> > Then it may help if you try to be more specific what you mean.
> > See: http://www.boost.org/doc/libs/1_55_0/libs/libraries.htm
> > What percentage of listed libraries is so difficult to understand
> > like you describe?
>
> I can't give you a percentage, but I note that I have Bjarne
> Stroustrup on my side. See his FAQ.
Stroustrup does say that some of it is too coupled and some of
it is too complex but it is bad idea to reinvent wheel if that is
already in boost (or in C++11).
> > Can't be most of those. I also see that there
> > are things with rare specific usage or things that are obsolete
> > thanks to C++11. Rest of libraries still seem useful.
>
> Oh, I don't claim they aren't /useful/. They probably are -- but
> there are so many complications to get past!
The complications arise from attempt to address boost as a whole.
It is *not* a whole. It is a lot of different purpose libraries. It is net
total 15 millions lines of code. So one approaching it *must* put on
heavy filters.
> I used to feel the same way about the STL, fifteen years ago or so.
> Iterators, the begin--end idiom ... that was stuff that I needed to
> think about for some weeks or months before I "got" it and could use
> it. The difference being that's stuff that's useful daily, in any
> program. I'd prefer not to spend that kind of effort on every Boost
> library which might or might not be useful to me.
Such major effort is likely overkill. Learn about a library in boost when
you need something like that. If it looks like overly complex then
look for alternatives.
> Perhaps there should be "for dummies" Boost interfaces which are
> simpler and cover what 99% of us need to do. Then if we max our those
> interfaces we can turn to the "real" ones.
When there is big amount of things from different authors for various
purposes then that can not be likely made uniform, simple and easy to
access for dummies.
== 7 of 12 ==
Date: Sun, Jan 26 2014 7:57 am
From: woodbrian77@gmail.com
On Sunday, January 26, 2014 8:59:49 AM UTC-6, Öö Tiib wrote:
> On Sunday, 26 January 2014 02:21:00 UTC+2, Jorgen Grahn wrote:
> >
>
> > I can't give you a percentage, but I note that I have Bjarne
> > Stroustrup on my side. See his FAQ.
>
> Stroustrup does say that some of it is too coupled and some of
> it is too complex but it is bad idea to reinvent wheel if that is
> already in boost (or in C++11).
Hmm. There's also case where two approaches cover same
area, but they do so through different means. For
example, the serialization library in Boost uses C++
compiler based code generation and the C++ Middleware
Writer (CMW) is an external code generator.
If I took too literally your advice, I wouldn't have
developed CMW and imo C++ wouldn't have advantage over
other languages that CMW provides. CMW provides
automation of serialization like C# and Java, but
it goes beyond that in terms of being an on line
code generator.
>
> > > Can't be most of those. I also see that there
> > > are things with rare specific usage or things that are obsolete
> > > thanks to C++11. Rest of libraries still seem useful.
> >
>
> > Oh, I don't claim they aren't /useful/. They probably are -- but
> > there are so many complications to get past!
>
> The complications arise from attempt to address boost as a whole.
> It is *not* a whole. It is a lot of different purpose libraries. It is net
> total 15 millions lines of code. So one approaching it *must* put on
> heavy filters.
Yes.
>
> > I used to feel the same way about the STL, fifteen years ago or so.
> > Iterators, the begin--end idiom ... that was stuff that I needed to
> > think about for some weeks or months before I "got" it and could use
> > it. The difference being that's stuff that's useful daily, in any
> > program. I'd prefer not to spend that kind of effort on every Boost
> > library which might or might not be useful to me.
>
> Such major effort is likely overkill. Learn about a library in boost when
> you need something like that. If it looks like overly complex then
> look for alternatives.
I have spent some days getting acquainted with a Boost
library only to eventually find what I considered to
be a serious flaw. This can happen with any library
regardless of it being in Boost or not.
>
> > Perhaps there should be "for dummies" Boost interfaces which are
> > simpler and cover what 99% of us need to do. Then if we max our those
> > interfaces we can turn to the "real" ones.
>
> When there is big amount of things from different authors for various
> purposes then that can not be likely made uniform, simple and easy to
> access for dummies.
"A fool with a plan can outsmart a genius with no plan."
T. Boone Pickens
Some of Boost is genius with no plan... Frankenstein.
Brian
Ebenezer Enterprises - "Where there is no revelation,
people cast off restraint; but blessed is the one who
heeds wisdom's instruction." Proverbs 29:18
http://webEbenezer.net
== 8 of 12 ==
Date: Sun, Jan 26 2014 9:08 am
From: Öö Tiib
On Sunday, 26 January 2014 17:57:02 UTC+2, woodb...@gmail.com wrote:
> On Sunday, January 26, 2014 8:59:49 AM UTC-6, Öö Tiib wrote:
> > On Sunday, 26 January 2014 02:21:00 UTC+2, Jorgen Grahn wrote:
> > >
> > > I can't give you a percentage, but I note that I have Bjarne
> > > Stroustrup on my side. See his FAQ.
> >
> > Stroustrup does say that some of it is too coupled and some of
> > it is too complex but it is bad idea to reinvent wheel if that is
> > already in boost (or in C++11).
>
> Hmm. There's also case where two approaches cover same
> area, but they do so through different means.
Yes. We can always try to do same thing differently.
There's always some yet another way. However no one
has time to try all ways out.
> If I took too literally your advice, I wouldn't have
> developed CMW and imo C++ wouldn't have advantage over
> other languages that CMW provides. CMW provides
> automation of serialization like C# and Java, but
> it goes beyond that in terms of being an on line
> code generator.
Who knows? It may be that if you had taken my advice
literally then may be you would have developed some
other tool to some less or more full market that is less
or more outstanding from crowd. That we can never
tell.
About Java, C# or Python ... we often need to interoperate
with programs written in other languages indeed, but that
is not what your CMW helps with?
> I have spent some days getting acquainted with a Boost
> library only to eventually find what I considered to
> be a serious flaw. This can happen with any library
> regardless of it being in Boost or not.
More people look and try and use boost. So the defects
will be found and eventually repaired. That is one of the
strengths of boost.
== 9 of 12 ==
Date: Sun, Jan 26 2014 9:51 am
From: woodbrian77@gmail.com
On Sunday, January 26, 2014 11:08:07 AM UTC-6, Öö Tiib wrote:
> On Sunday, 26 January 2014 17:57:02 UTC+2, woodb...@gmail.com wrote:
>
> > On Sunday, January 26, 2014 8:59:49 AM UTC-6, Öö Tiib wrote:
> >
>
> > Hmm. There's also case where two approaches cover same
> > area, but they do so through different means.
>
> Yes. We can always try to do same thing differently.
> There's always some yet another way. However no one
> has time to try all ways out.
>
"Unless the L-rd builds the house, they labor in
vain who build it. Unless the L-rd guards the city,
the watchman waketh but in vain.' Psalms 127:1
> > If I took too literally your advice, I wouldn't have
> > developed CMW and imo C++ wouldn't have advantage over
> > other languages that CMW provides. CMW provides
> > automation of serialization like C# and Java, but
> > it goes beyond that in terms of being an on line
> > code generator.
>
> Who knows? It may be that if you had taken my advice
> literally then may be you would have developed some
> other tool to some less or more full market that is less
> or more outstanding from crowd. That we can never
> tell.
>
> About Java, C# or Python ... we often need to interoperate
> with programs written in other languages indeed, but that
> is not what your CMW helps with?
>
Other serialization libraries are also focused on C++.
Corba takes language neutral approach. Is it thriving?
I tend to think it is stagnant and dying.
My approach is to focus first on C++. After dust
settles, I hope to provide support for one or two other
languages. C++ is most important language for services,
so good place to start.
> > I have spent some days getting acquainted with a Boost
> > library only to eventually find what I considered to
> > be a serious flaw. This can happen with any library
> > regardless of it being in Boost or not.
>
> More people look and try and use boost. So the defects
> will be found and eventually repaired. That is one of the
> strengths of boost.
Don't hold your breath if you have requests for some
libraries. The maintenance can be very thin.
Brian
Ebenezer Enterprises
http://webEbenezer.net
== 10 of 12 ==
Date: Sun, Jan 26 2014 10:14 am
From: woodbrian77@gmail.com
On Sunday, January 26, 2014 11:51:49 AM UTC-6, woodb...@gmail.com wrote:
> On Sunday, January 26, 2014 11:08:07 AM UTC-6, Öö Tiib wrote:
>
> > About Java, C# or Python ... we often need to interoperate
> > with programs written in other languages indeed, but that
> > is not what your CMW helps with?
>
>
> Other serialization libraries are also focused on C++.
> Corba takes language neutral approach. Is it thriving?
> I tend to think it is stagnant and dying.
>
> My approach is to focus first on C++. After dust
> settles, I hope to provide support for one or two other
> languages. C++ is most important language for services,
> so good place to start.
>
I looked into Java a number of years ago and found
it's requirement for a class to be in only one file
to be antithetical to code generation.
So I would guess the second language we'll support
will be either C# or Python.
Brian
Ebenezer Enterprises
http://webEbenezer.net
== 11 of 12 ==
Date: Sun, Jan 26 2014 11:00 am
From: Öö Tiib
On Sunday, 26 January 2014 19:51:49 UTC+2, woodb...@gmail.com wrote:
> On Sunday, January 26, 2014 11:08:07 AM UTC-6, Öö Tiib wrote:
> > About Java, C# or Python ... we often need to interoperate
> > with programs written in other languages indeed, but that
> > is not what your CMW helps with?
>
> Other serialization libraries are also focused on C++.
> Corba takes language neutral approach. Is it thriving?
> I tend to think it is stagnant and dying.
If someone asks for C++ solution for serialization then he
gets lot of answers like protocol buffers, jsoncpp,
codesynthesis xsd, tinyxml, boost serialize, and so
on. Like you see all are capable to serialize into language
neutral formats. Other languages have same or
different tools for serialization since what matters is
the format.
> My approach is to focus first on C++. After dust
> settles, I hope to provide support for one or two other
> languages. C++ is most important language for services,
> so good place to start.
Lot of network services are not written in C++. I trust majority.
> > More people look and try and use boost. So the defects
> > will be found and eventually repaired. That is one of the
> > strengths of boost.
>
> Don't hold your breath if you have requests for some
> libraries. The maintenance can be very thin.
I speak of experience. Boost tends to have lower amount of
defects than other C++ libraries. If there is a defect then it is
usually fixed soon and also workaround is found. Anyway if
it looks too complex for me to fix it myself then I avoid it.
== 12 of 12 ==
Date: Sun, Jan 26 2014 1:27 pm
From: woodbrian77@gmail.com
On Sunday, January 26, 2014 1:00:37 PM UTC-6, Öö Tiib wrote:
> On Sunday, 26 January 2014 19:51:49 UTC+2, woodb...@gmail.com wrote:
>
> > Other serialization libraries are also focused on C++.
> > Corba takes language neutral approach. Is it thriving?
> > I tend to think it is stagnant and dying.
>
> If someone asks for C++ solution for serialization then he
> gets lot of answers like protocol buffers, jsoncpp,
> codesynthesis xsd, tinyxml, boost serialize, and so
The C++ Middleware Writer has support for serializing
some of Boost. G-d willing we'll add support for other
types in the future including more of Boost. It will
depend on the needs of users.
> on. Like you see all are capable to serialize into language
> neutral formats. Other languages have same or
> different tools for serialization since what matters is
> the format.
>
I'm talking about binary serialization here.
> > My approach is to focus first on C++. After dust
> > settles, I hope to provide support for one or two other
> > languages. C++ is most important language for services,
> > so good place to start.
>
> Lot of network services are not written in C++.
>
Do you disagree with my claim that C++ is most important
language for services?
>
> > Don't hold your breath if you have requests for some
> > libraries. The maintenance can be very thin.
>
> I speak of experience. Boost tends to have lower amount of
> defects than other C++ libraries. If there is a defect then it is
> usually fixed soon and also workaround is found.
Some of Boost is as you describe. Other parts don't
get much love.
Brian
Ebenezer Enterprises
http://webEbenezer.net
==============================================================================
TOPIC: goto label inside of if statement
http://groups.google.com/group/comp.lang.c++/t/7c222b0d5330287c?hl=en
==============================================================================
== 1 of 8 ==
Date: Sat, Jan 25 2014 4:36 pm
From: Mr Flibble
On 25/01/2014 22:59, Tobias Müller wrote:
> Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote:
>> Like it or not you are already using exceptions as 'new' can throw a
>> 'std::bad_alloc' exception.
>
> Except 'new (nothrow)'.
Which means checking for null pointers with if statements all over your
code and trying to decide what to do all over your code.
/Flibble
== 2 of 8 ==
Date: Sun, Jan 26 2014 1:51 am
From: Tobias Müller
Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote:
> On 25/01/2014 22:59, Tobias Müller wrote:
>> Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote:
>>> Like it or not you are already using exceptions as 'new' can throw a
>>> 'std::bad_alloc' exception.
>>
>> Except 'new (nothrow)'.
>
> Which means checking for null pointers with if statements all over your
> code and trying to decide what to do all over your code.
That's what propagation of error codes/error values means. It's tedious but
certainly possible.
Tobi
== 3 of 8 ==
Date: Sun, Jan 26 2014 8:03 am
From: Mr Flibble
On 26/01/2014 09:51, Tobias Müller wrote:
> Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote:
>> On 25/01/2014 22:59, Tobias Müller wrote:
>>> Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote:
>>>> Like it or not you are already using exceptions as 'new' can throw a
>>>> 'std::bad_alloc' exception.
>>>
>>> Except 'new (nothrow)'.
>>
>> Which means checking for null pointers with if statements all over your
>> code and trying to decide what to do all over your code.
>
> That's what propagation of error codes/error values means. It's tedious but
> certainly possible.
It is also possible for a person to be insane.
/Flibble
== 4 of 8 ==
Date: Sun, Jan 26 2014 11:13 am
From: Jax
Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote in
news:3dqdne8xsb8OxXnPnZ2dnUVZ8kadnZ2d@giganews.com:
> On 25/01/2014 22:59, Tobias Müller wrote:
>> Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote:
>>> Like it or not you are already using exceptions as 'new' can throw a
>>> 'std::bad_alloc' exception.
>>
>> Except 'new (nothrow)'.
>
> Which means checking for null pointers with if statements all over your
> code and trying to decide what to do all over your code.
>
> /Flibble
Flibble I am very new to C++ and would like to get your recommendation. Do
you mean that GOTO shouldn't ever be used or is it okay in certain
circumstances?
--
Jax :)
== 5 of 8 ==
Date: Sun, Jan 26 2014 12:11 pm
From: Mr Flibble
On 26/01/2014 19:13, Jax wrote:
> Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote in
> news:3dqdne8xsb8OxXnPnZ2dnUVZ8kadnZ2d@giganews.com:
>
>> On 25/01/2014 22:59, Tobias Müller wrote:
>>> Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote:
>>>> Like it or not you are already using exceptions as 'new' can throw a
>>>> 'std::bad_alloc' exception.
>>>
>>> Except 'new (nothrow)'.
>>
>> Which means checking for null pointers with if statements all over your
>> code and trying to decide what to do all over your code.
>>
>> /Flibble
>
> Flibble I am very new to C++ and would like to get your recommendation. Do
> you mean that GOTO shouldn't ever be used or is it okay in certain
> circumstances?
'goto' should only be used to break out of nested loops.
/Flibble
== 6 of 8 ==
Date: Sun, Jan 26 2014 12:27 pm
From: Öö Tiib
On Sunday, 26 January 2014 21:13:22 UTC+2, Jax wrote:
> Do you mean that GOTO shouldn't ever be used or is it okay in certain
> circumstances?
One is certain that C++ programs can be written without using 'goto'
because there are large C++ code-bases (millions of lines) without a
single 'goto' in them.
Goto may cause that program logic is hard to understand. However
the silly tricks with loops, switches, continues or break's that I have
seen sometimes written for emulating goto are even worse. So if you
ever feel that you need to write tricky code to avoid goto then better
use goto.
== 7 of 8 ==
Date: Sun, Jan 26 2014 1:22 pm
From: Paavo Helde
Jax <remove.bear.bottoms1@gmail.com> wrote in
news:XnsA2C1C38BC1524JAX@127.0.0.1:
> Flibble I am very new to C++ and would like to get your
> recommendation. Do you mean that GOTO shouldn't ever be used or is it
> okay in certain circumstances?
As with all features, one uses goto if it is better than the alternatives.
And "better" here means primarily more readable and maintainable code.
Breaking out of deep nested loops with goto to near the beginning or the
end of a function is IMO okay, as the relevant state of the program after
the jump is pretty clear in such cases.
The same functionality can be always achieved with reorganizing the code,
possibly splitting it into multiple functions. Whether this makes the code
more readable and maintainable than 'goto' depends on the circumstances and
also on the taste (of the future readers and maintainers in particular). So
there is no clear-cut answer. One thing is clear, the need for 'goto' is
rare, if you find yourself writing a goto every week then something is
probably wrong.
HTH
Paavo
== 8 of 8 ==
Date: Sun, Jan 26 2014 1:32 pm
From: Gareth Owen
Paavo Helde <myfirstname@osa.pri.ee> writes:
> Jax <remove.bear.bottoms1@gmail.com> wrote in
> news:XnsA2C1C38BC1524JAX@127.0.0.1:
>
>
>> Flibble I am very new to C++ and would like to get your
>> recommendation. Do you mean that GOTO shouldn't ever be used or is it
>> okay in certain circumstances?
>
> As with all features, one uses goto if it is better than the
> alternatives. And "better" here means primarily more readable and
> maintainable code. Breaking out of deep nested loops with goto to
> near the beginning or the end of a function is IMO okay, as the
> relevant state of the program after the jump is pretty clear in such
> cases.
>
> The same functionality can be always achieved with reorganizing the
> code, possibly splitting it into multiple functions. Whether this
> makes the code more readable and maintainable than 'goto' depends on
> the circumstances and also on the taste (of the future readers and
> maintainers in particular). So there is no clear-cut answer. One thing
> is clear, the need for 'goto' is rare, if you find yourself writing a
> goto every week then something is probably wrong.
Jax,
Take Paavo's advice and memorise it.
You'll not find it a better argument more cogently stated.
If you remember nothing else, remember the first sentence.
==============================================================================
TOPIC: C++ is hard (Google game)
http://groups.google.com/group/comp.lang.c++/t/dac6864900693dc7?hl=en
==============================================================================
== 1 of 6 ==
Date: Sun, Jan 26 2014 12:12 pm
From: Mr Flibble
Google: "Why is [language] so..."
Javascript: popular
Java: popular
Python: popular
Perl: ugly
R: slow
Ruby: slow
Fortran: fast
C++: hard
/Flibble
== 2 of 6 ==
Date: Sun, Jan 26 2014 12:26 pm
From: woodbrian77@gmail.com
On Sunday, January 26, 2014 2:12:43 PM UTC-6, Mr Flibble wrote:
> Google: "Why is [language] so..."
>
> Javascript: popular
> Java: popular
> Python: popular
> Perl: ugly
> R: slow
> Ruby: slow
> Fortran: fast
> C++: hard
>
Duckduckgo says C++ is fast and complicated:
https://duckduckgo.com/?q=%22why+is+C%2B%2B+so%22
Brian
Ebenezer Enterprises
http://webEbenezer.net
== 3 of 6 ==
Date: Sun, Jan 26 2014 12:51 pm
From: Öö Tiib
On Sunday, 26 January 2014 22:12:43 UTC+2, Mr Flibble wrote:
> Google: "Why is [language] so..."
> Javascript: popular
> Java: popular
> Python: popular
> Perl: ugly
> R: slow
> Ruby: slow
> Fortran: fast
> C++: hard
I typed the text and google suggested first in drop down:
Javascript: why is javascript v8 so fast
Java: why is javascript so popular
Python: why is python documentation so bad
Perl: why is perl 6 taking so long
R: why is runescape so laggy
Ruby: why is ruby on rails so popular
Fortran: why is fortran so fast
C++: why is c++ called so
Not sure how google guesses what i want to ask.
== 4 of 6 ==
Date: Sun, Jan 26 2014 1:10 pm
From: Mr Flibble
On 26/01/2014 20:51, Öö Tiib wrote:
> On Sunday, 26 January 2014 22:12:43 UTC+2, Mr Flibble wrote:
>> Google: "Why is [language] so..."
>> Javascript: popular
>> Java: popular
>> Python: popular
>> Perl: ugly
>> R: slow
>> Ruby: slow
>> Fortran: fast
>> C++: hard
>
> I typed the text and google suggested first in drop down:
>
> Javascript: why is javascript v8 so fast
> Java: why is javascript so popular
> Python: why is python documentation so bad
> Perl: why is perl 6 taking so long
> R: why is runescape so laggy
> Ruby: why is ruby on rails so popular
> Fortran: why is fortran so fast
> C++: why is c++ called so
>
> Not sure how google guesses what i want to ask.
You are not playing the game properly.
Google: "Why is [thing] so"
Don't put anything in-between [thing] and "so".
/Flibble
== 5 of 6 ==
Date: Sun, Jan 26 2014 1:26 pm
From: Paavo Helde
Mr Flibble <flibbleREMOVE_THIS_AND_THIS@i42.co.uk> wrote in
news:Xo6dnZ9Z14ai8XjPnZ2dnUVZ8tOdnZ2d@giganews.com:
> Google: "Why is [language] so..."
> C++: hard
To keep us entertained, of course!
== 6 of 6 ==
Date: Sun, Jan 26 2014 1:26 pm
From: Vir Campestris
On 26/01/2014 20:26, woodbrian77@gmail.com wrote:
> Duckduckgo says C++ is fast and complicated:
>
> https://duckduckgo.com/?q=%22why+is+C%2B%2B+so%22
Google tells _me_ it's also hard and popular.
Your answers may vary.
Andy
==============================================================================
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