comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Boost - 10 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
* goto label inside of if statement - 6 messages, 5 authors
http://groups.google.com/group/comp.lang.c++/t/7c222b0d5330287c?hl=en
* C++ is hard (Google game) - 10 messages, 6 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 10 ==
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
== 2 of 10 ==
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.
== 3 of 10 ==
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
== 4 of 10 ==
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
== 5 of 10 ==
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.
== 6 of 10 ==
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
== 7 of 10 ==
Date: Sun, Jan 26 2014 1:34 pm
From: Ian Collins
woodbrian77@gmail.com wrote:
> On Sunday, January 26, 2014 1:00:37 PM UTC-6, Öö Tiib wrote:
>
>>> 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?
While C++ is an important language for services, it has to inter-operate
with servers and clients written in other languages. This is why most
serialisation formats in common use today (SOAP, XML-RPC, JSON) are
textual or binary extensions of them (BSON).
--
Ian Collins
== 8 of 10 ==
Date: Sun, Jan 26 2014 2:18 pm
From: Öö Tiib
On Sunday, 26 January 2014 23:27:36 UTC+2, woodb...@gmail.com wrote:
> 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
> > 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.
The binary formats are less used than text formats when traffic
is small enough. There are plenty of binary formats and most
have C++ or C serialization/deserialization available. Protocol
Buffers have language neutral binary format from above.
Boost Serialization binary format may have differences between
versions of library and it is C++ only. However it may be useful
for usage within single application.
> > > 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?
No. Claiming what is more or less important programming language
misses the point about importance of formats. I was saying that
there are lot of services that are not written in C++. These are
important too and the programs need to interoperate so need to
use common format.
> > 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.
Most of the libraries in Boost seem to be made with love.
== 9 of 10 ==
Date: Sun, Jan 26 2014 2:46 pm
From: woodbrian77@gmail.com
On Sunday, January 26, 2014 3:34:18 PM UTC-6, Ian Collins wrote:
> woodbrian77@gmail.com wrote:
> >
> > Do you disagree with my claim that C++ is most important
> > language for services?
>
> While C++ is an important language for services, it has to inter-operate
> with servers and clients written in other languages.
If you had said --
it sometimes has to inter-operate
I'd agree. I know of a few companies that write C++
programs that communicate with each other. That's
not exactly unheard of.
And as I said I'm open to working on adding support
for another language, but I don't think that language
will be Java. Python or C# is more likely.
> This is why most
> serialisation formats in common use today (SOAP, XML-RPC, JSON) are
> textual or binary extensions of them (BSON).
>
I think scientific apps and games often use binary serialization.
I believe the quality of my software is good and believe
that thinking about the software/service through another
project's eyes will help me to improve the software service.
Brian
Ebenezer Enterprises
http://webEbenezer.net
== 10 of 10 ==
Date: Sun, Jan 26 2014 2:56 pm
From: Ian Collins
woodbrian77@gmail.com wrote:
> On Sunday, January 26, 2014 3:34:18 PM UTC-6, Ian Collins wrote:
>> woodbrian77@gmail.com wrote:
>>>
>>> Do you disagree with my claim that C++ is most important
>>> language for services?
>>
>> While C++ is an important language for services, it has to inter-operate
>> with servers and clients written in other languages.
>
> If you had said --
>
> it sometimes has to inter-operate
>
> I'd agree. I know of a few companies that write C++
> programs that communicate with each other. That's
> not exactly unheard of.
Probably the most common type of "service" these days is the web
service. Web services almost exclusively use SOAP. If you are going to
write the back ends for web pages in C++, you will probably have to use
JSON to communicate with the client JavaScript.
> And as I said I'm open to working on adding support
> for another language, but I don't think that language
> will be Java. Python or C# is more likely.
>
>> This is why most
>> serialisation formats in common use today (SOAP, XML-RPC, JSON) are
>> textual or binary extensions of them (BSON).
>
> I think scientific apps and games often use binary serialization.
>
> I believe the quality of my software is good and believe
> that thinking about the software/service through another
> project's eyes will help me to improve the software service.
By using a proprietary binary format, you are restricting yourself to a
narrow range of applications. The easiest way to support other
languages is to use a well known on wire format.
--
Ian Collins
==============================================================================
TOPIC: goto label inside of if statement
http://groups.google.com/group/comp.lang.c++/t/7c222b0d5330287c?hl=en
==============================================================================
== 1 of 6 ==
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
== 2 of 6 ==
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 :)
== 3 of 6 ==
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
== 4 of 6 ==
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.
== 5 of 6 ==
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
== 6 of 6 ==
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 10 ==
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 10 ==
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 10 ==
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 10 ==
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 10 ==
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 10 ==
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
== 7 of 10 ==
Date: Sun, Jan 26 2014 2:08 pm
From: woodbrian77@gmail.com
On Sunday, January 26, 2014 3:26:15 PM UTC-6, Vir Campestris wrote:
> 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.
>
I think you mean C++ when you say "it's." Duckduckgo
also said those things. I was just giving a summary
of the top two things it came back with.
== 8 of 10 ==
Date: Sun, Jan 26 2014 2:18 pm
From: Richard Damon
On 1/26/14, 3:51 PM, Öö Tiib wrote:
> Not sure how google guesses what i want to ask.
>
If you haven't asked Google a question like this (at least that Google
can match to you now), Google will look at what other people have
entered as search strings. It may also weight them by how similar it
thinks those people are to you.
== 9 of 10 ==
Date: Sun, Jan 26 2014 2:52 pm
From: woodbrian77@gmail.com
On Sunday, January 26, 2014 4:18:46 PM UTC-6, Richard Damon wrote:
> On 1/26/14, 3:51 PM, Öö Tiib wrote:
>
>
> If you haven't asked Google a question like this (at least that Google
> can match to you now), Google will look at what other people have
> entered as search strings. It may also weight them by how similar it
> thinks those people are to you.
I prefer privacy --
http://donttrack.us/
Brian
Ebenezer Enterprises
http://webEbenezer.net
== 10 of 10 ==
Date: Sun, Jan 26 2014 3:04 pm
From: Mr Flibble
On 26/01/2014 22:52, woodbrian77@gmail.com wrote:
> On Sunday, January 26, 2014 4:18:46 PM UTC-6, Richard Damon wrote:
>> On 1/26/14, 3:51 PM, Öö Tiib wrote:
>>
>>
>> If you haven't asked Google a question like this (at least that Google
>> can match to you now), Google will look at what other people have
>> entered as search strings. It may also weight them by how similar it
>> thinks those people are to you.
>
> I prefer privacy --
>
> http://donttrack.us/
>
> Brian
> Ebenezer Enterprises
> http://webEbenezer.net
What dirty little secrets are you hiding?
/Flibble
==============================================================================
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