soft and program: 21 new messages in 9 topics

comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en

comp.lang.c++@googlegroups.com

Today's topics:

==============================================================================
TOPIC: copy from keys from multimap into the vector
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/abc66612050d5014?hl=en
==============================================================================

== 1 of 5 ==
Date: Wed, Oct 29 2008 4:15 pm
From: Juha Nieminen

Obnoxious User wrote:
> #include <vector>
> #include <map>
> #include <iterator>
> #include <algorithm>
> #include <iostream>
>
> template<typename C, typename M>
> class key_inserter :
> public std::iterator<std::output_iterator_tag,void,void,void,void> {
> private:
> C & d_coll;
> public:
> key_inserter(C & c) : d_coll(c) {}
> key_inserter & operator*() { return *this; }
> key_inserter & operator++() { return *this; }
> key_inserter & operator++(int) { return *this; }
> key_inserter &
> operator=(typename M::value_type const & p) {
> d_coll.push_back(p.first);
> return *this;
> }
> };
>
> template<typename C, typename M>
> key_inserter<C,M> make_key_inserter(C & c, M & m) {
> return key_inserter<C,M>(c);
> }
>
> int main() {
> std::vector<int> v;
> std::map<int,int> m;
> m[0];m[1];m[2];m[6];
> std::copy(m.begin(),
> m.end(),
> make_key_inserter(v,m));
> std::copy(v.begin(),
> v.end(),
> std::ostream_iterator<int>(std::cout,"\n"));
> return 0;
> }

Given that the while loop solution only requires 2 lines of code, I
think it's the easier solution... ;)

== 2 of 5 ==
Date: Wed, Oct 29 2008 4:28 pm
From: Salt_Peter

On Oct 29, 2:33 pm, puzzlecracker <ironsel2...@gmail.com> wrote:
> I am using while loop for that but I am sure you can do it quicker and
> more syntactically clear with copy function.
>
> Here is what I do and would like to if someone has a cleaner solution:
>
> vector<string> vec;
> multimap<stirng, int> myMap
>
> // populate myMap
>
> multimap<string, int >::iterator iter = myMap.begin();
>
> while(iter != myMap.end())
> {
> vec.push_back(iter->first)
> }

You could use std::transform with std::back_inserter to load vector
and a functor to extract the std::string from multimap's value_type.

#include <iostream>
#include <string>
#include <vector>
#include <map>
#include <algorithm>
#include <iterator>

template< typename P >
struct extract_first
{
const typename P::first_type&
operator()(const P& p) const
{
return p.first;
}
};

int main()
{
std::vector< std::string > vec;
std::multimap< std::string, int > mm;
// populate mm

typedef std::multimap< std::string, int >::value_type VType;

std::transform( mm.begin(),
mm.end(),
std::back_inserter(vec),
extract_first< VType >() );
}

== 3 of 5 ==
Date: Wed, Oct 29 2008 5:40 pm
From: Kai-Uwe Bux

Salt_Peter wrote:

> On Oct 29, 2:33 pm, puzzlecracker <ironsel2...@gmail.com> wrote:
>> I am using while loop for that but I am sure you can do it quicker and
>> more syntactically clear with copy function.
>>
>> Here is what I do and would like to if someone has a cleaner solution:
>>
>> vector<string> vec;
>> multimap<stirng, int> myMap
>>
>> // populate myMap
>>
>> multimap<string, int >::iterator iter = myMap.begin();
>>
>> while(iter != myMap.end())
>> {
>> vec.push_back(iter->first)
>> }
>
> You could use std::transform with std::back_inserter to load vector
> and a functor to extract the std::string from multimap's value_type.
>
> #include <iostream>
> #include <string>
> #include <vector>
> #include <map>
> #include <algorithm>
> #include <iterator>
>
> template< typename P >
> struct extract_first
> {
> const typename P::first_type&
> operator()(const P& p) const
> {
> return p.first;
> }
> };
>
> int main()
> {
> std::vector< std::string > vec;
> std::multimap< std::string, int > mm;
> // populate mm
>
> typedef std::multimap< std::string, int >::value_type VType;
>
> std::transform( mm.begin(),
> mm.end(),
> std::back_inserter(vec),
> extract_first< VType >() );
> }

Alternatively, one can put the template inside:

// same headers

struct extract_first {

template< typename P >
typename P::first_type const &
operator()(const P& p) const {
return p.first;
}

};

int main() {
std::vector< std::string > vec;
std::multimap< std::string, int > mm;
// populate mm

std::transform( mm.begin(),
mm.end(),
std::back_inserter(vec),
extract_first() );
}

This makes extract_first oblivious to the type actually being used. I am not
sure, which is better. Any thoughts?

Best

Kai-Uwe Bux

== 4 of 5 ==
Date: Wed, Oct 29 2008 7:40 pm
From: puzzlecracker

> Given that the while loop solution only requires 2 lines of code, I
> think it's the easier solution... ;)

That's exactly my point. Guys, do you see how this solution is
verbose, cluttered, and not particularly expressive over my
traditional solution? Meyers allegedly encourages to use transforms,
copy and other algorithms in the STL library. And I am confident that
for this problem, he would still pick a stl-like solution. However,
using transform, in this case, doesn't telegraph your intent -- that
you want to copy keys to from a multimap into a vector -whereas a loop
with fairly descriptive variable names would.

I bring this example, because I have stumbled upon a huge amount of
code, where STL is [ab]used rather excessively, not only making the
code hard to read, maintain, but also fix bugs in it. However, this
particular example is coming from my 'fix' where I considered using
hardcore stl or a trivial loop, I chose the latter.

Thoughts?

== 5 of 5 ==
Date: Wed, Oct 29 2008 11:45 pm
From: Triple-DES

On 30 Okt, 01:40, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
> Salt_Peter wrote:

> > You could use std::transform with std::back_inserter to load vector
> > and a functor to extract the std::string from multimap's value_type.
>
> > #include <iostream>
> > #include <string>
> > #include <vector>
> > #include <map>
> > #include <algorithm>
> > #include <iterator>
>
> > template< typename P >
> > struct extract_first
> > {
> > const typename P::first_type&
> > operator()(const P& p) const
> > {
> > return p.first;
> > }
> > };
>
> > int main()
> > {
> > std::vector< std::string > vec;
> > std::multimap< std::string, int > mm;
> > // populate mm
>
> > typedef std::multimap< std::string, int >::value_type VType;
>
> > std::transform( mm.begin(),
> > mm.end(),
> > std::back_inserter(vec),
> > extract_first< VType >() );
> > }
>
> Alternatively, one can put the template inside:
>
> // same headers
>
> struct extract_first {
>
> template< typename P >
> typename P::first_type const &
> operator()(const P& p) const {
> return p.first;
> }
>
> };
>
> int main() {
> std::vector< std::string > vec;
> std::multimap< std::string, int > mm;
> // populate mm
>
> std::transform( mm.begin(),
> mm.end(),
> std::back_inserter(vec),
> extract_first() );
>
> }
>
> This makes extract_first oblivious to the type actually being used. I am not
> sure, which is better. Any thoughts?
>

I like your solution, but the "canonical" solution, I think, is the
former (looking at SGI's select1st functor). That being said, I can't
think of a case where your solution would be any worse.

==============================================================================
TOPIC: Class objects work like built-in types, but is it worth it?
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/2c47abdc653f2dd1?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Oct 29 2008 4:22 pm
From: tonytech08

On Oct 29, 4:00 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
> On 2008-10-28 23:21, tonytech08 wrote:
>
>
>
>
>
> > On Oct 28, 4:14 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
> >> On 2008-10-28 21:29, tonytech08 wrote:
> >> > On Oct 28, 1:55 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
> >> >> On 2008-10-28 16:00, tonytech08 wrote:
> >> >> > On Oct 26, 2:49 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
> >> >> >> On 2008-10-26 05:07, tonytech08 wrote:
> >> >> >> > On Oct 24, 4:25 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> >> >> >> >> tonytech08 wrote:
> >> >> >> >> > On Oct 23, 5:42 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> >> >> >> >> >> tonytech08 wrote:
> >> >> >> >> >> (like they are in
> >> >> >> >> >> some languages). While in some cases this would be a useful thing (which
> >> >> >> >> >> is the reason why those some languages do it in the first place), this
> >> >> >> >> >> would seriously hinder the efficiency of built-in types.
>
> >> >> >> >> > It wouldn't change built-in efficiency in the least or in any way.
>
> >> >> >> >> Exactly how would you create a generic data container which supports
> >> >> >> >> both built-in types in the most efficient way possible *and*
> >> >> >> >> user-defined classes if, as you suggest, the latter do not behave like
> >> >> >> >> built-in types?
>
> >> >> >> > Why is that important?
>
> >> >> >> Consistency is very important when writing software, we do not need the
> >> >> >> additional complexity of having different containers for different
> >> >> >> types.
>
> >> >> > Pushing complexity to another area is just pushing it around rather
> >> >> > than finding an elegant solution. And yes, sometimes the elegant
> >> >> > solution has some amount of compromise to avoid that complexity. If
> >> >> > one is real anal about it, well, C++ the language may be what you end
> >> >> > up with? "Refactoring" the language may be in order (on alternative).
>
> >> >> To me it seems like we pushed the complexity all the way out of existence.
>
> >> > Ha! C++ is complexity incarnate! Pushing stuff into the compiler is
> >> > not reducing complexity, it's just moving it elsewhere.
>
> >> First of all I do not agree that the complexity for the compiler is
> >> increased by any significan amount (after all, every abstraction that
> >> takes you away from assembly-language is added complexity) but
> >> constructors and such are relatively simple.
>
> > It's not just compiler-called constructors. The compiler-called
> > constructors give rise to implementing exceptions, mentioned earlier
> > in this thread (probably more than once).
>
> Also mentioned earlier is the fact that constructors does not
> necessitate exceptions. Examples of why one would want exceptions
> regardless of the presence of constructors (or even objects) have been
> given, as has examples of how one could have constructors without
> exceptions.

I'm not buying those arguments though.

>
>
>
>
>
> >> >> >> If you need to different containers (one for built-in types and
> >> >> >> one for others) it means you need two sets of code, which meant you
> >> >> >> double the amount of bugs, double the maintenance const, double the
> >> >> >> things to keep track of, etc.
>
> >> >> > So, how many linked lists of integer values have you used in code? It
> >> >> > appears that not supporting built-in types for some containers would
> >> >> > encourage better programming practice (going by just that one
> >> >> > example).
>
> >> >> Linked lists? None in any non-trivial program, but I've used vectors
> >> >> (lots of them), heaps, stacks, and queues with integers.
> >> > The one who said "it means you need two sets of code" above someone
> >> > with the paradigm that containers are value-based things, probably
> >> > because of some kind of derivation of what a container is based upon
> >> > built-in arrays, which leads to "hence, class objects need to behave
> >> > like built-in types to be used by value-based containers", was why I
> >> > posed the "how many linked lists of integers..." question and
> >> > "theory" that value-based containers aren't even desireable mostly.
>
> >> I will not speculate about his reasoning but I can say this: The fact
> >> that the container can also handle class-types have been useful in some
> >> situations (for example I can switch to debugging by just changing a
> >> #define/typedef).
>
> > I was suggesting that handling built-ins as value-based containers was
> > probably the wrong design paradigm for containers and that shoehorns
> > class objects into a requirement to behave like built-ins (which is
> > not necessarily lucrative).
>
> And I suggested that it was not true.

We'll have to agree to disagree on that then probably.

>
> In fact, if classes where to behave like built-in types we would not
> have a need for constructors (since built-in types are not initialised
> on creation) and thus, by your reasoning, no need for exceptions either.

Well let's not pick nits. The "built-in type-like behavior" then.

>
> >>>> I think that both arrays and lists (as used in functional
> >>>> languages) are containers.
>
> >> > Built in arrays are different beasts. It would probably not be
> >> > prudent to make the "raw materials of composition" (built-ins), class
> >> > objects. One can wrap those for more specific purposes.
>
> >> Not sure what you mean here.
>
> > 2 separate thoughts, should have been separated with paragraphs. 1.)
> > Built-in arrays and "containers" are not synonymous at a practical
> > level (sure if you wanted to be way abstract and talk about algoritms,
> > it might make sense, but in this thread, no.).
>
> At a practical level I think arrays are containers, you can store
> objects in them. Or put another way, arrays contains (hint, hint) objects.

That's not what I had in mind for the discussion in this thread
because the definition is too broad to be useful here. I'd like to
stop anymore discussion here about built-in arrays as I do plan on
letting this thread end in a reasonable amount of time without
bringing in "the meaning of life" and everything else.

>
> > 2.)Getting back to the thread topic, making built-ins class objects
> > is probably a bad idea.
>
> Actually I think it's a good idea, then there will be no distinction
> between built-in and user-defined types.

I think built-in types arise out of being things that are "native" to
hardware and are therefor fundamentally different than class types.
But that's a discussion for compiler writers and hardware engineers
rather than me. (Feel free to start another thread about that and I
will lurk there as I am curious to know more about that).

>
> Or did you mean making user-defined types behave like built-ins? You
> have been repeatedly claimed it to be a bad idea

No I haven't. I'm just trying to work out whether I can live without
that or not.

> but I've yet to see any
> convincing arguments. You have mentioned constructors and exceptions as
> being problematic but as I pointed out earlier in this post that simply
> does not hold.

I didn't call them problematic. I just said they may be more icing
than I want on the cake. I'm weighing the pros and cons and at this
point I'm not convinced I need compiler-called functions in certain
classes or any for that matter.

>
> > But the topic ponders is making class objects behave like built-ins a
> > bad idea at some level also (?).
>
> No, reducing the distinction between user-defined types and built-in
> types simplifies the logical model, makes it easier to write reusable
> code, easier to maintain and change code, and probably makes it easier
> to implement also (since compilers and tools does not have to make any
> distinction).

Well that's one opinion, good. Thanks. It's kind of "lofty" though
rather than scientific.

>
> >> > My original
> >> > question is still open. Maybe there are 2 (or more) types of classes:
> >> > those that behave like built-ins and those that are something else.
> >> > That "something else" being lightweight and not nearly as complex as
> >> > requiring compiler-called constructors and then exceptions to solve
> >> > the "problem" with constructors.
>
> >> In my experience its the classes that do not behave as built-in types
> >> that are the more complex ones (singletons, non-value semantics, etc.).
>
> > Maybe even most classes (?).
>
> Yes, most classes behaves like value types.

Oh, I thought you were saying the opposite: tha most classes are not
value-type-like (which is what I think). I gave class Money and class
Complex as typical value-type-like classes and postulated that the
entire set of those kinds of classes was small relative to other
classes.

>Especially those that I use
> a log. Those that do not have value-semantics are more rarely used and
> not so numerous. At least that's my experience.

It probably depends on the domain you program for. Obviously if you
are doing numerical programming you'd have a lot of those things.

>
> > If so, whether the subset of classes that need built-in-like behavior
> > justifies all the related machinery is the question.
>
> Since the subset is the majority I think it is safe to assume it does.

I'm not convinced it is. Actually, I think it is the opposite (for
me). But really depends on what kind of software one is writing.

>
> Besides, you still have not shown that there is any extra "machinery"
> needed (by extra I mean something that can not justify it's own
> existence in isolation).

I consider exceptions as "extra machinery" or at least that I have it
"on trial".

>
> > Maybe it does, maybe it doesn't. Value-based containers require some
> > level of built-in type behavior from class objects and that seems
> > "too big of a pill to swallow" where simplicity/minimalness is valued
> > or the goal.
>
> Most programmers find it very intuitive and you usually don't have to do
> anything to get the behaviour.

you have to give up PODness.

> On the other hand any other behaviour is
> less intuitive and requires more manual labour.

Well have to agree to disagree on that.

> So it seems to me like
> value-semantics is the simpler approach. Besides, you have to look at
> the full picture. Having two classes of types is not minimalistic.

In quantity (yes 2 is more than 1) but that is hardly an analysis. If
I can live without exceptions, that's a big potential deletion from a
compiler I'll bet. I'll bet something like that permeates compiler
code all over the place.

>
> > I'm probably suggesting that classes should be designed NOT as
> > built-in types unless "it hurts not to" and that value- based
> > container "incompatibility" is "bad container design/ architecture"
> > rather than a point to justify built-in behavior from class objects.
>
> In general it does hurt not do have value-semantics for types.

Maybe. But having constructors, destructors, exceptions etc. like it
is in C++ is not the only way to do that. Whether an alternative will
give only a 80% but workable solution is not known (to me, yet).

> Even in
> Java and C# where most types have reference-semantics people program as
> if they had value-semantics, and the GC makes this transparent to the user.
>
> If you want something else you will end up with a very different
> programming paradigm.

Not necessarily. Perhaps just a different implementation.

>
> >> >> > I think I've noted before or above that if you start with the thought
> >> >> > that "a built-in array is a container", a perverted definition of
> >> >> > "container" will result. A built-in array is a type rather than a
> >> >> > container (by "my" definition of container anyway).
>
> >> >> Actually if we say that an array is a container we say that it fulfils
> >> >> the requirements of a container, not the the requirements of a container
> >> >> is to be like an array. Or in OO terms: an array implements the
> >> >> interface container, but there might be many other implementations of
> >> >> the same interface.
>
> >> > That's not topical though, and is paradigmical and a very
> >> > high-level/abstract "definition" (and even moreso, a definition of
> >> > "container interface" rather than "container").
> >> It's a
> >> definition of a container in terms of an interface, i.e. the interface
> >> specifies what a container is and everything that implements the
> >> interface is a container.
>
> > Nah, that's just a behavioral specification. A container interface is
> > not a container just like a remote control is not a television. The
> > remote just allows interaction with it.
>
> In my work we design nodes in networks (some might call them servers but- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -...
>
> read more »

Ooops, a Google hiccup?

== 2 of 2 ==
Date: Wed, Oct 29 2008 4:32 pm
From: tonytech08

On Oct 29, 4:00 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
> On 2008-10-28 23:21, tonytech08 wrote:

> >> >> > I think I've noted before or above that if you start with the thought
> >> >> > that "a built-in array is a container", a perverted definition of
> >> >> > "container" will result. A built-in array is a type rather than a
> >> >> > container (by "my" definition of container anyway).
>
> >> >> Actually if we say that an array is a container we say that it fulfils
> >> >> the requirements of a container, not the the requirements of a container
> >> >> is to be like an array. Or in OO terms: an array implements the
> >> >> interface container, but there might be many other implementations of
> >> >> the same interface.
>
> >> > That's not topical though, and is paradigmical and a very
> >> > high-level/abstract "definition" (and even moreso, a definition of
> >> > "container interface" rather than "container").
> >> It's a
> >> definition of a container in terms of an interface, i.e. the interface
> >> specifies what a container is and everything that implements the
> >> interface is a container.
>
> > Nah, that's just a behavioral specification. A container interface is
> > not a container just like a remote control is not a television. The
> > remote just allows interaction with it.
>
> In my work we design nodes in networks (some might call them servers but
> I don't think that's a good description) which communicate with each
> other and other nodes in networks. The requirements on these nodes are
> specified by a standardisation organisation and the way they are
> specified are in they way they interact with other nodes in the
> networks. In other words the specification of a node is a description of
> its interfaces. What I want to say with this is that a specification of
> behaviour can be a sufficient definition of a thing. So an interface
> description of a container can be a definition of a container.

But would be an incorrect definition given the context of this thread.
Context matters.

>
> >> > Containers were brought into the discussion when someone said that
> >> > built-in-type-behavior of class objects is required so that
> >> > containers can be implemented, which of course is wrong in the
> >> > general sense.
>
> >> Of course, but he only said that it is necessary to implement practical
> >> and useful containers.
>
> > Which also is not true.
>
> Says you, but who should I believe?

I'm not here to convince you. I do things my own way and I have
containers that I use that are practical and useful. And obviously I
think they are more practical and useful than their STL equivalents.

> A regular who's skills are
> programming in general and C++ in particular I've witnessed, or you who
> has so far only questioned what is more or less the collective opinion
> among C++ programmers?

I just wanted to know what people though on the topic. I was hoping to
get some response from people who actually implement the language
rather than just users of it. And from people who are also good
inventors and have found other ways to skin the proverbial cat. (As in
"a better C++"). Surely if one just says "C++ is just fine" that
doesn't add anything toward discovery of anything new.

==============================================================================
TOPIC: Contract Opening
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/66baddb018d3be22?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Oct 29 2008 5:18 pm
From: yyyc186

On Oct 15, 5:52 pm, red floyd <redfl...@gmail.com> wrote:
> On Oct 15, 2:25 pm, yyyc186 <yyyc...@hughes.net> wrote:> Hello,
>
> > Ordinarily I don't sub,
>
> [redacted]
>
> Apparently, you don't bother trying to find out the etiquette for
> places
> you post your jobs to either.
>
> See the FAQ (http://www.parashift.com/c++-faq-lite), especially FAQ
> 5.10
> (http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.10).

Sorry to wiz in your cornflakes!

The vast majority of technology based newsgroups allow postings of
contracts which are directly relevant to the readers since some of
them may be looking for jobs. Nobody posts a serious contract in any
*.jobs.* newsgroup since that is the refuge of the damned.

== 2 of 2 ==
Date: Wed, Oct 29 2008 9:05 pm
From: Victor Bazarov

yyyc186 wrote:
> On Oct 15, 5:52 pm, red floyd <redfl...@gmail.com> wrote:
>> On Oct 15, 2:25 pm, yyyc186 <yyyc...@hughes.net> wrote:> Hello,
>>
>>> Ordinarily I don't sub,
>> [redacted]
>>
>> Apparently, you don't bother trying to find out the etiquette for
>> places
>> you post your jobs to either.
>>
>> See the FAQ (http://www.parashift.com/c++-faq-lite), especially FAQ
>> 5.10
>> (http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.10).
>
> Sorry to wiz in your cornflakes!
>
> The vast majority of technology based newsgroups allow postings of
> contracts which are directly relevant to the readers since some of
> them may be looking for jobs. Nobody posts a serious contract in any
> *.jobs.* newsgroup since that is the refuge of the damned.

The vast majority of people who have violated the rules of some place
they barge in, and have been pointed to their mistake, apologize and
make up for the damage they've done. Contracts are *off-topic* here.
I may have some fish bait left over, should I post about it here? It
just might be "relevant to the readers since some may be looking for"
fish bait for their next fishing trip...

Go wiz in your own cornflakes.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

==============================================================================
TOPIC: sampling using iterators
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/e03fe9437b39e490?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Oct 29 2008 7:25 pm
From: Leon

Juha Nieminen wrote:
> Leon wrote:
>> using
>> multimap<int,int>::iterator itlow = pq.lower_bound (x);
>> multimap<int,int>::iterator itup = pq.upper_bound (y);
>>
>> I obtain lower and upper bound from the multimap, and having these two
>> iterators I would like to sample one element with uniform distribution.
>> It a way do to this using iterators? I can of course draw an integer and
>> loop over the sequence until I meet the drawn value, but it is not a
>> very nice solution. Can sample directly using iterators?
>
> I don't really understand what do you mean by "sample". If you mean
> that you want (constant-time) random access to the range above, that's
> just not possible with multimap iterators, as they are not random access
> iterators.
>
> If you *really* need that (eg. for efficiency reasons) then one
> solution might be to instead of using a multimap, use a regular map with
> a vector (or deque) as element, so that each element with the same key
> is put into the vector correspondent to that key. Then you can
> random-access the vector when you need to.
>
> (Of course the downside of this is that inserting and removing
> elements is not, strictly speaking, O(lg n) anymore... But you can't
> have everything at once.)

Yes, since the iterator is not random for multimap I have to loop
anyway. Thanks!

==============================================================================
TOPIC: expression template and FFT
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/0f359f745d567e20?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Oct 29 2008 7:56 pm
From: aaragon

On Oct 21, 3:27 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> Peng Yu wrote:
>
> > I see a proposal to add rvalue reference in the standard. Is it in the
> > standard now? Is there any compiler that supports it?
>
> Well you just said it's a proposal, didn't you? The new standard has
> yet to be published.
>
> Have a look at gcc 4.3.
>
> --
> Ian Collins

You should try to use Andrei's code. It's only a header file and the
implementation is really a piece of cake. I think it's gonna take a
while until compilers support this idea of rvalue references. The idea
behind the mojo code is that if you use objects that allocate memory
dynamically, you can avoid the creation of temporaries (for example
when you return an object from a function) by stealing the pointer to
the memory allocated. This is what move constructors do. This can also
be done by the RVO (Return Value Optimization), but this is up to the
compiler because it depends on how messy the function is. The mojo
code works regardless, but it won't be useful unless you allocate a
lot of memory on the heap. I used it because I coded myself Matrix and
Vector classes to do numerical computations and all elements in these
objects were allocated through an array in the heap.

I hope it helps.

==============================================================================
TOPIC: Question about creating a struct of flags in c++
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/aded373b78039bdf?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Oct 29 2008 9:07 pm
From: "Plissken.s@gmail.com"

Is there an efficient way to create a struct of flag in C++?

I need to create a struct of boolean flag, like this:
struct testStruct {
bool flag1;
bool flag2;
bool flag3;
bool flag4;
bool flag5;
bool flag6;
bool flag7;
bool flag8;
bool flag9;
bool flag10;
bool flag11;
bool flag12;
bool flag13;
};

But if I do that, i print out the sizeof(), that struct and it is 13.
So i think the compile use 1 byte for each flag.

Is it possible to create a struct so that each flag uses only 1 bit.

Thank you.

== 2 of 3 ==
Date: Wed, Oct 29 2008 9:10 pm
From: Victor Bazarov

Plissken.s@gmail.com wrote:
> Is there an efficient way to create a struct of flag in C++?
>
> I need to create a struct of boolean flag, like this:
> struct testStruct {
> bool flag1;
> bool flag2;
> bool flag3;
> bool flag4;
> bool flag5;
> bool flag6;
> bool flag7;
> bool flag8;
> bool flag9;
> bool flag10;
> bool flag11;
> bool flag12;
> bool flag13;
> };
>
> But if I do that, i print out the sizeof(), that struct and it is 13.
> So i think the compile use 1 byte for each flag.
>
> Is it possible to create a struct so that each flag uses only 1 bit.

Yes, read about bitfields. The syntax is the colon and the field width
after the name of the member, like

bool flag1:1;

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

== 3 of 3 ==
Date: Wed, Oct 29 2008 10:50 pm
From: "Plissken.s@gmail.com"

On Oct 29, 11:10 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> Plisske...@gmail.com wrote:
> > Is there an efficient way to create a struct of flag in C++?
>
> > I need to create a struct of boolean flag, like this:
> > struct testStruct {
> > bool flag1;
> > bool flag2;
> > bool flag3;
> > bool flag4;
> > bool flag5;
> > bool flag6;
> > bool flag7;
> > bool flag8;
> > bool flag9;
> > bool flag10;
> > bool flag11;
> > bool flag12;
> > bool flag13;
> > };
>
> > But if I do that, i print out the sizeof(), that struct and it is 13.
> > So i think the compile use 1 byte for each flag.
>
> > Is it possible to create a struct so that each flag uses only 1 bit.
>
> Yes, read about bitfields. The syntax is the colon and the field width
> after the name of the member, like
>
> bool flag1:1;
>
> V
> --
> Please remove capital 'A's when replying by e-mail
> I do not respond to top-posted replies, please don't ask

Thank you Victor.

I am going to follow you suggestion. If I create a class like this:
class myMask {
public:
bool flag1:1;
bool flag2:1;
bool flag3:1;
bool flag4:1;
bool flag5:1;
bool flag6:1;
bool flag7:1;
bool flag8:1;
bool flag9:1;
bool flag10:1;
bool flag11:1;
bool flag12:1;
bool flag13:1;
};

Can I set all the flag to 0 by doing this:

myMask mask;

memset(&mask, '\0', sizeof(myMask));

And can I compare if 2 masks are the same by doing this:

myMask mask1;
myMask mask2;

memcmp(&mask1, &mask2, sizeof(myMask));

Thanks.

==============================================================================
TOPIC: stl help needed
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/fb8d07b1ba882dd2?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Oct 29 2008 9:20 pm
From: DJ Dharme

> do you mean that you want to create your own data container which
> works in the same way as the standard library data containers?

Yes my intension was to write my own container class (a modified set)
which supports dynamic order statistics (which allows me to access
items by it's index in lgN time instead of N time).

> Why aren't you using a std::vector in your type instead of reinventing
> the wheel?

I have no intension of re-writing a vector class, I am just writing it
to learn stl as it was the simplest container class that I could
imagine.

> The type's name is misleading to me unless you sort upon insertion

Hmm.., I thought someone would like to put all the elements at once
(without sorting) and the do a single sort as it would be more optimum
than sort upon insertion. But there is also an option to sort upon
insertion if you want (which assumes the current elements are already
in the sorted order). May be you were curious about the other insert
option ?

Thanks everyone for the support!

DJD

== 2 of 2 ==
Date: Wed, Oct 29 2008 10:25 pm
From: DJ Dharme

On Oct 29, 10:43 pm, Obnoxious User <O...@127.0.0.1> wrote:
> On Wed, 29 Oct 2008 09:57:34 -0700, DJ Dharme wrote:
> > Hi,
> > I really like to use stl as much as possible in my code. But I
> > found it really hard to understand by looking into there source code. I
> > have no idea about what iterator traits, heaps and allocators are.
>
> http://www.amazon.co.uk/C-Standard-Library-Tutorial-Reference/dp/0201...
>
> --
> OU
> Remember 18th of June 2008, Democracy died that afternoon.http://frapedia.se/wiki/Information_in_English

This book rocks, thanks you very much OU

Regards,
DJD

==============================================================================
TOPIC: const correctness - should C++ prefer const member over non-const?
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/35cc955f55ea7387?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Oct 29 2008 10:13 pm
From: fungus

I define this class:

class foo {
std::vector<int>data;
public:

int operator[](int n) {
return data[n];
}
int operator[](int n) const {
return data[n];
}
};

Now in my program I do:

foo myFoo;
int x = myFoo[123];
...

Should the const version of foo::operator[] be called?

I think it should, but my compiler disagrees with me.

What's the correct behavior? Why...?

--
<\___/>
/ O O \
\_____/ FTB.

http://www.topaz3d.com/ - New 3D editor!

== 2 of 3 ==
Date: Wed, Oct 29 2008 10:31 pm
From: blargg.h4g@gishpuppy.com (blargg)

In article
<7908dabe-5102-4669-bf68-6cd36bedd6a7@m74g2000hsh.googlegroups.com>,
fungus <openglMYSOCKS@artlum.com> wrote:

> I define this class:
>
>
> class foo {
> std::vector<int>data;
> public:
>
> int operator[](int n) {
> return data[n];
> }
> int operator[](int n) const {
> return data[n];
> }
> };
>
>
> Now in my program I do:
>
> foo myFoo;
> int x = myFoo[123];
> ...
>
>
> Should the const version of foo::operator[] be called?
>
> I think it should, but my compiler disagrees with me.
>
> What's the correct behavior? Why...?

I'm interested in why you think it should call the const version. If it
did, when would it ever call the non-const version?

== 3 of 3 ==
Date: Wed, Oct 29 2008 10:41 pm
From: Jerry Coffin

In article <7908dabe-5102-4669-bf68-6cd36bedd6a7
@m74g2000hsh.googlegroups.com>, openglMYSOCKS@artlum.com says...
> I define this class:
>
>
> class foo {
> std::vector<int>data;
> public:
>
> int operator[](int n) {
> return data[n];
> }
> int operator[](int n) const {
> return data[n];
> }
> };
>
>
> Now in my program I do:
>
> foo myFoo;
> int x = myFoo[123];
> ...
>
>
> Should the const version of foo::operator[] be called?

No.

> I think it should, but my compiler disagrees with me.

The compiler's right. The const version should be called for a const
object. The non-const version should be called for a non-const object.
If you don't/didn't have a non-const version, then the const version
could be called -- but it would be called by convertion the non-const to
a const object first. That's fine (in this case) but it's still a
conversion. When matching overloaded functions, one that doesn't require
a conversion is a better match than one that does require a conversion.

Most people want the const version used on the RHS of an assignment, but
the non-const for the LHS. To get what that kind of behavior, you
normally use a proxy object that overloads operator= and operator T.

--
Later,
Jerry.

The universe is a figment of its own imagination.

==============================================================================
TOPIC: Is c++ only better c ?
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/38527e42967dc124?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Oct 29 2008 10:29 pm
From: Jerry Coffin

In article <yW5Ok.215$wy4.77@read4.inet.fi>, nospam@thanks.invalid
says...
> Gerhard Fiedler wrote:
> > One example doesn't make a general point, good or bad. I don't know MathML,
> > and I don't have to. If it's a bad example, it's just a bad example.
>
> Just to show a concrete example, here's an equation as written in LaTeX:
>
> \begin{equation}
> x^2+4x+4=0
> \end{equation}
>
> The same equation written in MathML:

[ ... elided ]

This really is a problem with MathML, not with XML in general though. If
you wanted to define a LateXML, you could easily allow a equation to
look like:

Of course, if that was _all_ you had for the content in a file, the
overhead of an XML header would be fairly substantial, at least on a
percentage basis. I've yet to see a situation in which that was really
an issue though.

I'd characterize LaTeX as a "programmer's format", whereas MathML is a
"software Engineeer's" format. MathML is the kind of thing you could
implement reasonably well with an army of average intelligence, average
talent, etc., programmers, and still get the job done. Implementing
LaTeX at all well requires fewer programmers, but they need far more
knowledge of the subject matter, and probably better judgement to do the
job well. At the same time, if they do have the judgement and the
knowledge, LaTeX (or something similar) gives them a lot more leeway to
put their talent to use in producing a superior result.

--
Later,
Jerry.

The universe is a figment of its own imagination.

== 2 of 2 ==
Date: Thurs, Oct 30 2008 12:07 am
From: Ian Collins

Juha Nieminen wrote:
> James Kanze wrote:
>>> As an example of what I'm talking about, consider MathML vs.
>>> LaTeX equations, and which one is easier for a human to
>>> write.)
>> Neither are, IMHO, particularly simple.
>
> I didn't ask if either one is particularly simple. I asked which one
> is *simpler* for a human to write (and read).
>
> The LaTeX equation syntax is *by far* simpler to read and write by a
> human.

The verbosity id largely irrelevant, most of the XML I deal with (which
is a lot) is generated by machines to communicate between machines or
generated by humans as source for generating other formats.

XML should not be considered in isolation, but in the context of the
tools that work with it (CSS, DOM, XSLT and friends).

--
Ian Collins

==============================================================================

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

soft and program

Thursday, October 30, 2008

21 new messages in 9 topics - digest

No comments:

Blog Archive

About Me