soft and program: comp.lang.c++ - 25 new messages in 12 topics

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

comp.lang.c++@googlegroups.com

Today's topics:

==============================================================================
TOPIC: std::string recplace char
http://groups.google.com/group/comp.lang.c++/t/2a58dd8b015f15cb?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Sep 28 2009 12:12 am
From: Simon

Hi,

I wrote a function to do a search and replace in a std::string, (feel
free to comment about it :)).

// --
void replace_inplace
(
std::string& origStr,
const std::string& srchStr,
const std::string& replaceStr
)
{
const size_t len = replaceStr.length();
const size_t lens = srchStr.length();
if( 0 == lens || (len == lens && replaceStr == srchStr) )
{
return; // what are we looking for?
}

std::string::size_type loc = origStr.find(srchStr);
while (loc != std::string::npos)
{
origStr.replace(loc, lens, replaceStr);
loc = origStr.find(srchStr, loc + len );
}
}
// --

But I am looking for a similar function that would replace a search
string with a single char

// --
void replace_inplace
(
std::string& origStr,
const std::string& srchStr,
const char replaceChar
)
{
...
}

Of course I could cast assign the char into a std::string and call the
first function, but I was wondering if there was a more efficient
solution to replace a std::string with a char?

Many thanks

Simon

== 2 of 2 ==
Date: Mon, Sep 28 2009 4:42 am
From: "Francesco S. Carta"

On 28 Set, 09:12, Simon <b...@example.com> wrote:
> Hi,
>
> I wrote a function to do a search and replace in a std::string, (feel
> free to comment about it :)).
>
> // --
> void replace_inplace
> (
> std::string& origStr,
> const std::string& srchStr,
> const std::string& replaceStr
> )
> {
> const size_t len = replaceStr.length();
> const size_t lens = srchStr.length();
> if( 0 == lens || (len == lens && replaceStr == srchStr) )
> {
> return; // what are we looking for?
> }
>
> std::string::size_type loc = origStr.find(srchStr);
> while (loc != std::string::npos)
> {
> origStr.replace(loc, lens, replaceStr);
> loc = origStr.find(srchStr, loc + len );
> }}
>
> // --
>
> But I am looking for a similar function that would replace a search
> string with a single char
>
> // --
> void replace_inplace
> (
> std::string& origStr,
> const std::string& srchStr,
> const char replaceChar
> )
> {
> ...
>
> }
>
> Of course I could cast assign the char into a std::string and call the
> first function, but I was wondering if there was a more efficient
> solution to replace a std::string with a char?

Hi Simon,
I'm not sure how you would "cast assign" the char into a string, I
would build a temporary string and call the original function in this
way:
-------
replace_inplace(origStr, srchStr, std::string(1, replaceChar));
-------

Since you asked for comments about your code: I don't like the naming
convention, the fact that you're passing a non-const reference and the
doubled return path.

I would write it along the lines of:
-------
void replace(std::string* original,
const std::string& search_this,
const std::string& replace_with) {
const size_t search_len = search_this.size();
if ( original
&& search_len
&& search_this != replace_with ) {
const size_t replace_len = replace_with.size();
std::string::size_type found_at = original->find(search_this);
while (found_at != std::string::npos) {
original->replace(found_at, search_len, replace_with);
found_at = original->find(search_this, found_at +
replace_len );
}
}
}

-------

Warning: code not tested!!!

Matter of tastes, of course, but also matter of already present
conventions. Following an existing project/team convention should have
the precedence over personal preferences.

Hope that helps, just my two cents.

Have good coding,
Francesco
--
Francesco S. Carta, hobbyist
http://fscode.altervista.org

==============================================================================
TOPIC: A few questions about singletons...
http://groups.google.com/group/comp.lang.c++/t/dd7f3af258a800cd?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Sep 28 2009 12:15 am
From: Krice

On 25 syys, 20:44, Noah Roberts <d...@reply.com> wrote:
> Patterns ARE central to solid development.

Patterns are like templates, they have become a trend
that everyone has to use, even there is no reason.
It's no wonder that programming has become non-productive,
generating programs that are buggy and slow. But I guess
programmers love complicated and fancy stuff. Maybe they
even get paid more to write more source code and spend
longer time doing that. Maybe patterns were invented just
because of that.

== 2 of 3 ==
Date: Mon, Sep 28 2009 1:13 am
From: James Kanze

On Sep 28, 2:37 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> "Joshua Maurice" <joshuamaur...@gmail.com> wrote in message
[...]
> > Short version: Actually doing a correct singleton in C++ is
> > hard (tm).

> IMVHO, it sure as heck simplifies things if your program is
> single-threaded or you guarantee that no threads will ever be
> created before `main()'!!!

Yes. Except that you can extend it a little: you have to
guarantee that no threads which use the singleton will ever be
created before main. That's an important difference---when
third party libraries are involved, you can't make many
guarantees concerning what happens before main. (Sybase, for
example, does start threads from the constructors of static
objects, at least in some configurations.) On the other hand,
it's a pretty good bet that those libraries don't use a
singleton that you write.

--
James Kanze

== 3 of 3 ==
Date: Mon, Sep 28 2009 1:18 am
From: James Kanze

On Sep 28, 8:15 am, Krice <pau...@mbnet.fi> wrote:
> On 25 syys, 20:44, Noah Roberts <d...@reply.com> wrote:

> > Patterns ARE central to solid development.

> Patterns are like templates, they have become a trend
> that everyone has to use, even there is no reason.

Patterns are totally unlike templates; they aren't so much a
software development technique per se, as a means of
communication (including communicating with yourself). And
until someone suggests something better... Communication is
essential to well written programs, and using a recognized
pattern make the code far easier to understand (and thus more
likely correct) than it would be if you reinvented the wheel
each time around.

Note that in any real program, there will be lots of use of
patterns. I've never seen a GUI interface that didn't use at
least one of the template method pattern, the strategy pattern
or the decorator pattern. (Most will use all of them at
different points.) So the real question is: does the
documentation just say that such and such a pattern is used, or
does the documentation describe all of the nitty gritty details
each time, leaving the client wondering if somewhere in the
three or four pages of documentation, there isn't a subtle
difference in the pattern this time around.

--
James Kanze

==============================================================================
TOPIC: Operator problem with std::pair
http://groups.google.com/group/comp.lang.c++/t/41ebf68dc165775f?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Sep 28 2009 12:02 am
From: "Leo Meyer"

Alf P. Steinbach wrote:
>> [operator problem]
> Try to reproduce the problem in a minimal program.
>
> Cheers & hth.,
>
> - Alf

I have replaced the offending find macro call with a simple loop. It compiles now.
Too many other problems for building a designated test case ;-)
Regards, Leo

--
Warning: This posting may contain traces of ISO 8859-1.

== 2 of 2 ==
Date: Mon, Sep 28 2009 12:53 am
From: James Kanze

On Sep 26, 2:54 pm, "Leo Meyer" <leome...@gmx.de> wrote:

> if I don't describe this problem properly, please ask me, I'm
> not an expert on the STL. This thing has me quite baffled.
> I'm porting a program to Pocket PC 2002 using STLPort using MS
> EVC3 and I keep running into this problem:

> ...\STLport-5.2.1\stlport\stl/_algobase.c(198) : error C2678: binary '==' : no operator defined
> which takes a left-hand operand of type 'struct stlp_std::pair<class CIMGFile,bool>' (or there is no acceptable conversion)

> The problem occurs in an implementation of find:
> template <class _InputIter, class _Tp>
> _STLP_INLINE_LOOP _InputIter __find(_InputIter __first, _InputIter __last,
> const _Tp& __val,
> const input_iterator_tag &) {
> while (__first != __last && !(*__first == __val)) ++__first;
> ^ on this line the error is reported
> return __first;
> }

This is deep in the standard library. The actual error is due
to something incorrect in the call which instantiated this
function. (It could also be a bug in the implementation of the
standard library, but my bets are with an error in your call.)
Could you write a very small program which displays the error,
and post it with all of the error messages?

(If you can, you might also try compiling with a different
compiler/library implementation. The quality of the error
messages varies greatly from one compiler to the next, and it's
possible that the error messages from a different compiler will
be clearer to you.)

> As far as I can tell, the pair is being constructed with this
> macro call: std::make_pair(CIMGFile(), true)

> CIMGFile is a proper class that seems to compile ok.

> Previously, in a header file, the programmer defined the ==
> operator using:
> inline bool operator == (std::pair<CIMGFile, bool> & p, int id )
> {
> return p.first.GetID() == id;
> }

> So STLPort keeps telling me that there is no == operator while
> there clearly should be. Note that it doesn't work either if I
> change std::pair to stlp_std::pair or make it const in the
> operator definition. I have also tried "int & id" instead with
> no effect. Is there something wrong about the type signature
> that I am missing? How can I get this operator definition to
> work?

Probably, the first argument of the operator== must be a
reference to const, although if you're passing in non-const
iterators to a standard container, it should still work. Still,
without seeing a concrete example, it's hard to tell.

--
James Kanze

==============================================================================
TOPIC: new[] / delete
http://groups.google.com/group/comp.lang.c++/t/3064a5710eb9678d?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Sep 28 2009 12:24 am
From: alariq

can i do this without any harm (assuming that type MyType does not
allocate ANY memory in heap)

MyType* pmytype = new MyType[10];

// do some stuff

delete pmytype;

AFAIK, it will free memory allocated for 10 instances of MyType but
will not call destructors (which i do not need) and nothis bad will
happen. Moreover i saw such code when working with native types (such
as char/int/etc) in production code.
What does standard says in this case?
Thanks

== 2 of 3 ==
Date: Mon, Sep 28 2009 1:17 am
From: "Alf P. Steinbach"

* alariq:
> can i do this without any harm (assuming that type MyType does not
> allocate ANY memory in heap)
>
> MyType* pmytype = new MyType[10];
>
> // do some stuff
>
> delete pmytype;
>
> AFAIK, it will free memory allocated for 10 instances of MyType but
> will not call destructors (which i do not need) and nothis bad will
> happen. Moreover i saw such code when working with native types (such
> as char/int/etc) in production code.
> What does standard says in this case?

It's Undefined Behavior.

In practice it will probably, *currently*, work regardless of compiler.

However, why invite later disaster?

Cheers & hth.,

- Alf

== 3 of 3 ==
Date: Mon, Sep 28 2009 1:54 am
From: Saeed Amrollahi

On Sep 28, 10:24 am, alariq <ala...@gmail.com> wrote:
> can i do this without any harm (assuming that type MyType does not
> allocate ANY memory in heap)
>
> MyType* pmytype = new MyType[10];
>
> // do some stuff
>
> delete pmytype;
>
> AFAIK, it will free memory allocated for 10 instances of MyType but
> will not call destructors (which i do not need) and nothis bad will
> happen. Moreover i saw such code when working with native types (such
> as char/int/etc) in production code.
> What does standard says in this case?
> Thanks

According to C++ Standard Document -- ISO-IEC_14882.2003, section
5.3.5, the
behavior is undefined. May be on some implementations, just the first
element of
array will be deleted.
In both cases:
delete object
delete [] array
the destructor called.
In that case, there is no difference between built-in data types and
user-defined data types.
Programmer should use new/new[] and delete/delete[] in regular manner.
See the following links:
http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.12
http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.13

Regards,
-- Saeed Amrollahi

==============================================================================
TOPIC: linked list implementation
http://groups.google.com/group/comp.lang.c++/t/8ab8479c5ce65146?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Sep 28 2009 1:07 am
From: James Kanze

On Sep 27, 12:32 am, Ian Collins <ian-n...@hotmail.com> wrote:
> aegis wrote:
> > I've seen code for linked list implementations where the
> > Node class has a data member for some type in addition to a
> > pointer to another Node. The issue? The "some type" is,
> > from what I have seen, never a pointer to "some type", hence
> > you would have to have a default constructor for the "some
> > type". But what about a case where a default constructor
> > might not be ideal?

> I don't think I've ever seen such a case, care to post an
> example?

> > It would seem more sensible to me to have the data member of
> > the Node class, to be a pointer to "some type". Thoughts?

> That's why most do!

Do they? Mine never did, and the implementations of std::list
that I've seen don't either.

But I don't see the reason behind the original posters comments.
Why would a Node type which contains the data type require a
default constructor for the data type?

--
James Kanze

== 2 of 2 ==
Date: Mon, Sep 28 2009 1:31 am
From: Ian Collins

James Kanze wrote:
> On Sep 27, 12:32 am, Ian Collins <ian-n...@hotmail.com> wrote:
>> aegis wrote:
>>> I've seen code for linked list implementations where the
>>> Node class has a data member for some type in addition to a
>>> pointer to another Node. The issue? The "some type" is,
>>> from what I have seen, never a pointer to "some type", hence
>>> you would have to have a default constructor for the "some
>>> type". But what about a case where a default constructor
>>> might not be ideal?
>
>> I don't think I've ever seen such a case, care to post an
>> example?
>
>>> It would seem more sensible to me to have the data member of
>>> the Node class, to be a pointer to "some type". Thoughts?
>
>> That's why most do!
>
> Do they? Mine never did, and the implementations of std::list
> that I've seen don't either.

You're right, I was answering with my C programmers hat on! I really
should find better things to do on a Sunday afternoon...

--
Ian Collins

==============================================================================
TOPIC: ##### 2009 Air Force One Shoes cheap wholesale with high quality at
website --- www.fjrjtrade.com ---(paypal payment)
http://groups.google.com/group/comp.lang.c++/t/45bc8862d1ea3534?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Sep 28 2009 1:17 am
From: fjrjtrade

##### 2009 Air Force One Shoes cheap wholesale with high quality at
website --- www.fjrjtrade.com ---(paypal payment)

Welcome to visit www.fjrjtrade.com

Cheap Wholesale Air Force One Shoes

Wholesale Air Force One Shoes (paypal payment)

http://www.fjrjtrade.com/category-916-b0-Air-Force-one.html

Wholesale Air Force One 25 Men (paypal payment)

http://www.fjrjtrade.com/category-1627-b0-Air-Force-one-25%28M%29.html

Wholesale Air Force One Children (paypal payment)

http://www.fjrjtrade.com/category-1629-b0-Air-force-One-Children.html

Wholesale Air Force One low (paypal payment)

http://www.fjrjtrade.com/category-1630-b0-Air-Force-one%28low%29.html

Wholesale Air Force One M&W (paypal payment)

http://www.fjrjtrade.com/category-1631-b0-Air-Force-One%28MW%29.html

Wholesale Air Force One Mid (paypal payment)

http://www.fjrjtrade.com/category-1632-b0-Air-Force-one%28Mid%29.html

Wholesale Air Force One Mid Men (paypal payment)

http://www.fjrjtrade.com/category-1771-b0-Air-Force-one-Mid-Man.html

Wholesale Air Force One Mid Women (paypal payment)

http://www.fjrjtrade.com/category-1772-b0-Air-Force-one-Mid-Women.html

Wholesale Air Force One Women (paypal payment)

http://www.fjrjtrade.com/category-1633-b0-Air-Force-One%28W%29.html

Website:
http://www.fjrjtrade.com

==============================================================================
TOPIC: about new and delete
http://groups.google.com/group/comp.lang.c++/t/85fc26a34c7b73d3?hl=en
==============================================================================

== 1 of 5 ==
Date: Mon, Sep 28 2009 1:19 am
From: Joshua Maurice

On Sep 27, 7:53 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> On Sep 27, 7:44 pm, Sam <s...@email-scan.com> wrote:
>
>
>
> > Juha Nieminen writes:
> > > Sam wrote:
> > >>>> Elsewhere in the thread, you will find concrete data showing faster
> > >>>> results in std::list's case.
>
> > >>> With how many elements?
>
> > >> The same number in OP's test case.
>
> > > The original post had no test cases. It only had a program. The
> > > original poster did not specify how many numbers would be entered.
>
> > Oh, I see now -- the OP was entering tens of thousands of numbers on
> > std::cin. That explains all the hubbub.
>
> > >>> Sure, std::list may be faster when we have 10 elements. However, it
> > >>> quickly becomes slower when the amount of elements grows even slightly.
>
> > >> You changing a practical point into a theoretical one is noted.
>
> > > Exactly how is it theoretical that std::vector becomes quickly faster
> > > than std::list when the amount of elements grows even a bit (you don't
>
> > It becomes theoretical as soon as you leave the boundaries of the original
> > scenario.
>
> So, the OP's case involves a small number of integers?
>
> Thus no matter what kind of container, the OP will not see any
> measurable difference for his program, correct?
>
> However, if he were to try to reuse his program, such as by piping the
> output of one program to another, then std::vector would outperform
> right?
>
> Thus he should just use std::vector, right?

In case you missed it Sam, I'd like to know your reply to this simple
argument: If it's a small number of items, performance doesn't matter,
but if it's a large number of elements, then std::vector will
outperform std::list. So, for a small number of elements the choice
does not matter, so he should use vector to make his code reusable and
extensible, because as we all know code is frequently reused, such as
copy-paste, a library, in his piping output from one program to his,
etc.

This was, and is, the source of contention for one issue, that you
claim performance is a reason to use list, but that's only true for a
very small number of inserts, your interpretation of his use case.
However, in this use case, the performance bonus of std::list over
std::vector is not measurable. Thus your argument is "Use std::list
because it performs faster in an entirely unmeasurable way in your use
case." (Note that I said "unmeasurable in his use case". If you change
it to a micro-benchmark like you did, then yes you can measure it. You
cannot measure the difference for his program for a small input set.
You can however measure the difference for a larger input set, in
which case std::vector clearly wins.)

Then there's the teaching aspect as well. (You disagree, but) vector
is generally better than std::list for performance, so it is good
advice to tell him to use vector over list by default.

== 2 of 5 ==
Date: Mon, Sep 28 2009 1:27 am
From: James Kanze

On Sep 27, 6:26 pm, Juha Nieminen <nos...@thanks.invalid> wrote:

[...]
> (Another disadvantage of std::vector which might present
> itself sometimes, is that it can cause bad memory fragmentation, causing
> the overall memory usage of the program to be considerably higher than
> what the program is actually using.)

Or vice versa. std::list typically allocates a lot of little
blocks (although custom allocators can avoid this); std::vector
will end up with a single, large block. A single, large block
will generally cause less fragmentation than a lot of little
blocks. But of course, it depends on the actual use. If you
insert everything in the list in one go, with no other uses of
dynamic memory during the insertions, it's possible that all of
the little blocks end up contiguous. But it's not the sort of
thing I'd count on.

Note that similar considerations hold between std::map and
maintaining a sorted std::vector< std::pair >. In one recent
application, we switched from std::map to the vector solution
because of problems with memory fragmentation. In general, node
based containers like std::map or std::list increase memory
fragmentation, and in most cases, total memory use and execution
times. But that's only very, very generally; each application
will be particular, and you really should use the logically most
appropriate container for the job until you've got some actual
measurements to go on. Thus, std::map for a map, and
std::vector for a vector, std::list if you make a lot of
insertions and deletions in the middle, etc.

--
James Kanze

== 3 of 5 ==
Date: Mon, Sep 28 2009 2:15 am
From: Richard Herring

In message <cone.1253978073.442975.7247.500@commodore.email-scan.com>,
Sam <sam@email-scan.com> writes
>Juha Nieminen writes:
>
>> If efficiency is irrelevant, then you have to consider ease of usage
>> as the second most important feature. Which one is, in your opinion,
>> easier to use, std::list or std::vector? Suppose, that you want to, for
>> example, iterate through the elements in the container:
>> for(std::list<int>::iterator iter = values.begin();
>> iter != values.end(); ++iter)
>> ...
>> vs.
>> for(size_t i = 0; i < values.size(); ++i)
>> ...
>> Take your pick.
>
>Yes. We all should take lessons on efficiencies from someone who fails
>to realize that std::list::end() is an invariant,

So what would you expect to be the execution-time cost of "evaluating"
an inline function which looks something like one of these (examples
from three implementations of the standard library I happen to have to
hand)?

iterator end() { return (iterator(_Myhead, this)); }

iterator end() { return this->_M_node._M_data; }

iterator end () { return __node; }

>and that evaluating it on every iteration always produces the same result.

Don't you think the compiler might make this deduction too?

--
Richard Herring

== 4 of 5 ==
Date: Mon, Sep 28 2009 4:05 am
From: Sam

Joshua Maurice writes:

> On Sep 27, 7:53 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
>> On Sep 27, 7:44 pm, Sam <s...@email-scan.com> wrote:
>>
>>
>>
>> > Juha Nieminen writes:
>> > > Sam wrote:
>> > >>>> Elsewhere in the thread, you will find concrete data showing faster
>> > >>>> results in std::list's case.
>>
>> > >>> With how many elements?
>>
>> > >> The same number in OP's test case.
>>
>> > > The original post had no test cases. It only had a program. The
>> > > original poster did not specify how many numbers would be entered.
>>
>> > Oh, I see now -- the OP was entering tens of thousands of numbers on
>> > std::cin. That explains all the hubbub.
>>
>> > >>> Sure, std::list may be faster when we have 10 elements. However, it
>> > >>> quickly becomes slower when the amount of elements grows even slightly.
>>
>> > >> You changing a practical point into a theoretical one is noted.
>>
>> > > Exactly how is it theoretical that std::vector becomes quickly faster
>> > > than std::list when the amount of elements grows even a bit (you don't
>>
>> > It becomes theoretical as soon as you leave the boundaries of the original
>> > scenario.
>>
>> So, the OP's case involves a small number of integers?
>>
>> Thus no matter what kind of container, the OP will not see any
>> measurable difference for his program, correct?
>>
>> However, if he were to try to reuse his program, such as by piping the
>> output of one program to another, then std::vector would outperform
>> right?
>>
>> Thus he should just use std::vector, right?
>
> In case you missed it Sam, I'd like to know your reply to this simple
> argument: If it's a small number of items, performance doesn't matter,

To you, may be not. But in latency-sensitive environments, it most certainly
does.

But just keep thinking that it doesn't matter, don't let me discourage you
otherwise. I consider stuff like that to be excellent job security.

> but if it's a large number of elements, then std::vector will
> outperform std::list.

Only in some situations involving a large number of elements. In others, a
std::vector cannot be used for other reasons, so it's not even an option.

> So, for a small number of elements the choice
> does not matter, so he should use vector to make his code reusable and
> extensible, because as we all know code is frequently reused, such as

If one places code reusability at a premium, one should be using iterators,
rather than any std::vector-specific methods, or overloads. As I showed,
doing so allows one to substitute the underlying implementation, without
changing the code.

A completely different issue.

> This was, and is, the source of contention for one issue, that you
> claim performance is a reason to use list, but that's only true for a
> very small number of inserts, your interpretation of his use case.

Not just "interpretation". I showed the actual numbers.

> However, in this use case, the performance bonus of std::list over
> std::vector is not measurable.

Sorry, I measured it. Just because some may don't think twice about pissing
away a small amount of resources, that's not a valid reason to do so in my
book.

> You can however measure the difference for a larger input set, in
> which case std::vector clearly wins.)

No, not "clearly". There are a number of situations where the
contortions one must go through, in order to use a vector as the underlying
container, more than negate any inherent vector-specific optimizations.

Sorry, facts disagree.

== 5 of 5 ==
Date: Mon, Sep 28 2009 4:11 am
From: Sam

Richard Herring writes:

> In message <cone.1253978073.442975.7247.500@commodore.email-scan.com>,
> Sam <sam@email-scan.com> writes
>>Juha Nieminen writes:
>>
>>> If efficiency is irrelevant, then you have to consider ease of usage
>>> as the second most important feature. Which one is, in your opinion,
>>> easier to use, std::list or std::vector? Suppose, that you want to, for
>>> example, iterate through the elements in the container:
>>> for(std::list<int>::iterator iter = values.begin();
>>> iter != values.end(); ++iter)
>>> ...
>>> vs.
>>> for(size_t i = 0; i < values.size(); ++i)
>>> ...
>>> Take your pick.
>>
>>Yes. We all should take lessons on efficiencies from someone who fails
>>to realize that std::list::end() is an invariant,
>
> So what would you expect to be the execution-time cost of "evaluating"
> an inline function which looks something like one of these (examples
> from three implementations of the standard library I happen to have to
> hand)?
>
> iterator end() { return (iterator(_Myhead, this)); }
>
> iterator end() { return this->_M_node._M_data; }
>
> iterator end () { return __node; }

The cost is that in many situations the compiler will not be able to prove
to itself that the ending iterator value remains constant for the duration
of the iteration, so it has to emit the code to load the ending iterator
value on each iteration of the loop.

Explicitly evaluating end() once, at the beginning of the loop, is usually
sufficient for the compiler to emit corresponding code that loads the value
just once, into a register, avoiding the need to load it every time.

>>and that evaluating it on every iteration always produces the same result.
>
> Don't you think the compiler might make this deduction too?

It's surprisingly hard, and can only be done in very limited situations.

If there's even one non-inlined function call in the body of the loop, there
are only a very limited amount of cases where the compiler will know that
the function call cannot possibly modify the container using some other
pointer or reference, elsewhere, and it is safe to optimize out the ending
iterator evaluation on every iteration. Otherwise, each function call can
potentially modify the container, and since each iteration compares against
the value of end() that exists at that time, it cannot be optimized out.

==============================================================================
TOPIC: Problem with pow function
http://groups.google.com/group/comp.lang.c++/t/18e7c1d075f2dfd1?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Sep 28 2009 1:40 am
From: arkkimede

On 25 Set, 16:24, Jiøí Paleèek <jpale...@web.de> wrote:
> I think you cannot - the reason is that the "well known mathematical
> rules" actually don't work that way, when we're dealing with functions of
> complex variable. Look:
>
> octave:14> log(exp(i*pi))
> ans = 0.00000 + 3.14159i
> octave:15> log(exp(i*pi*2))
> ans = 0.0000e+00 - 2.4492e-16i
> octave:16> log(exp(i*pi*3))
> ans = 0.00000 + 3.14159i
>
> The problem is that eg. the function Imag(log(exp(x*i))) = arccos(cos(i))
> simply isn't identity (and cannot be).
>
> Regards
> Jiri Palecek

Sorry for the delay, but what do you suggest to solve this problem?
I also implemented an overloading of the function pow with same
result....

==============================================================================
TOPIC: ★☆★☆Cheap Wholesale LV Handbags LV Purses Jimmy Choo Handbags Gucci
Handbags Gucci Purse <www.dotradenow.com>
http://groups.google.com/group/comp.lang.c++/t/381b8493da84651b?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Sep 28 2009 1:49 am
From: Abbey

AAA true leather Handbags http://www.dotradenow.com/category-882-b0-AAA-True-Leather.html
Cheap Wholesale Balenciaga Handbags <www.dotradenow.com paypal
payment>
Cheap Wholesale Balenciaga Purse
Cheap Wholesale Bally Purse <free shipping paypal payment>
Cheap Wholesale BOSS Purse <www.dotradenow.com paypal payment>
Cheap Wholesale Burberry Handbags
Cheap Wholesale Chanel Handbags <free shipping paypal payment>
Cheap Wholesale Chanel Purse
Cheap Wholesale Chloe Handbags
Cheap Wholesale Chloe Purse <free shipping paypal payment>
Cheap Wholesale Coach Handbags
Cheap Wholesale Coach Purse <www.dotradenow.com paypal payment>
Cheap Wholesale D&G Handbags
Cheap Wholesale D&G Purse
Cheap Wholesale Dior Handbags <free shipping paypal payment>
Cheap Wholesale Dunhill Purse
Cheap Wholesale Fendi Handbags <free shipping paypal payment>
Cheap Wholesale Gucci Handbags <www.dotradenow.com paypal payment>
Cheap Wholesale Gucci Purse
Cheap Wholesale Hermes Handbags
Cheap Wholesale Hermes Purse <free shipping paypal payment>
Cheap Wholesale Jimmy Choo Handbags <free shipping paypal
payment>
Cheap Wholesale Jimmy Choo Purse <free shipping paypal payment>
Cheap Wholesale Juicy Handbags <www.dotradenow.com paypal payment>
Cheap Wholesale Kooba Handbags
Cheap Wholesale Lancel Handbags
Cheap Wholesale Loewe Handbags <www.dotradenow.com paypal
payment>
Cheap Wholesale LV Handbags <free shipping paypal payment>
Cheap Wholesale LV Purse <free shipping paypal payment>
Cheap Wholesale Marc Jacobs Handbags <www.dotradenow.com paypal
payment>
Cheap Wholesale Miumiu Handbags
Cheap Wholesale Mulberry Handbags
Cheap Wholesale Prada Handbags <free shipping paypal payment>
Cheap Wholesale Prada Purse
Cheap Wholesale Thomaswlde Handbags <www.dotradenow.com paypal
payment>
Cheap Wholesale Valentnv Handbags
Cheap Wholesale Versace Handbags <www.dotradenow.com paypal
payment>

A+ Grade
Purse http://www.dotradenow.com/category-863-b0-Purse.html
Discount Wholesale Anna Purse <free shipping paypal payment>
Discount Wholesale Burbetty Purse
Discount Wholesale Chanel Purse <www.dotradenow.com >
Discount Wholesale Chloe Purse
Discount Wholesale Coach Purse <www.dotradenow.com >
Discount Wholesale D&G Purse
Discount Wholesale Dior Purse <www.dotradenow.com >
Discount Wholesale Dooney&Bourke Purse
Discount Wholesale ED Hardy Purse <www.dotradenow.com >
Discount Wholesale Fendi Purse
Discount Wholesale Ferragmo Purse
Discount Wholesale Gucci Purse <www.dotradenow.com >
Discount Wholesale Guess Purse
Discount Wholesale LV Purse <free shipping paypal payment>
Discount Wholesale Miumiu Purse
Discount Wholesale Prada Purse <www.dotradenow.com >
Discount Wholesale Tous Purse
Discount Wholesale Versace Purse <www.dotradenow.com > <free
shipping paypal payment>
Handbags http://www.dotradenow.com/category-843-b0-Handbag.html
Discount Wholesale BOSS Handbag
Discount Wholesale Burberry Handbag <www.dotradenow.com >
Discount Wholesale CA Handbag
Discount Wholesale Chanel Handbag <free shipping paypal payment>
Discount Wholesale Chloe Handbag <www.dotradenow.com >
Discount Wholesale Coach Handbag
Discount Wholesale D&G Handbag <www.dotradenow.com >
Discount Wholesale Dooney&Bourke Handbag
Discount Wholesale ED Hardy Handbag <www.dotradenow.com >
Discount Wholesale Fendi Handbag
Discount Wholesale Gucci Handbag <www.dotradenow.com >
Discount Wholesale Hermes Handbag
Discount Wholesale Jimmy Choo Handbag <free shipping paypal
payment>
Discount Wholesale Juciy Handbag
Discount Wholesale LV Handbag <www.dotradenow.com >
Discount Wholesale Miumiu Handbag <www.dotradenow.com >
Discount Wholesale Prada Handbag
Discount Wholesale Tous Handbag <www.dotradenow.com >
Discount Wholesale Versace Handbags <free shipping paypal payment>

==============================================================================
TOPIC: class *a = new ?;
http://groups.google.com/group/comp.lang.c++/t/bc73b079fc6a5569?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Sep 28 2009 4:14 am
From: feribiro

Hi,

could you tell me please how it is possible to pass the type of a
class to a function as a parameter, and then initiate a new class of
that type?

class A {...}
class B : public A {...}
class C : public A {...}

void Main()
{
Create(B);
Create(C);
}

void Create(??? param)
{
A *a = new ??param??;
delete a;
}

Thank you very much

== 2 of 3 ==
Date: Mon, Sep 28 2009 4:30 am
From: SG

On 28 Sep., 13:14, feribiro <ferib...@index.hu> wrote:
> Hi,
>
> could you tell me please how it is possible to pass the type of a
> class to a function as a parameter, and then initiate a new class of
> that type?
>
> class A {...}
> class B : public A {...}
> class C : public A {...}
>
> void Main()
> {
> Create(B);
> Create(C);
> }
>
> void Create(??? param)
> {
> A *a = new ??param??;
> delete a;
> }
>
> Thank you very much

You cannot do this dynamically like in other languages which keep
enough meta data about classes in memory for "reflection" (I'm
thinking of Java in this case) -- at least not without getting your
hands dirty (building registries, registering types, etc by yourself).

But you can do it easily at compile-time. In your case ("Create(B);")
you already know the type at compile-time (B)...

class A
{
public:
virtual ~A() {}
//...
};

class B : public class A {...};
class C : public class A {...};

template<typename T>
void Create()
{
A* a = new T;
delete a;
}

int main()
{
Create<B>();
Create<C>();
}

Note: The class A must have a virtual destructor because you invoke
delete with a pointer of type A* that points to a possibly derived
object. Inheritance must be public in your case. The main function's
name is all lower case and its return type is int.

Cheers,
SG

== 3 of 3 ==
Date: Mon, Sep 28 2009 4:51 am
From: pjb@informatimago.com (Pascal J. Bourguignon)

SG <s.gesemann@gmail.com> writes:

> On 28 Sep., 13:14, feribiro <ferib...@index.hu> wrote:
>> Hi,
>>
>> could you tell me please how it is possible to pass the type of a
>> class to a function as a parameter, and then initiate a new class of
>> that type?
>>
>> class A {...}
>> class B : public A {...}
>> class C : public A {...}
>>
>> void Main()
>> {
>> Create(B);
>> Create(C);
>> }
>>
>> void Create(??? param)
>> {
>> A *a = new ??param??;
>> delete a;
>> }
>>
>> Thank you very much
>
> You cannot do this dynamically like in other languages which keep
> enough meta data about classes in memory for "reflection" (I'm
> thinking of Java in this case) -- at least not without getting your
> hands dirty (building registries, registering types, etc by yourself).

Well this can be done easily enough with boost::lambda.
Or somewhat less easily by defining factory functions.

typedef A* (*factory)();
A* makeInstance_B(){ return new B(); }
A* makeInstance_C(){ return new C(); }

void Create(factory f){
A* a=f();
a->doSomething();
delete a;
}

Create(&makeInstance_B);
Create(&makeInstance_C);

--
__Pascal Bourguignon__

==============================================================================
TOPIC: Why doesn't the default argument allow const member?
http://groups.google.com/group/comp.lang.c++/t/5b4659040c4a93de?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Sep 28 2009 5:01 am
From: Bart van Ingen Schenau

On Sep 26, 8:31 pm, Divick <divick.kish...@gmail.com> wrote:
> On Sep 24, 6:12 pm, Bart van Ingen Schenau <b...@ingen.ddns.info>
> wrote:
>
> > Actually, you ARE allowed to use an arbitrarily complex expression as
> > a default argument.
> > The problem is that the default argument expression is 'evaluated' in
> > two different contexts. At the point where the expression occurs in
> > the sourcce code, it is 'evaluated'to determine which objects and
> > functions are referenced. At this point, all identifiers must be bound
> > to an actual object or function.
> > When the default argument is used in a function call, then it is
> > evaluated for a second time, not to determine the actual value of the
> > default argument.
>
> > For example:
>
> > int a = 0;
> > int f(double x) {return x*100;}
> > int g(int x=f(a)); /* binds default argument to f(double) and ::a */
>
> > int f(int x) {return x;}
>
> > void m()
> > {
> > int a = 1;
> > ::a = 2;
> > g(); /* calls g(f(2)) -> g(200) */
>
> > }
>
> On my compiler the call to g(f(2)) calls g(2), which makes sense as
> the type of a passed to f is 'known' at compile time to be int and
> thus the integer version of f() is called. While you seem to suggest
> that the double version of f() is called. Was it a typo?

No, it was a misunderstanding on my side of the wording in the C++
standard.
The most important part is that, at the point of the declaration of
the default argument, a function called 'f' and an object called 'a'
must be available.

Perhaps it was better if I just copied the example from the standard
(instead of trying to make up something similar):

int a = 1;
int f(int);
int g(int x = f(a)); // default argument: f(::a)

void h() {
a = 2;
{
int a = 3;
g(); // g(f(::a))
}
}

Note that this example also calls g(f(2)).

>
> > As you can see, this mechanism precludes using information that is
> > only known at the call site (such as the object on which a member-
> > function is being invoked).
>
> I did not get what you mean here. Could you please elaborate? If you
> mean that all the information is not available at compile time in this
> example, I would tend to disagree.

I mean that not all required information to access a non-static member
is available at compile-time *at the source location where it is
needed*.
The way that default arguments are defined, you need a concrete object
(as in: the address is/can be fully known) at the point where the
default argument is declared.
The name 'this', or an expression that implicitly depends on 'this',
does not qualify as a concrete object.

It could have been defined otherwise (for example, that name-lookup is
performed at the call-site), but I don't expect the rules to chane
now, becaus that would have too big an impact.

>
> > I think you can safely assume that they only do so if the language has
> > built-in (specified in the language definition) support for multi-
> > threading.
>
> How about C++, does C++ spec support multi threading?

The current version of the C++ standard does NOT support multi-
threading.
Support will be added in the upcoming revision.

>
> Thanks,
> DK

Bart v Ingen Schenau

==============================================================================
TOPIC: Cheap wholesale ED T-shirt, DIESEL T-shirt, COOGI T-shirt, BBC T-shirt,
ARMANI T-shirt<www.dotradenow.com>
http://groups.google.com/group/comp.lang.c++/t/1ee69e2cd11d10e8?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Sep 28 2009 6:24 am
From: Elijah

Cheap wholesale AFF T-shirt (www.dotradenow.com paypal payment, free
shipping)
Cheap wholesale ARMANI T-shirt (www.dotradenow.com paypal payment,
free shipping)
Cheap wholesale BAPE T-shirt
Cheap wholesale BBC T-shirt
Cheap wholesale BOSS T-shirt
Cheap wholesale Burberry T-shirt
Cheap wholesale CA T-shirt men's
Cheap wholesale CA T-shirt women's
Cheap wholesale COOGI T-shirt
Cheap wholesale CRYSTAL ROCK women's (www.dotradenow.com paypal
payment, free shipping)
Cheap wholesale D&G T-shirt
Cheap wholesale DIESEL T-shirt
Cheap wholesale DSQUARED T-shirt men's
Cheap wholesale DSQUARED T-shirt women's
Cheap wholesale Eck? Unltd T-shirt
Cheap wholesale ED T-shirt men's
Cheap wholesale ED T-shirt women's
Cheap wholesale EVISU T-shirt (www.dotradenow.com paypal payment,
free shipping)
Cheap wholesale GGG T-shirt
Cheap wholesale G-STAR T-shirt
Cheap wholesale HLST T-Shirt (www.dotradenow.com paypal payment, free
shipping)
Cheap wholesale Lacoste T-shirt
Cheap wholesale Lacoste T-shirt women's
Cheap wholesale LRG T-shirt
Cheap wholesale O&L T-shirt (www.dotradenow.com paypal payment, free
shipping)
Cheap wholesale POLO 3 T-shirt
Cheap wholesale 4 T-shirt
Cheap wholesale POLO 5 T-shirt
Cheap wholesale POLO T-shirt men's
POLO T-shirt women's
Prada T-shirt (www.dotradenow.com paypal payment, free shipping)
RUEHL T-Shirt
SMET T-Shirt men's
SMET T-Shirt women's
VERSACE T-shirt
A&F Abercrombie & Fitch T-shirt men's
A&F Abercrombie & Fitch T-shirt women's
Cheap wholesale Lacoste polo t shirt
Cheap wholesale Lacoste t shirt solid color
Cheap wholesale Lacoste sweater
Cheap wholesale Lacoste shirt
Cheap wholesale Lacoste
Cheap wholesale Ralph lauren (www.dotradenow.com paypal payment, free
shipping)
Cheap wholesale Ralph Lauren polo
Cheap wholesale Polo
Cheap wholesale Ralph lauren polo t shirt
Cheap wholesale Ralph lauren t shirt (www.dotradenow.com paypal
payment, free shipping)
Cheap wholesale Abercrombie & fitch shirt
Cheap wholesale Burberry shirt
Cheap wholesale Burberry t shirt (www.dotradenow.com paypal
payment, free shipping)
Cheap wholesale NBA sports jersey

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

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

Monday, September 28, 2009

comp.lang.c++ - 25 new messages in 12 topics - digest

No comments:

Blog Archive

About Me