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 - 14 messages, 8 authors
http://groups.google.com/group/comp.lang.c++/t/1164ef3d2f08f58f?hl=en
* Decoding GIF file in C? [Source code here] - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/dec6ec0426c88c64?hl=en
* Overloaded operator question - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/d9e346a8acc0298d?hl=en
* Boost - 5 messages, 4 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 14 ==
Date: Wed, Jan 15 2014 1:37 pm
From: Seungbeom Kim
On 2014-01-15 08:50, woodbrian77@gmail.com wrote:
>
> It isn't very descriptive. It's like saying a
> marble is not blue. Hash_map would be better.
A problem I see is that the name "unordered_map" strongly suggests
that a map should be ordered by default. While it's true that order
is an important property for std::map, a map in its purest sense
doesn't have to be ordered and it would have been no less sensible
to have std::map (unordered) and std::ordered_map instead. It's just
for a historical reason that an ordered map took the name "std::map".
The same goes for unordered_set: we all learned in elementary schools
that a set is just a collection of things like {apple, banana, orange},
which never has to be ordered. (Letting multiset carry the burden of
the prefix "multi-" makes sense because its behavior deviates from
that of a "normal set".)
And I don't think being unordered is the most important and essential
property for std::unordered_{map,set}. A negative description such as
"not xxx" or "un-xxx" usually isn't; std::unordered_{map,set} is not
what we get just by removing order from std::{map,set}. This makes
a big point that makes the names std::unordered_{map,set} lame.
> I think there was some history with that name,
> but think the name could still be changed to
> hash_map.
I don't believe it can happen. I don't like the choice, but I admit
it's made by the committee members who are in a better position to
make good decisions for the entire C++ community.
--
Seungbeom Kim
== 2 of 14 ==
Date: Wed, Jan 15 2014 2:42 pm
From: Öö Tiib
On Wednesday, 15 January 2014 22:23:35 UTC+2, woodb...@gmail.com wrote:
> On Wednesday, January 15, 2014 11:32:44 AM UTC-6, Öö 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". 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 believe unordered_map has to have a hash function.
> It defaults to std::hash if you don't supply your own.
Yes. Also you can provide function to detect equality
of value of two keys and you can dynamically 'rehash'
and set load factor of hash table. For majority of use
cases those opportunities are unimportant. Majority
just need a map for searching mapping between two
values. They don't care about order of iteration.
> The Microsoft documentation on unordered_map says the
> sequence is "weakly ordered". That's a more accurate
> description than "unordered". But I don't like
> "weakly_ordered_map" for a name either. "Hash_map"
> is nice because it isn't so long.
The "order" we talk of here is iteration order that is
"unordered" since it is not related to order of keys
unlike with 'std::map'. The keys of 'std::unordered_map'
may be even not comparable with each other at all. As
long a functor to detect equality of two keys is available
it works fine.
> > > I think there was some history with that name,
> > > but think the name could still be changed to
> > > hash_map.
> >
> > When the requirements of standard are sufficiently
> > different than those of prior art then it is good idea
> > to rename.
>
> What different requirements?
Depends what 'hash_map' you are talking about. It was
very common extension provided by many library
implementations prior to standardising. Code that used
some particular implementation could continue to use
it without fear it changing or switch to standardised
'unordered_map' if there was budget for that switch.
== 3 of 14 ==
Date: Wed, Jan 15 2014 2:52 pm
From: Öö Tiib
On Wednesday, 15 January 2014 22:35:01 UTC+2, woodb...@gmail.com wrote:
> On Wednesday, January 15, 2014 10:20:06 AM UTC-6, Öö Tiib wrote:
> > Saving one integer value is questionable here. It is most
> > likely that removing it is inefficient like with C string.
> > C string is less efficient than 'std::string' on most of cases
> > precisely because of not storing the length anywhere.
> > So you need to show that you "pay", otherwise it might
> > be empty claim.
>
> Some containers you rarely/never need to know their size.
The C++ standard committee that wrote C++98 also thought
so. However in practice there was tons of newbies who wrote
things like 'if(x.size() == 0)' instead of 'if(x.empty())'. That is
terrible performance hit if a set counts its elements each time
someone detects its emptiness but the bug is so subtle and
common so the library implementers started to cache the size.
The committee then wizened up and standardised practice
that existed.
== 4 of 14 ==
Date: Wed, Jan 15 2014 4:11 pm
From: Seungbeom Kim
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... :)
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).
> 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. :)
--
Seungbeom Kim
== 5 of 14 ==
Date: Wed, Jan 15 2014 6:15 pm
From: woodbrian77@gmail.com
On Wednesday, January 15, 2014 6:11:37 PM UTC-6, 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... :)
>
> 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).
>
I've been trying to say something like that, but you beat
me to it so now I don't have to.
> > 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.
>
That sounds interesting.
Brian
Ebenezer Enterprises
http://webEbenezer.net
== 6 of 14 ==
Date: Thurs, Jan 16 2014 5:45 am
From: Juha Nieminen
woodbrian77@gmail.com wrote:
> I believe std::set has some const assumption that makes it
> difficult to use as an alternative.
Fair enough.
>> > I think unordered_map is a lame name.
>>
>> It's descriptive. What else do you want?
>>
>
> It isn't very descriptive. It's like saying a
> marble is not blue. Hash_map would be better.
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.
Consistency would dictate std::map to be renamed to std::ordered_map,
but backwards compatibility and grandfather clauses...
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
== 7 of 14 ==
Date: Thurs, Jan 16 2014 9:19 am
From: woodbrian77@gmail.com
On Thursday, January 16, 2014 7:45:41 AM UTC-6, Juha Nieminen 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.
>
Are there any implementations that do something else?
> Consistency would dictate std::map to be renamed to std::ordered_map,
> but backwards compatibility and grandfather clauses...
>
A new name could be introduced without forcing a renaming.
There would be two names for the same thing with one being
the hoped-to-be improved name.
== 8 of 14 ==
Date: Thurs, Jan 16 2014 1:02 pm
From: Seungbeom Kim
On 2014-01-16 05:45, Juha Nieminen 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?
Besides, I'm curious to hear what data structures other than hash tables
exist that use a hash function and buckets but don't deserve the word
"hash" in the name.
--
Seungbeom Kim
== 9 of 14 ==
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.
== 10 of 14 ==
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
== 11 of 14 ==
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.
== 12 of 14 ==
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 ---
== 13 of 14 ==
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.
== 14 of 14 ==
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).
==============================================================================
TOPIC: Decoding GIF file in C? [Source code here]
http://groups.google.com/group/comp.lang.c++/t/dec6ec0426c88c64?hl=en
==============================================================================
== 1 of 5 ==
Date: Wed, Jan 15 2014 1:46 pm
From: Jorgen Grahn
On Wed, 2014-01-15, kirannd1989@gmail.com wrote:
> On Monday, January 13, 2014 6:28:12 PM UTC+5:30, Jorgen Grahn wrote:
>> On Mon, 2014-01-13, kirannd1989@gmail.com wrote:
>>
>> > Thanks for the nominations :-).
>> > Fortunately i was able to find only this to start up.
>> > Hope u understand how a startup person would feel,
>> > when he comes across a source file all of a sudden.
>> >
>> > Please can u direct me to the place where i can find something useful.
>>
>> What do you want to do? Decoding GIFs was useful back in 1994, but
>> since then a few other image formats have become more popular. There
>> are widely used libraries for decoding all of them.
> I want to decode a GIF encoded image.
I meant "/why/ do you want to decode GIF?" I'm not saying /noone/ uses
GIF any more, but I see it very rarely compared to PNG and JPEG.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 2 of 5 ==
Date: Thurs, Jan 16 2014 12:44 am
From: kirannd1989@gmail.com
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 :-)
On Thursday, January 16, 2014 3:16:13 AM UTC+5:30, Jorgen Grahn wrote:
> On Wed, 2014-01-15, kirannd1989@gmail.com wrote:
>
> > On Monday, January 13, 2014 6:28:12 PM UTC+5:30, Jorgen Grahn wrote:
>
> >> On Mon, 2014-01-13, kirannd1989@gmail.com wrote:
>
> >>
>
> >> > Thanks for the nominations :-).
>
> >> > Fortunately i was able to find only this to start up.
>
> >> > Hope u understand how a startup person would feel,
>
> >> > when he comes across a source file all of a sudden.
>
> >> >
>
> >> > Please can u direct me to the place where i can find something useful.
>
> >>
>
> >> What do you want to do? Decoding GIFs was useful back in 1994, but
>
> >> since then a few other image formats have become more popular. There
>
> >> are widely used libraries for decoding all of them.
>
>
>
> > I want to decode a GIF encoded image.
>
>
>
> I meant "/why/ do you want to decode GIF?" I'm not saying /noone/ uses
>
> GIF any more, but I see it very rarely compared to PNG and JPEG.
>
>
>
> /Jorgen
>
>
>
> --
>
> // Jorgen Grahn <grahn@ Oo o. . .
>
> \X/ snipabacken.se> O o .
== 3 of 5 ==
Date: Thurs, Jan 16 2014 7:02 am
From: Jorgen Grahn
On Thu, 2014-01-16, kirannd1989@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?) :-)
No, you're right. If your software decodes GIF images, then it's a
GIF decoder.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 4 of 5 ==
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?
== 5 of 5 ==
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: Overloaded operator question
http://groups.google.com/group/comp.lang.c++/t/d9e346a8acc0298d?hl=en
==============================================================================
== 1 of 2 ==
Date: Wed, Jan 15 2014 1:47 pm
From: woodbrian77@gmail.com
Notice the operator<< functions here:
class failure : public ::std::exception {
::std::string whatStr;
public:
explicit failure (char const* what_) : whatStr(what_)
{}
explicit failure (::std::string what_) : whatStr(::std::move(what_))
{}
~failure () throw()
{}
char const* what () const throw()
{ return whatStr.c_str(); }
// failure& operator<< (char* s)
// {
// whatStr.append(s);
// return *this;
// }
failure& operator<< (char const* s)
{
whatStr.append(s);
return *this;
}
failure& operator<< (::std::string const& s)
{
whatStr.append(s);
return *this;
}
template <class T>
failure& operator<< (T val)
{
whatStr.append(::std::to_string(val));
return *this;
}
};
If I add back the commented out operator<< above the
following line is accepted by the compiler:
if(argc!=2) throw failure("Usage: ")<<*argv<<" config-file-name";
But if it is stays commented out, I get an error:
/ErrorWords.hh: In instantiation of 'cmw::failure& cmw::failure::operator<<(T) [with T = char*]':
cmwAmbassador.cc:309:44: required from here
./ErrorWords.hh:47:40: error: call of overloaded 'to_string(char*&)' is ambiguous
whatStr.append(::std::to_string(val));
I'd like to be able to remove the commented out version
of that operator from the class. I guess the compiler
prefers the function template version to the version that
takes a char const*. Any ideas? Thanks.
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
== 2 of 2 ==
Date: Thurs, Jan 16 2014 12:11 am
From: bblaz
On 01/15/14 22:47, woodbrian77@gmail.com wrote:
> Notice the operator<< functions here:
>
> class failure : public ::std::exception {
> ::std::string whatStr;
>
> public:
> explicit failure (char const* what_) : whatStr(what_)
> {}
>
> explicit failure (::std::string what_) : whatStr(::std::move(what_))
> {}
>
> ~failure () throw()
> {}
>
> char const* what () const throw()
> { return whatStr.c_str(); }
>
>
> // failure& operator<< (char* s)
> // {
> // whatStr.append(s);
> // return *this;
> // }
>
> failure& operator<< (char const* s)
> {
> whatStr.append(s);
> return *this;
> }
>
> failure& operator<< (::std::string const& s)
> {
> whatStr.append(s);
> return *this;
> }
>
> template <class T>
> failure& operator<< (T val)
> {
> whatStr.append(::std::to_string(val));
> return *this;
> }
> };
>
> If I add back the commented out operator<< above the
> following line is accepted by the compiler:
>
> if(argc!=2) throw failure("Usage: ")<<*argv<<" config-file-name";
>
> But if it is stays commented out, I get an error:
>
> /ErrorWords.hh: In instantiation of �cmw::failure& cmw::failure::operator<<(T) [with T = char*]�:
> cmwAmbassador.cc:309:44: required from here
> ./ErrorWords.hh:47:40: error: call of overloaded �to_string(char*&)� is ambiguous
> whatStr.append(::std::to_string(val));
>
>
> I'd like to be able to remove the commented out version
> of that operator from the class. I guess the compiler
> prefers the function template version to the version that
> takes a char const*. Any ideas? Thanks.
>
> Brian
> Ebenezer Enterprises - In G-d we trust.
> http://webEbenezer.net
>
Templated version is selected because it is an exact match, and none of
the other candidates are more specialized.
So, either
take argv as const char**,
or const cast
if(argc!=2) throw failure("Usage: ")<<const_cast<const char*>(*argv)<<"
config-file-name";
or modify the templated function, i.e.
template <class T, class = typename std::enable_if<!std::is_same<T,
char*>::value>::type>
failure& operator<< (T val) {
whatStr.append(std::to_string(val));
return *this;
}
blaz
==============================================================================
TOPIC: Boost
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
==============================================================================
== 1 of 5 ==
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 5 ==
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 5 ==
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 5 ==
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 5 ==
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.
==============================================================================
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