soft and program: comp.lang.c++ - 26 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: Implementation of shared_ptr
http://groups.google.com/group/comp.lang.c++/t/f44425fab08bd122?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, Jan 30 2009 12:00 am
From: fungus

On Jan 29, 9:41 pm, Marcel Müller <news.5.ma...@spamgourmet.com>
wrote:
>
> intrusive reference counting is still a extremely lightweight method
> for moderate requirements.

You also have a lot more freedom to reset pointers to
point to any object. With shared_ptr you can only
copy other shared pointers because you need to know
where the reference count is.

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

== 2 of 3 ==
Date: Fri, Jan 30 2009 3:23 am
From: James Kanze

On Jan 29, 9:41 pm, Marcel Müller <news.5.ma...@spamgourmet.com>
wrote:
> Juha Nieminen wrote:
> > Your ref_count class lacks a proper copy constructor and
> > assignment operator, which means that it will fail
> > spectacularly if objects inherited from it are
> > copied/assigned around (if the reference count in the source
> > and target are different).

> You are right. The objects that I protect by a class like this
> have an application wide primary key. So they are non-copyable
> anyway, because if I copy them the key would no longer be
> unique.

> > This is an extremely typical mistake with intrusive reference
> > counting. It's trivial to fix, though.
>
> class ref_count
> { friend void intrusive_ptr_add_ref(ref_count*);
> friend void intrusive_ptr_release(ref_count*);
> private:
> unsigned count;
> protected:
> ref_count() : count(0) {}
> ref_count(const ref_count&) : count(0) {}
> virtual ~ref_count() {}
> ref_count& operator=(const ref_count&) { return *this; }
> public:
> bool ref_is_managed() { return ref_count != 0; }
> bool ref_is_unique() { return ref_count == 1; }
> // Only a return value of true is thread-safe.
> };

In general, if you're allocating objects dynamically, it's
because they have identity, and aren't copiable. (There are
doubtlessly exceptions, but they aren't that common.) So just
ban copy and assignment. The client code can always reactivate
it for his classes, if it makes sense.

> But maybe it makes more sense to derive from
> boost::non_copyable instead, because copying reference counted
> objects is likely to be not what you intended. A derived class
> may still implement copy and assignment semantics explicitly.

Exactly.

> But intrusive reference counting is still a extremely
> lightweight method for moderate requirements. The runtime
> overhead is quite small.

That's one reason to use intrusive reference counting, but it's
not the only one, nor even the most important one.
Non-intrusive reference counting is extremely brittle; with
boost::shared_ptr, for example, you need to take extrodinary
precautions to ensure that you don't end up with two distinct
counters. (The Boost documentation suggests making all of the
pointers to the object boost::shared_ptr. Which is fine, but
the compilers I use don't collaborate---this isn't a
boost::shared_ptr.)

That's for the cases where reference counting is appropriate, of
course. which aren't all that frequent to begin with.

> OK the interlocked access to the reference counter does not
> scale that good on x86/x64 SMP machines, but this is more
> related to x86/x64 than to the method.

The interlocked access is necessary regardless of the strategy.
On the other hand, I find that when an object is being passed
between threads, auto_ptr is more appropriate: once the second
thread has access, you don't want to allow access from the first
thread.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

== 3 of 3 ==
Date: Fri, Jan 30 2009 3:58 am
From: Pete Becker

On 2009-01-30 06:23:34 -0500, James Kanze <james.kanze@gmail.com> said:

> On Jan 29, 9:41 pm, Marcel Müller <news.5.ma...@spamgourmet.com>
> wrote:
>
>> OK the interlocked access to the reference counter does not
>> scale that good on x86/x64 SMP machines, but this is more
>> related to x86/x64 than to the method.
>
> The interlocked access is necessary regardless of the strategy.
> On the other hand, I find that when an object is being passed
> between threads, auto_ptr is more appropriate: once the second
> thread has access, you don't want to allow access from the first
> thread.

Which says, sort of, that the interlocked access is not necessary. That
is, there's a good argument that shared_point does not need to be
thread-safe.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

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

== 1 of 1 ==
Date: Fri, Jan 30 2009 1:32 am
From: imuaplease@gmail.com

All the posters are nice,
I am a stupid student
but not the most stupid one
and not the undisciplined you may disgust
You can learn the cause and effect law via
my reactions.
Are we still shameful when doing wrong anything ?
1.Yes, because we are still human.
2.No, because we are almost animals.

==============================================================================
TOPIC: Time to put C++ in maintenance mode
http://groups.google.com/group/comp.lang.c++/t/2b386e0101ed3bce?hl=en
==============================================================================

== 1 of 4 ==
Date: Fri, Jan 30 2009 1:35 am
From: paulkp@mbnet.fi

On 30 tammi, 09:02, "Tony" <t...@my.net> wrote:
> Time to put hardware in it's appropriate place!

Stop using drugs.

== 2 of 4 ==
Date: Fri, Jan 30 2009 1:36 am
From: imuaplease@gmail.com

On Jan 29, 11:02 pm, "Tony" <t...@my.net> wrote:
> You know it's way past time to relegate it. (Was 'relegate' the right
> word?). C++ is not for new development. It has always been for "legacy"
> development (cotton fields?). A vehicle for hardware companies to exploit?
> The leadership and innovation required was never about hardware. The real
> thing has always been software. Hardware is a follower. Time to put hardware
> in it's appropriate place! (Gag me with a spoon with SSE instructions! SSE
> shows that hardware people are idiots).
>
> Tony

If you still want something
as meaningful as living a life
Don't make such a question
because hardware is a conception
of a thing
not a human.
If you want hardware,
you can buy one at the store in
the corner of the street.
Or you can find some at the bar.
Pay some money
you will be gracefully done!

== 3 of 4 ==
Date: Fri, Jan 30 2009 1:38 am
From: paulkp@mbnet.fi

On 30 tammi, 11:36, imuaple...@gmail.com wrote:
> If you still want something
> as meaningful as living a life

Stop using drugs.

== 4 of 4 ==
Date: Fri, Jan 30 2009 1:45 am
From: imuaplease@gmail.com

On Jan 30, 1:38 am, pau...@mbnet.fi wrote:
> On 30 tammi, 11:36, imuaple...@gmail.com wrote:
>
> > If you still want something
> > as meaningful as living a life
>
> Stop using drugs.

Today, hardware can be
infected with viral software
and performs illegal actions
Including take in action with
other hardware pieces
As well as leaving its CPU upon the mouth
of the fan without any damage

==============================================================================
TOPIC: sorting stl list with predicate
http://groups.google.com/group/comp.lang.c++/t/5aa7bc1fd6974fbf?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 30 2009 2:02 am
From: James Kanze

On Jan 29, 10:33 am, ManicQin <Manic...@gmail.com> wrote:
> On Jan 29, 11:13 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Jan 28, 6:46 pm, Juha Nieminen <nos...@thanks.invalid> wrote:

> > > ManicQin wrote:
> > > > struct greaterScale : public std::greater<PCOperation>
> > > Btw, you don't have to inherit from std::greater (or any
> > > comparator in the STL) in order to write a comparator.
> > > This is template metaprogramming, not object-oriented
> > > programming.
>
> > True, but providing additional information in the form of
> > typedefs is sometimes useful. I'd generally inherit from
> > std::binary_operator< Operation*, Operation*, bool > for
> > example. Since std::greater< Operation* > inherits from
> > this, he's effectively done so, with less characters to
> > type, but with the result of misleading the reader (since
> > his object manifestly has nothing to do with std::greater).

> > If you're doing much of this sort of thing, it might be
> > worth defining a ComparisonOperator class template:

> > template< typename ArgumentType >
> > struct ComparisonOperator
> > : std::binary_operator< ArgumentType, ArgumentType, bool >
> > {
> > } ;

> > and inheriting from it.

> > (I generally define a compare() member function, then derive
> > from a ComparisonOperators class template which defines all
> > of the comparison operators in terms of compare(), and
> > provides the typedefs.)

> Ok I agree with that point as an advice for good programming
> I'll take it to my consideration. But I still have the
> problem i stated above that when I try to inherit from
> binary_function I get
> error C2664: 'void __thiscall std::list<class COperation *,class
> std::allocator<class COperation *> >::sort(struct std::greater<class
> COperation *>)' : cannot convert parameter 1 from 'struct
> greaterScale'
> to 'struct std::greater<class COperation *>

It's your typedef's which are causing the confusion, I suspect.
Drop the typedefs, and the problem is obvious. You have a list
of COperation*, and you try to sort it using an operator which
can only be called with COperation const*. Drop the references,
or make them references to COperation*, and everything should be
fine (once you've corrected the predicate so that it is
conform). You could also make the references references to a
const, so that you could initialize them with the results of the
conversion COperation* to COperation const*. But I'd just drop
the reference.

==============================================================================
TOPIC: OO wrapper for SQL where clause like Roguewave
http://groups.google.com/group/comp.lang.c++/t/bdc34863097108c4?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 30 2009 2:14 am
From: James Kanze

On Jan 30, 12:29 am, borsc...@roguewave.com wrote:
> On Jan 9, 1:35 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Jan 8, 11:04 am, "Peter Morris" <mrpmorri...@SPAMgmail.com> wrote:

> > > > I'm not too sure I like the concept. I'm not really
> > > > happy with the idea that == doesn't do a comparison, and
> > > > that && doesn't short circuit; in other words, that ``
> > > > purchases[ "videoID" ] == videoID '' can't be used as a
> > > > condition, and that the second operand of && will always
> > > > be evaluated.

> > > In what context? I am unaware of any circumstances where
> > > this is the case (that I can think of at the moment at
> > > least.)

> > In what context what? In the example code we were looking
> > at (using the RogueWave SQL library), == didn't do a
> > comparison, and && didn't short circuit. In general, I
> > would classify that as operator overload abuse. (In this
> > case, the criticism is somewhat mitigated because these
> > operators are only used in a very special context.)

> Yes, I can see your point about operator overload abuse
> although I disagree that it is a problem.

As I said, the criticism is mitigated because (if?) the
operators can only be used in this very special context.

What you're doing, fundamentally, is defining a new language,
which isn't C++ (but is modeled very closely on SQL). I'm
somewhat sceptical of mixing two languages in the same source
file. Of course, we already do it with C style macros and C++
template meta-programming, but both are reknown for resulting in
unreadable code, so I'm not sure they're good models to follow.

The important aspect here is to be able to distinguish which
language is "active" at any given time. If the operators are
designed so that it is impossible to use them outside of certain
clearly marked contexts, it's less of a problem. But the
solution still isn't perfect.

> To continue with Rogue Wave's tutorial code snippet, this
> code:

> purchases["videoID"] == videoID && purchases["last_name"] == lastName

> is being used as an argument to the method RWDBDeleter::where
> which takes an RWDBExpr.

And what happens if someone uses it in an if?

> So, the operators are defined on RWDBExpr. RWDBExpr is used to
> build an SQL expression to be sent to a database. The SQL
> statement produced would be:

> purchases.videoID == videoID && purchases.last_name == lastName

You mean "purchases.videaID = videoId and purchases.last_name =
last_name", I suppose. The above is C++.

> What kind of an alternative would you suggest that would be
> intuitive and easy to use?

The most intuitive and easiest to use is just to have the user
provide a string. Of course, if you do this, you loose
compile-time checking. There are a number of tradeoffs
involved; in my experience, there's not too much problem
differing the checking until runtime, and using a string. But I
don't have that much experience with data bases, and most of my
requests are fairly simple. (Almost all of my use of data bases
from C++ is for persistence, which generally means that I'm
never doing anything very complicated.)

==============================================================================
TOPIC: networking problems
http://groups.google.com/group/comp.lang.c++/t/122ffcb8c1eb02d4?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 30 2009 2:16 am
From: Lionel B

On Thu, 29 Jan 2009 06:30:43 -0800, eminhanif wrote:

> On Jan 29, 1:57 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
>> ramubes...@gmail.com wrote:
>> > This is ramu form hyd .. i am working as a desktop eng i have a
>> > some dout plz clarify my douts...
>>
>> This is victor bazarov .. i am reading this newsgrp i think i can hlp
>> with your douts... watch <Waving Hands><More Hand-Waving> here ..
>> all douts have been clarified
>>
>> Did you have a C++ language question?
> rofl, so good response i was wandering what that guy was on about...
> with the "dout" and everything

That'll be std::dout, the C++ Standard Library "doofus output stream".
Anything written to this stream appears spontaneously in a random usenet
group.

--
Lionel B

==============================================================================
TOPIC: Logical Value Of A Pointer
http://groups.google.com/group/comp.lang.c++/t/e9c0b3e622d74ae6?hl=en
==============================================================================

== 1 of 5 ==
Date: Fri, Jan 30 2009 2:29 am
From: James Kanze

On Jan 29, 6:07 pm, "Andrew Koenig" <a...@acm.org> wrote:
> "James Kanze" <james.ka...@gmail.com> wrote in message

> news:11b0ce6c-69ed-4764-aa5a-c3f8b971e2d5@s1g2000prg.googlegroups.com...
> On Jan 13, 8:46 am, Nosophorus <Nosopho...@gmail.com> wrote:

> > For historical reasons, a pointer implicitly converts to
> > bool, with a null pointer converting to false, and all other
> > pointer values converting to true. In general, it's better
> > to avoid the implicit convertion, and write what you mean:
> > if ( a != NULL ) ...

> Why do you think it's better? I don't think so, but maybe you
> can convince me.

For the same reason implicit conversions in general are to be
avoided. A pointer isn't a bool, so it doesn't make sense to
use it as one; doing so only leads to confusion. Say what you
mean, and mean what you say.

(BTW: you're the co-author of the original proposal for bool.
And there, unless I'm remembering wrong, you proposed
deprecating the above conversion. Have you changed your mind?
And if so, what made you change it?)

== 2 of 5 ==
Date: Fri, Jan 30 2009 4:01 am
From: Pete Becker

On 2009-01-29 20:45:30 -0500, "Alf P. Steinbach" <alfps@start.no> said:

> * Andrew Koenig:
>> "James Kanze" <james.kanze@gmail.com> wrote in message
>> news:11b0ce6c-69ed-4764-aa5a-c3f8b971e2d5@s1g2000prg.googlegroups.com...
>> On Jan 13, 8:46 am, Nosophorus <Nosopho...@gmail.com> wrote:
>>
>>> For historical reasons, a pointer implicitly converts to bool,
>>> with a null pointer converting to false, and all other pointer
>>> values converting to true. In general, it's better to avoid the
>>> implicit convertion, and write what you mean:
>>> if ( a != NULL ) ...
>>
>>
>> Why do you think it's better? I don't think so, but maybe you can convince me.
>
> Don't know if this is James' reason, but relying on the implicit
> conversion here one may acquire the habit of generally relying on
> implicit conversion to bool, and e.g. the Visual C++ compiler produces
> silly-warnings (it actually thinks it affects /performance/ :-) ) in
> some other situations, e.g. for a 'return'. And without a clean
> compile, no warnings, one doesn't know whether one has ignored some
> serious warning, such as e.g. comparision between signed/unsigned.

And the obvious answer to that is that the compiler should not dictate
coding style. Who knows more about your application domain: the
compiler writer or you?

Turn off stupid warnings.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

== 3 of 5 ==
Date: Fri, Jan 30 2009 4:18 am
From: "Alf P. Steinbach"

* Pete Becker:
> On 2009-01-29 20:45:30 -0500, "Alf P. Steinbach" <alfps@start.no> said:
>
>> * Andrew Koenig:
>>> "James Kanze" <james.kanze@gmail.com> wrote in message
>>> news:11b0ce6c-69ed-4764-aa5a-c3f8b971e2d5@s1g2000prg.googlegroups.com...
>>> On Jan 13, 8:46 am, Nosophorus <Nosopho...@gmail.com> wrote:
>>>
>>>> For historical reasons, a pointer implicitly converts to bool,
>>>> with a null pointer converting to false, and all other pointer
>>>> values converting to true. In general, it's better to avoid the
>>>> implicit convertion, and write what you mean:
>>>> if ( a != NULL ) ...
>>>
>>>
>>> Why do you think it's better? I don't think so, but maybe you can
>>> convince me.
>>
>> Don't know if this is James' reason, but relying on the implicit
>> conversion here one may acquire the habit of generally relying on
>> implicit conversion to bool, and e.g. the Visual C++ compiler produces
>> silly-warnings (it actually thinks it affects /performance/ :-) ) in
>> some other situations, e.g. for a 'return'. And without a clean
>> compile, no warnings, one doesn't know whether one has ignored some
>> serious warning, such as e.g. comparision between signed/unsigned.
>
> And the obvious answer to that is that the compiler should not dictate
> coding style. Who knows more about your application domain: the compiler
> writer or you?
>
> Turn off stupid warnings.

Sometimes, for some other warnings, that's the only practical recourse.

However, in this particular case just writing explicit code as one ideally
should anyway, makes that unnecessary, and not only for the original programmer
but for all using the code.

The code-should-be-explicit argument isn't, from my point of view, that
compelling on its own for the conversion of pointer to bool, which after all for
some is idiomatic style. But coupled with the (e.g. MSVC) silly-warnings, which
also on its own is a rather weak argument, I think it sums up to a good
argument. For AFAIK there's really no good reason to omit the comparision.

Cheers,

- Alf

== 4 of 5 ==
Date: Fri, Jan 30 2009 4:51 am
From: Pete Becker

On 2009-01-30 07:18:21 -0500, "Alf P. Steinbach" <alfps@start.no> said:

> * Pete Becker:
>>
>> Turn off stupid warnings.
>
> Sometimes, for some other warnings, that's the only practical recourse.
>
> However, in this particular case just writing explicit code as one
> ideally should anyway, makes that unnecessary, and not only for the
> original programmer but for all using the code.
>
> The code-should-be-explicit argument isn't, from my point of view, that
> compelling on its own for the conversion of pointer to bool, which
> after all for some is idiomatic style. But coupled with the (e.g. MSVC)
> silly-warnings, which also on its own is a rather weak argument, I
> think it sums up to a good argument. For AFAIK there's really no good
> reason to omit the comparision.
>

Didn't your mother teach you: two wrongs don't make a right?

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

== 5 of 5 ==
Date: Fri, Jan 30 2009 5:08 am
From: Lionel B

On Thu, 29 Jan 2009 17:07:41 +0000, Andrew Koenig wrote:

> "James Kanze" <james.kanze@gmail.com> wrote in message
> news:11b0ce6c-69ed-4764-aa5a-c3f8b971e2d5@s1g2000prg.googlegroups.com...
> On Jan 13, 8:46 am, Nosophorus <Nosopho...@gmail.com> wrote:
>
>> For historical reasons, a pointer implicitly converts to bool, with a
>> null pointer converting to false, and all other pointer values
>> converting to true. In general, it's better to avoid the implicit
>> convertion, and write what you mean:
>> if ( a != NULL ) ...
>
>
> Why do you think it's better? I don't think so, but maybe you can
> convince me.

It makes the intent of the coder clearer?

If I see "if (a != NULL)" I immediately know that a is a pointer and that
we're checking that it's not a null pointer. Or more precisely, if this
is /not/ the case, then I'm dealing with such a perverse coder that all
bets are off...

If I see "if (a != 0)" then I have fewer clues what's going on and quite
likely have to check a lot of other code to find out.

--
Lionel B

==============================================================================
TOPIC: Inline destructors and construtors
http://groups.google.com/group/comp.lang.c++/t/2e48514188bbc558?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, Jan 30 2009 2:37 am
From: James Kanze

On Jan 29, 1:04 pm, "abhijith....@gmail.com"
<abhijith....@gmail.com> wrote:
> What is the use of declaring inline destructors ?
> destructors gets called automatically which means for every
> object when it is about to get out of scope OR when we call
> delete etc. and hence it should be a function.

It is a function. The same reasons for inlining it apply that
apply for any function.

In practice, the only time I inline a destructor is in an
interface. Or when the profiler says I should.

> Also why we need inline constructors ?

For the same reason we need any inline function. Current
optimization technology isn't sufficient (at least in most
compilers).

In the case of special member functions (constructors,
destructors and the assignment operator), another reason for
inlining them in the case of interfaces may be to avoid needing
an implementation file. A call-back interface, for example,
will usually not have any implementation. It still requires a
user defined destructor, however, since the compiler provided
one won't be virtual. And in some cases, you might want to make
the constructor or the destructor protected. In such cases, it
seems silly to have to create a source file just for the empty
destructor, and I'll write:

class MyInterface
{
public:
virtual MyInterface() {}
// ...
} ;

== 2 of 3 ==
Date: Fri, Jan 30 2009 2:56 am
From: James Kanze

On Jan 30, 5:54 am, "Alf P. Steinbach" <al...@start.no> wrote:
> * abhijith....@gmail.com:

> > Making a virtual function inline is of NO use(even thousgh
> > it does nothing a empty body) as the function pointer is
> > needed and hence it WILL be a function istead of macro
> > definition....

> Some of your terminology seems to be garbled. I take it you
> mean that an 'inline' virtual routine will not be called
> virtually. Well, that's incorrect: a virtual routine is always
> called virtually or, with respect to possible optimizations,
> *as if* it had been called virtually.

> 'inline' does not affect that.

Inline (by definition in the standard) has NO effect on the
semantics of a function. On the other hand, a virtual function
will not be called virtually if there is an explicit qualifier,
e.g. MyClass::f().

More generally, I'm not sure what "to be called virtually"
means. I've never seen the expression in any serious technical
literature, and the "native English" meaning would be that the
function isn't called "really", only virtually. But that
doesn't make sense here, and as you say, his terminology is
rather garbled, so I'm supposing, as you apparently did, that he
means that the dynamic type of the object will determine the
actual function called, rather than the static type. In which
case, of course: if a virtual function is called without an
explicit qualifier, the function called is always determined
according to the dynamic type of the object. The only
exceptions (maybe) are the compiler generated calls to the
constructors and destructors of base classes, from the
constructor or destructor of the derived class.

Of course, how the compiler decides which function to call is
its business, as long as it calls the right one. Most compilers
use the vptr/vtbl mechanism to call a virtual function, when
they don't know what the actual most derived type will be, and
use exactly the same mechanism they use to call a non-virtual
function if they do know. (I know you know this, but somehow, I
have the impression that the original poster doesn't.) And most
compilers cannot "inline" a function if they don't know which
function is actually going to be called (although I've heard of
at least one compiler that can do this, in certain special
cases).

> > so my question was is it really necessary to have
> > destructors declared

> Nothing is strictly "necessary".

It depends. If you want the destructor of the base class to be
virtual, it's necessary to declare it; the compiler generated
default won't be virtual.

It's actually an interesting example, since if the base class is
abstract, the "virtual" destructor will never be called via the
virtual function mechanism (since this will always resolve to
the destructor of the most derived class); it will, however, be
called directly (as if qualified) by the destructors of the
derived classes.

> > as inline as its of no use, as it will be anyway a
> > function....

> Sorry, that's incorrect.

The second part isn't. In C++, an inline function is a
function.

> The guaranteed effect of 'inline', or equivalently for a
> member routine, defining a member routine in the class
> definition, is to allow this definition to occur in more than
> one compilation unit.

And to require this definition to be present in all compilation
units which use the function.

> Additionally, by having the source code available (i.e. the
> source code is available "inline" in e.g. a header file), this
> allows some optimizations such as machine code inlining
> without using costly global program optimization.

There's also a clear statement in the standard concerning
intent. A compiler should make a greater effort to generate the
code inline (suppressing the function call) if the function is
declared inline. From a QoI point of view, it's pretty much
like register: the compiler should respect it unless it can
actually do a better job at optimizing. The only difference
being that this is the case for register, for almost all
compilers, and it is not the case for inline, except for a very
few compilers (but the number is probably growing).

== 3 of 3 ==
Date: Fri, Jan 30 2009 3:28 am
From: "Alf P. Steinbach"

* James Kanze:
>
> I'm not sure what "to be called virtually"
> means. I've never seen the expression in any serious technical
> literature

Ah, terminology!

Always fun!

Well, the *international C++ standard* ISO/IEC 14882 uses the term "virtual
call" in two places.

The C++ standard is, IMHO, "serious technical literature"... ;-)

The original Smalltalk view is very clear on the effect of a virtual call. When
there is a source code call of a method with signature M on an object O, and the
method M is virtual in the statically known type of O, the execution effect is
as if a search for M starts in the most derived class of O's dynamic type. The
search for M goes upward all available base class chains, in any order, until an
M definition is found (the order doesn't matter because C++ guarantees that
there will be only one M reachable in this way, although higher up there may be
more). The found M is called with a pointer to O as the 'this' pointer.

Cheers, & hth.,

- Alf

PS: Yeah, I know you know what a virtual call is, even if you disagree with the
standard's terminology (as do I for some other terms). The explanation above is
for the benefit of other readers -- not all are aware of the Smalltalk view.

==============================================================================
TOPIC: What is wrong with this reference?
http://groups.google.com/group/comp.lang.c++/t/fa318e14d4a6b040?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 30 2009 3:10 am
From: James Kanze

On Jan 29, 2:31 pm, Michael <mich...@michaeldadmum.no-ip.org> wrote:
> This is the sample program:

> #include<cstdio>

> int main()
> {
> int*const a=new int;
> const int*const&b=a;
> printf("%p %p\n",&a,&b);
> delete a;
> return 0;
> }

> When running, it produces:

> 0x7fff1dc49fc8 0x7fff1dc49fb8

> That means the memory locations of a and b are different i.e.
> a and b is different object!

Obviously. The have different types (int* and int const*). One
object can never have two different types.

> I want to make something that *a is modifiable but *b is not
> (to be used inside a class) but the following code generates a
> compile-time error:

> #include<cstdio>
>
> int main()
> {
> int*a=new int;
> const int*&b=a;
> printf("%p %p\n",&a,&b);
> delete a;
> return 0;
> }

> test.cpp:6: error: invalid initialization of reference of type \u2018const int*&\u2019
> from expression of type \u2018int*\u2019

Consider the following:

int const a = 43 ;
int const* pa = &a ;
int* b ;
int const*& rb = b ; // This is what the compiler is
// complaining about
rb = pa ;
*b = 0 ;

If const is to mean anything, one of the last three statements
above must be illegal. And it's hard to imagine how to make the
last two illegal, so the conversion in the third from the bottom
is banned.

> The following code runs perfect:

> #include<cstdio>

> int main()
> {
> int a=new int;
> const int&b=a;
> printf("%p %p\n",&a,&b);
> return 0;
> }

I can't get it to compile. Are you sure about the initializer
of a?

With an initializer of type int, there's nothing wrong with it.
A reference to an int const can refer to an int that isn't
const, just as a pointer to an int const can refer to an int
that isn't const. It's when you start adding levels of
indirection that it stops working. A pointer or a reference to
a cv-qualified type can refer to anything of that type whose
cv-qualifications are less than or equal to those of the pointer
or reference. Thus, a reference to an int* const can refer to
an int*. But not to an int const*; the types (and not just the
cv-qualifiers) of the pointer are different.

> What is the problem in the first code (I am using g++ 4.2.4)?

Nothing. You initialized a reference with an rvalue, which
creates a temporary, and binds the reference to that temporary.

==============================================================================
TOPIC: cci
http://groups.google.com/group/comp.lang.c++/t/84b959f324eddb09?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 30 2009 3:22 am
From: oivanov134@gmail.com

СЛАБОНЕРВНЫМ НЕСМОТРЕТЬ Weak nerves? No to look.

http://usd5-75.clan.su/index/0-20

порно фото с знаменитостями
порно фото знаменитостями с
порно с фото знаменитостями
порно с знаменитостями фото
порно знаменитостями фото с
порно знаменитостями с фото
фото порно с знаменитостями
фото порно знаменитостями с
фото с порно знаменитостями
фото с знаменитостями порно
фото знаменитостями порно с
фото знаменитостями с порно
с порно фото знаменитостями
с порно знаменитостями фото
с фото порно знаменитостями
с фото знаменитостями порно
с знаменитостями порно фото
с знаменитостями фото порно
знаменитостями порно фото с
знаменитостями порно с фото
знаменитостями фото порно с
знаменитостями фото с порно
знаменитостями с порно фото
знаменитостями с фото порно
новые бесплатные порно ролики
новые бесплатные ролики порно
новые порно бесплатные ролики
новые порно ролики бесплатные
новые ролики бесплатные порно
новые ролики порно бесплатные
бесплатные новые порно ролики
бесплатные новые ролики порно
бесплатные порно новые ролики
бесплатные порно ролики новые
бесплатные ролики новые порно
бесплатные ролики порно новые
порно новые бесплатные ролики
порно новые ролики бесплатные
порно бесплатные новые ролики
порно бесплатные ролики новые
порно ролики новые бесплатные
порно ролики бесплатные новые
ролики новые бесплатные порно
ролики новые порно бесплатные
ролики бесплатные новые порно
ролики бесплатные порно новые
ролики порно новые бесплатные
ролики порно бесплатные новые
видео приколы эротика порно
видео приколы порно эротика
видео эротика приколы порно
видео эротика порно приколы
видео порно приколы эротика
видео порно эротика приколы
приколы видео эротика порно
приколы видео порно эротика
приколы эротика видео порно
приколы эротика порно видео
приколы порно видео эротика
приколы порно эротика видео
эротика видео приколы порно
эротика видео порно приколы
эротика приколы видео порно
эротика приколы порно видео
эротика порно видео приколы
эротика порно приколы видео
порно видео приколы эротика
порно видео эротика приколы
порно приколы видео эротика
порно приколы эротика видео
порно эротика видео приколы
порно эротика приколы видео
тинейджеры молодые порно
тинейджеры порно молодые
молодые тинейджеры порно
молодые порно тинейджеры
порно тинейджеры молодые
порно молодые тинейджеры
порно слайд шоу
порно шоу слайд
слайд порно шоу
слайд шоу порно
шоу порно слайд
шоу слайд порно
порно фото педофилов
порно педофилов фото
фото порно педофилов
фото педофилов порно
педофилов порно фото
педофилов фото порно
порно осликов
осликов порно

==============================================================================
TOPIC: optimization with GCC 4.1.1 yields invalid code
http://groups.google.com/group/comp.lang.c++/t/ed2de4b9682bc41b?hl=en
==============================================================================

== 1 of 4 ==
Date: Fri, Jan 30 2009 4:19 am
From: roland.arthaud@gmail.com

Hello,

I had to optimize my C code for speed to achieve some time constraints
in my requirements.
I tried -O3 to get best results, but my code crashed. I found out
looking at the generated assembly code, that the compiler failed to
notice subroutines with a pointer to a local variable might indeed
change it.

How come such an oversight happen?
Is there a way to prevent the compiler to do such risky assumptions?

Thanks for your help,
Roland.

PS: I use GCC 4.1.1 to compile C source to PowerPC assembly.
Also, even using -O1 gave me "corrupt" code.

== 2 of 4 ==
Date: Fri, Jan 30 2009 4:48 am
From: tni

You likely have an aliasing issue (you should post some code). Try
compiling with '-fno-strict-aliasing'. (GCC 4 is much more aggressive
with aliasing analysis than most other compilers.)

== 3 of 4 ==
Date: Fri, Jan 30 2009 4:54 am
From: SG

On 30 Jan., 13:19, roland.arth...@gmail.com wrote:
> I had to optimize my C code for speed to achieve some time constraints
> in my requirements.
> I tried -O3 to get best results, but my code crashed. I found out
> looking at the generated assembly code, that the compiler failed to
> notice subroutines with a pointer to a local variable might indeed
> change it.
>
> How come such an oversight happen?
> Is there a way to prevent the compiler to do such risky assumptions?

Aure you sure that it's not your fault? (read: Are you sure you don't
invoke undefined behaviour?) I can think of the following possibility:
The compiler rearranged some instructions in a way that you didn't
anticipate because you violated the strict aliasing rules.

Without seeing the code we can't tell for sure.

Cheers!
SG

== 4 of 4 ==
Date: Fri, Jan 30 2009 5:16 am
From: Lionel B

On Fri, 30 Jan 2009 04:19:53 -0800, roland.arthaud wrote:

> Hello,
>
> I had to optimize my C code for speed to achieve some time constraints
> in my requirements.

If it's C code you may be better off posting to comp.lang.c rather than
here.

> I tried -O3 to get best results, but my code crashed. I found out
> looking at the generated assembly code, that the compiler failed to
> notice subroutines with a pointer to a local variable might indeed
> change it.

Impossible to check without seeing any code.Why not post a minimal program
exhibiting the problem, then others can check your result.

If it is indeed a compiler bug then you should, of course, report it to
the developers.

> How come such an oversight happen?

If it is a bug, then the answer is: compiler writers are generally humans

> Is there a way to prevent the compiler to do such risky assumptions?

What risky assumptions exactly? In what context? We don't know without
seeing code.

> Thanks for your help,
> Roland.
>
> PS: I use GCC 4.1.1 to compile C source to PowerPC assembly. Also, even
> using -O1 gave me "corrupt" code.

So -O3 is not the problem?

--
Lionel B

==============================================================================
TOPIC: STL map with "count" method
http://groups.google.com/group/comp.lang.c++/t/44ba4e1927010e5f?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 30 2009 5:12 am
From: thomas

Hi,

A STL map doesn't allow two keys having the same value.
That's to say, a "count()" method will always return 1 or 0.
So why a "count()" is needed while we better call it "exist()"?

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

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

Friday, January 30, 2009

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

No comments:

Blog Archive

About Me