comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* STL map to STL vector - 10 messages, 7 authors
http://groups.google.com/group/comp.lang.c++/t/1164ef3d2f08f58f?hl=en
* Decoding GIF file in C? [Source code here] - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/dec6ec0426c88c64?hl=en
* Boost - 14 messages, 9 authors
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
==============================================================================
TOPIC: STL map to STL vector
http://groups.google.com/group/comp.lang.c++/t/1164ef3d2f08f58f?hl=en
==============================================================================
== 1 of 10 ==
Date: Thurs, Jan 16 2014 1:36 pm
From: Vir Campestris
On 14/01/2014 21:14, Mr Flibble wrote:
> Actually the benefit of doing 'reserve' diminishes as the number of
> elements increases.
Do you have a source for that?
My understanding is that it will expand the vector - usually by doubling
in size or some such - whenever it gets full. This will require a copy
of every single item (1). Worth avoiding if you can.
Andy
--
(1) Even if it's a move in the new C++11 world it won't be zero cost.
== 2 of 10 ==
Date: Thurs, Jan 16 2014 2:06 pm
From: "Alf P. Steinbach"
On 16.01.2014 22:36, Vir Campestris wrote:
> On 14/01/2014 21:14, Mr Flibble wrote:
>> Actually the benefit of doing 'reserve' diminishes as the number of
>> elements increases.
I don't see Mr Flibble's original article and I suspect that the context
may narrow down what's being discussed, but even as a general statement
that above is correct when just the word "relative" is added or understood.
> Do you have a source for that?
Instead of authority, try logic.
It is after all the greatest authority.
The C++ standard guarantees amortized linear time, O(n), for creating a
vector of n items, i.e. amortized constant time per item. The O(n) time
includes O(n) item moves or copies, plus O(log n) buffer allocations.
The latter contribution diminishes greatly, relative to the total, as n
increases.
> My understanding is that it will expand the vector - usually by doubling
> in size or some such - whenever it gets full.
Yes. This is what guarantees amortized linear time. It might be a
constant factor such as 1.6 instead of 2.0, but assuming a doubling and
starting at buffer size 1, then for n elements you get copy/move time
consumption 1 + 2 + 4 + 8 + ... N, where N is the highest power of 2
that is less than or equal to n, which sum equals 2*N - 1.
> This will require a copy
> of every single item (1). Worth avoiding if you can.
A copy or move. But I agree, it's worth avoiding, e.g. by doing a
reserve, as a matter of course. Still it is true that the relative
benefit of doing that /diminishes/ as Mr. Flibble, alias Leigh "Sausage"
Johnston, wrote (or intended to write, I added "relative").
Cheers & hth.,
- Alf
== 3 of 10 ==
Date: Thurs, Jan 16 2014 2:11 pm
From: Mr Flibble
On 16/01/2014 22:06, Alf P. Steinbach wrote:
> A copy or move. But I agree, it's worth avoiding, e.g. by doing a
> reserve, as a matter of course. Still it is true that the relative
> benefit of doing that /diminishes/ as Mr. Flibble, alias Leigh "Sausage"
> Johnston, wrote (or intended to write, I added "relative").
You are a fucking nutter mate.
/Flibble.
== 4 of 10 ==
Date: Fri, Jan 17 2014 3:38 am
From: Juha Nieminen
Seungbeom Kim <musiphil@bawi.org> wrote:
>> I don't think the standard demands the implementation to be a hash array
>> (even though it demands a hash function to be provided.) The name would
>> be misleading if the internal implementation happened to be something else.
>
> I agree that standard names should not depend on implementation details,
> but what would be so misleading in the name "hash_map" for something
> that "by specification" requires and is organized by a hash function?
Does the standard require for std::unordered_map to use the provided
hash function for something?
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
== 5 of 10 ==
Date: Fri, Jan 17 2014 4:31 am
From: Öö Tiib
On Thursday, 16 January 2014 02:11:37 UTC+2, Seungbeom Kim wrote:
> On 2014-01-15 09:32, �� Tiib wrote:
>
> > On Wednesday, 15 January 2014 18:50:53 UTC+2, woodb...@gmail.com wrote:
> >>
> >> It isn't very descriptive. It's like saying a
> >> marble is not blue. Hash_map would be better.
> >
> > Why? "Hash" sounds like Klingon/Orcish word
> > while every child understands "unordered".
>
> Maybe some children would understand "unordered" as the
> status of their rooms with toys lying all around... :)
Yes and most of the population considers strings as women
underwear. :) I meant children who consider writing software.
On 95% of cases it does not matter to user that it is internally
"splay_tree_multiset" or "hash_table_dictionary" or
"copy_on_write_string". "unordered" is better since it is adjective but
ideal would be to have just "multiset", "dictionary" or "string".
> You need to understand hash containers and hash functions anyway
> to be able to use std::unordered_map effectively, especially on
> your own data type, so having "hash" in the name shouldn't be
> too limiting, no matter how it sounds (especially to children).
All standard library containers have allocator parameter. Most
users of those containers are not too good in memory
management and incapable to develop efficient allocators
because they rarely need to. Same is with hashing. Most map
keys actually used are already hashable. On rare case when
compiler tells that it can't find 'hash<Key>' but it needs one the
people google a bit and write one rather quickly. IOW I don't
see that one must understand details of algorithm or container
overly deeply to use it effectively.
> > On most cases the fact that unordered map is
> > built internally on hash table is as unimportant
> > as the fact that set is built upon red-black tree.
>
> I consider hashing is an important concept in std::unordered_map,
> as I said above. I wouldn't go as far as red-black trees, but actually
> I think I like the name "tree_map"; given the complexity requirements,
> it's almost as if the standard is written with trees as the underlying
> data structure in mind.
>
> The balance in the names "tree_map" and "hash_map" is an added bonus. :)
I think it will be in the future that the types will be (possibly
automatically) configurable. There are some class libraries with heavily
configurable traits already but it is not too convenient to tinker there
(and diagnostics can be ridiculous) right now. That will likely improve
when concepts emerge.
== 6 of 10 ==
Date: Fri, Jan 17 2014 6:28 am
From: Robert Wessel
On Fri, 17 Jan 2014 11:38:20 +0000 (UTC), Juha Nieminen
<nospam@thanks.invalid> wrote:
>Seungbeom Kim <musiphil@bawi.org> wrote:
>>> I don't think the standard demands the implementation to be a hash array
>>> (even though it demands a hash function to be provided.) The name would
>>> be misleading if the internal implementation happened to be something else.
>>
>> I agree that standard names should not depend on implementation details,
>> but what would be so misleading in the name "hash_map" for something
>> that "by specification" requires and is organized by a hash function?
>
>Does the standard require for std::unordered_map to use the provided
>hash function for something?
While I can see being able to search for a pair so long a key_equal is
provided, I'm not sure how you could manage the complexity guarantees
if you ignored hash_function. The problem is when hash_function
preprocesses the key in some way before hashing it (for example, you
might lowercase a string, so that the hash is not case sensitive).
== 7 of 10 ==
Date: Fri, Jan 17 2014 1:53 pm
From: Vir Campestris
On 17/01/2014 14:28, Robert Wessel wrote:
> While I can see being able to search for a pair so long a key_equal is
> provided, I'm not sure how you could manage the complexity guarantees
> if you ignored hash_function. The problem is when hash_function
> preprocesses the key in some way before hashing it (for example, you
> might lowercase a string, so that the hash is not case sensitive).
That doesn't matter, it's what the key_equal does that counts.
You'll still be able to store objects if your hash just returns zero -
it's for efficiency only that you want to minimise hash clashes.
Andy
== 8 of 10 ==
Date: Fri, Jan 17 2014 2:23 pm
From: Robert Wessel
On Fri, 17 Jan 2014 21:53:13 +0000, Vir Campestris
<vir.campestris@invalid.invalid> wrote:
>On 17/01/2014 14:28, Robert Wessel wrote:
>> While I can see being able to search for a pair so long a key_equal is
>> provided, I'm not sure how you could manage the complexity guarantees
>> if you ignored hash_function. The problem is when hash_function
>> preprocesses the key in some way before hashing it (for example, you
>> might lowercase a string, so that the hash is not case sensitive).
>
>That doesn't matter, it's what the key_equal does that counts.
>
>You'll still be able to store objects if your hash just returns zero -
>it's for efficiency only that you want to minimise hash clashes.
Which is why I said: "While I can see being able to search for a pair
so long a key_equal is provided, I'm not sure how you could manage the
complexity guarantees if you ignored hash_function".
== 9 of 10 ==
Date: Fri, Jan 17 2014 2:27 pm
From: woodbrian77@gmail.com
Please don't swear here, Leigh.
== 10 of 10 ==
Date: Fri, Jan 17 2014 2:35 pm
From: woodbrian77@gmail.com
On Friday, January 17, 2014 3:53:13 PM UTC-6, Vir Campestris wrote:
>
> That doesn't matter, it's what the key_equal does that counts.
>
> You'll still be able to store objects if your hash just returns zero -
> it's for efficiency only that you want to minimise hash clashes.
>
I'd consider that to be an efficiency bug.
Brian
Ebenezer Enterprises
http://webEbenezer.net
==============================================================================
TOPIC: Decoding GIF file in C? [Source code here]
http://groups.google.com/group/comp.lang.c++/t/dec6ec0426c88c64?hl=en
==============================================================================
== 1 of 2 ==
Date: Thurs, Jan 16 2014 11:58 pm
From: seeplus
On Thursday, January 16, 2014 7:44:12 PM UTC+11, kiran...@gmail.com wrote:
> For the images being encoded by someone with GIF encoder needs to be decoded by GIF decoder only (Am i wrong in this assumption?) :-)
>
> And thanks for the info of GIF usage :-)
>
Do you mean >> can some OTHER decoder, which is designed to decode something else and is not specifically a GIF decoder, decode GIF images?
== 2 of 2 ==
Date: Fri, Jan 17 2014 2:35 am
From: kirannd1989@gmail.com
Hey..
Just as a reply for why i was in need of GIF decoder which is rarely used compared to PNG and GPEG.
I had to mention it.
Hope you understand.
Thanks for all inputs.
On Friday, January 17, 2014 1:28:36 PM UTC+5:30, seeplus wrote:
> On Thursday, January 16, 2014 7:44:12 PM UTC+11, kiran...@gmail.com wrote:
>
> > For the images being encoded by someone with GIF encoder needs to be decoded by GIF decoder only (Am i wrong in this assumption?) :-)
>
> >
>
> > And thanks for the info of GIF usage :-)
>
> >
>
>
>
> Do you mean >> can some OTHER decoder, which is designed to decode something else and is not specifically a GIF decoder, decode GIF images?
==============================================================================
TOPIC: Boost
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
==============================================================================
== 1 of 14 ==
Date: Fri, Jan 17 2014 7:11 am
From: Nick Baumbach
Does anybody use Boost code, what is it.
I mean, it has to make things easier, but it does not looks like, since it
takes hours to compile.
== 2 of 14 ==
Date: Fri, Jan 17 2014 7:36 am
From: Öö Tiib
On Friday, 17 January 2014 17:11:24 UTC+2, Nick Baumbach wrote:
> Does anybody use Boost code, what is it.
Boost is collection of about hundred of quite fine open source C++
libraries. Majority of C++ developers have at least tried some of
those.
> I mean, it has to make things easier, but it does not looks like, since it
> takes hours to compile.
Most of boost libraries are header only; you just #include files to use
them in your program. If particular boost library makes things easier or
not depends on if your program needs to do what it does or not.
There are only about dozen of boost libraries that have compiled binary
parts and handful that have optional compiled binary parts. If you don't
even know what boost is and if you need those libraries for anything
then what is the point of compiling them? Also I'm pretty sure that you
can find built binaries from net like with any other open source.
== 3 of 14 ==
Date: Fri, Jan 17 2014 7:37 am
From: "Alf P. Steinbach"
On 17.01.2014 16:11, Nick Baumbach wrote:
> Does anybody use Boost code, what is it.
>
> I mean, it has to make things easier, but it does not looks like, since it
> takes hours to compile.
>
You can use the header-only sub-libraries without building Boost.
However, the most useful of them are now part of the standard, e.g.
shared_ptr.
Cheers & hth.,
- Alf
== 4 of 14 ==
Date: Fri, Jan 17 2014 7:43 am
From: Victor Bazarov
On 1/17/2014 10:11 AM, Nick Baumbach wrote:
> Does anybody use Boost code, what is it.
>
> I mean, it has to make things easier, but it does not looks like, since it
> takes hours to compile.
Plenty of people use Boost code. It does make things easier. If you
don't like it, don't use it. There is very little value in complaining
about something for which you don't have any use, or on which you don't
have any intention to spend any of your precious time.
Here is an analogy: it takes significant time to earn money to buy a car
and to learn to drive one. But once you buy it and start using it, you
often find that it does make your life easier. It's called "investment".
If you think that a few hours of compilation is not worth the return
that you might get from using Boost after you have prepared it for your
use, then don't spend those few hours. Life's too short.
V
--
I do not respond to top-posted replies, please don't ask
== 5 of 14 ==
Date: Fri, Jan 17 2014 7:49 am
From: Nick Baumbach
n wrote:
> On 17.01.2014 16:11, Nick Baumbach wrote:
>> Does anybody use Boost code, what is it.
>>
>> I mean, it has to make things easier, but it does not looks like, since
>> it takes hours to compile.
>>
>>
> You can use the header-only sub-libraries without building Boost.
>
> However, the most useful of them are now part of the standard, e.g.
> shared_ptr.
How do I know whether I need it.
== 6 of 14 ==
Date: Fri, Jan 17 2014 7:53 am
From: Nick Baumbach
n wrote:
> If you think that a few hours of compilation is not worth the return
> that you might get from using Boost after you have prepared it for your
> use, then don't spend those few hours. Life's too short.
Can't you read, how do one knows that Boosts code is needed. What can
Boost do, I can'd do simpler and ergo, faster.
More code added increase complexity, unnecessary.
== 7 of 14 ==
Date: Fri, Jan 17 2014 7:59 am
From: drew@furrfu.invalid (Drew Lawson)
In article <lbbjle$38q$2@speranza.aioe.org>
Nick Baumbach <nich@iwqoc.org> writes:
>n wrote:
>
>> If you think that a few hours of compilation is not worth the return
>> that you might get from using Boost after you have prepared it for your
>> use, then don't spend those few hours. Life's too short.
>
>Can't you read, how do one knows that Boosts code is needed. What can
>Boost do, I can'd do simpler and ergo, faster.
http://www.boost.org/doc/libs/1_55_0/
Start reading and see if anything there is useful to you.
We do not know what your projects are, so have no way of knowing
what you need.
>More code added increase complexity, unnecessary.
The flip-side is reinventing the wheel, wasted time, fixing the
same bugs that boost already worked through.
I don't use boost much, so I can't sell you on the idea.
--
Drew Lawson So risk all or don't risk anything
You can lose all the same
== 8 of 14 ==
Date: Fri, Jan 17 2014 8:56 am
From: Victor Bazarov
On 1/17/2014 10:49 AM, Nick Baumbach wrote:
> n wrote:
>
>> On 17.01.2014 16:11, Nick Baumbach wrote:
>>> Does anybody use Boost code, what is it.
>>>
>>> I mean, it has to make things easier, but it does not looks like, since
>>> it takes hours to compile.
>>>
>>>
>> You can use the header-only sub-libraries without building Boost.
>>
>> However, the most useful of them are now part of the standard, e.g.
>> shared_ptr.
>
> How do I know whether I need it.
I think the guiding principle here is "if you need to ask, you probably
have no use for it. Yet."
Here is the metaphor I think is applicable here. Can you dig a ditch
using your spade? Would an excavator help? Not really, if a ditch is
but a few feet long and a foot deep and the soil is loose and light.
You would only use an excavator if the amount of work warrants it. Of
course, if you already have an excavator on site, using it to move even
a bit of earth costs you almost nothing and can save some time, compared
to digging with a spade, even a mere few cubic feet of dirt.
Read about Boost, learn about the problems people solved using it. Some
here might tell you about it, but using Boost's online forum is probably
more effective. If you find that you can solve some problem with it,
then get it, invest some time learning it. Or don't.
V
--
I do not respond to top-posted replies, please don't ask
== 9 of 14 ==
Date: Fri, Jan 17 2014 9:01 am
From: Nick Baumbach
n wrote:
> Read about Boost, learn about the problems people solved using it. Some
> here might tell you about it, but using Boost's online forum is probably
> more effective. If you find that you can solve some problem with it,
> then get it, invest some time learning it. Or don't.
And now please answer the question. Only if you can, I did not asked for
noise.
== 10 of 14 ==
Date: Fri, Jan 17 2014 9:59 am
From: Victor Bazarov
On 1/17/2014 12:01 PM, Nick Baumbach wrote:
> n wrote:
>
>> Read about Boost, learn about the problems people solved using it. Some
>> here might tell you about it, but using Boost's online forum is probably
>> more effective. If you find that you can solve some problem with it,
>> then get it, invest some time learning it. Or don't.
>
> And now please answer the question. Only if you can, I did not asked for
> noise.
Your original post did not contain any questions. It only contained a
childish whine about the perceived difficulty of compiling Boost. Learn
to ask questions. Visit this page:
http://www.catb.org/~esr/faqs/smart-questions.html
As Drew Lawson write here
On 1/17/2014 10:59 AM, Drew Lawson wrote:
> [..]
> We do not know what your projects are, so have no way of knowing
> what you need.
consider telling us what it is you do, what problems you're trying to
solve, _before_ anyone could tell you to use some specific part of Boost
or to skip it altogether.
And now please ask your questions. Or don't.
V
--
I do not respond to top-posted replies, please don't ask
== 11 of 14 ==
Date: Fri, Jan 17 2014 10:35 am
From: Jorgen Grahn
On Fri, 2014-01-17, Nick Baumbach wrote:
> Does anybody use Boost code, what is it.
>
> I mean, it has to make things easier, but it does not looks like, since it
> takes hours to compile.
I suspect that Stroustrup sums it up nicely:
http://www.stroustrup.com/bs_faq.html#boost
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 12 of 14 ==
Date: Fri, Jan 17 2014 12:14 pm
From: Robert Wessel
On Fri, 17 Jan 2014 10:43:52 -0500, Victor Bazarov
<v.bazarov@comcast.invalid> wrote:
>On 1/17/2014 10:11 AM, Nick Baumbach wrote:
>> Does anybody use Boost code, what is it.
>>
>> I mean, it has to make things easier, but it does not looks like, since it
>> takes hours to compile.
>
>Plenty of people use Boost code. It does make things easier. If you
>don't like it, don't use it. There is very little value in complaining
>about something for which you don't have any use, or on which you don't
>have any intention to spend any of your precious time.
>
>Here is an analogy: it takes significant time to earn money to buy a car
>and to learn to drive one. But once you buy it and start using it, you
>often find that it does make your life easier. It's called "investment".
>
>If you think that a few hours of compilation is not worth the return
>that you might get from using Boost after you have prepared it for your
>use, then don't spend those few hours. Life's too short.
And just what part (or all) of Boost is going to require hours of
compilation time? Sounds like a troll to me...
== 13 of 14 ==
Date: Fri, Jan 17 2014 12:56 pm
From: Paavo Helde
Robert Wessel <robertwessel2@yahoo.com> wrote in
news:ck3jd9hvrjo7eio0idenggt72dg2hjtvct@4ax.com:
> And just what part (or all) of Boost is going to require hours of
> compilation time? Sounds like a troll to me...
Figuring out how to get the bjam (or b2 or whatever it is called nowadays)
compilation to work and then building all possible variants
(static/dynamic/debug/nodebug/32-bit/64-bit/static runtime/dynamic runtime
etc) of all existing compilable Boost libraries can indeed take hours on a
mediocre machine. Not that it's needed for anything, it's just the simplest
approach if someone has no idea what he wants.
Cheers
Paavo
== 14 of 14 ==
Date: Fri, Jan 17 2014 2:10 pm
From: woodbrian77@gmail.com
On Friday, January 17, 2014 9:11:24 AM UTC-6, Nick Baumbach wrote:
> Does anybody use Boost code, what is it.
>
I use the Boost Intrusive library.
> I mean, it has to make things easier, but it does not looks like, since it
> takes hours to compile.
I think parts of Boost, like the containers, are great.
Other parts of Boost are not so great.
Brian
Ebenezer Enterprises - Heavenly code.
http://webEbenezer.net
==============================================================================
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