soft and program: comp.lang.c++ - 25 new messages in 14 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: Thurs, Jan 29 2009 12:09 am
From: Kai-Uwe Bux

fungus wrote:

> On Jan 29, 8:10 am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
>>
>> Thinking about the assignment operator now, a doubly linked list is
>> definitely easier.
>>
>
> I was also thinking of schemes like this, there's many
> ways of doing it.
>
> At a practical level though, I was more interested in what
> current implementations do.

Just a data point: I had a look at tr1 shipping with g++. It allocated a
small control block. Since this is based upon Boost, I think that Boost
uses this technique, too.

> If this is going to be the "standard" reference counted pointer then this
> choice is very important.

I am not sure whether there will be a uniform implementation. The standard
clearly leaves some room for vendor specific implementations; and vendors
might use this to compete.

Best

Kai-Uwe Bux

== 2 of 3 ==
Date: Thurs, Jan 29 2009 12:12 am
From: fungus

On Jan 29, 8:01 am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
>
> That is an obvious way to implement non-intrusive reference counting.

On a related note: Is there a proposal for intrusive
pointers on C++0x? I just did a quick google and
couldn't see one.

PS: I found a performance comparison of different schemes here:

http://www.boost.org/doc/libs/1_37_0/libs/smart_ptr/smarttests.htm

Reading between the lines it seems that the "allocate a little
control block" method is favored.

FTB.

== 3 of 3 ==
Date: Thurs, Jan 29 2009 1:14 am
From: Marcel Müller

Hi!

fungus wrote:
> This is a question about the implementation of shared_ptr:
>
> Does shared_ptr allocate a little control block to hold the reference
> count?

Yes.

> If so, this means double the number of memory allocations
> (one for the object, one for the pointer).

If you want to come around this you should have a look at intrusive_ptr.
It looks a bit complicated to implement the free functions
intrusive_ptr_add_ref and intrusive_ptr_release. But there is a very
simple and generic solution: write a simple abstract base class for the
reference count.

Something like that:

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) {}
virtual ~ref_count() {}
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.
};

void intrusive_ptr_add_ref(ref_count* ref)
{ interlocked_increment(&ref->count);
}

void intrusive_ptr_release(ref_count* ref)
{ interlocked_decrement(&ref->count);
if (!ref->is_managed())
delete ref;
}

Now all you have to do for an intrusive reference count is to inherit
from ref_count. This will add the size of the reference count to your
data object, and the intrusive pointer instances are binary identical to
ordinary C pointers. Of course, they are semantically different.
Whether the virtual table pointer of ref_count takes additional space
depends. If your object is polymorphic anyway and you derive from
ref_count without multiple inheritance, there is usually no additional
space required.

If you do not want ref_count to have to have virtual functions all you
have to change is to move the delete operation in a template function
that is aware of the real type of your object. In this case you can
safely downcast ref_count* to your type and delete the result. This will
allow you to use non-polymorphic objects with intrusive_ptr. Of course,
the destructor of ref_count has to be non-virtual in this case.

Note that the above implementation is thread-safe, as long as you
provide appropriate interlocked increment and decrement functions.

Marcel

==============================================================================
TOPIC: Threading in C++
http://groups.google.com/group/comp.lang.c++/t/6ac41c5f8d84326c?hl=en
==============================================================================

== 1 of 4 ==
Date: Thurs, Jan 29 2009 12:16 am
From: Ambreen Ashfaq Afridi

hi all
im new to threading in C++. Can any of you plz post a very simple and
well explained example of threading in c++, and also which files and
namespaces to include.
thanks a lot

== 2 of 4 ==
Date: Thurs, Jan 29 2009 12:27 am
From: "Fred Zwarts"

"Ambreen Ashfaq Afridi" <amboafridi@gmail.com> wrote in message news:7db61330-8bf7-4a04-8c71-29edc01e0f25@p36g2000prp.googlegroups.com...
> hi all
> im new to threading in C++. Can any of you plz post a very simple and
> well explained example of threading in c++, and also which files and
> namespaces to include.
> thanks a lot

Threading is not defined in C++.
The threading models of e.g. Linux and Windows are a bit different,
so you need a platform specific solution or use a library has a
uniform interface for different platforms. Such a solution may
not be portable to all platforms with a standard C++ compiler.

== 3 of 4 ==
Date: Thurs, Jan 29 2009 3:05 am
From: peter koch

On 29 Jan., 09:16, Ambreen Ashfaq Afridi <amboafr...@gmail.com> wrote:
> hi all
> im new to threading in C++. Can any of you plz post a very simple and
> well explained example of threading in c++, and also which files and
> namespaces to include.
> thanks a lot

Take a look at boost. As Fred Zwarts told you, threading is not part
of the current C++ standard. But the next standard will include
threading, and boost should be a close approximation to what is going
to be in the next standard.

/Peter

== 4 of 4 ==
Date: Thurs, Jan 29 2009 5:34 am
From: "abhijith.net@gmail.com"

On Jan 29, 1:27 pm, "Fred Zwarts" <F.Zwa...@KVI.nl> wrote:
> "Ambreen Ashfaq Afridi" <amboafr...@gmail.com> wrote in messagenews:7db61330-8bf7-4a04-8c71-29edc01e0f25@p36g2000prp.googlegroups.com...
>
> > hi all
> > im new to threading in C++. Can any of you plz post a very simple and
> > well explained example of threading in c++, and also which files and
> > namespaces to include.
> > thanks a lot
>
> Threading is not defined in C++.
> The threading models of e.g. Linux and Windows are a bit different,
> so you need a platform specific solution or use a library has a
> uniform interface for different platforms. Such a solution may
> not be portable to all platforms with a standard C++ compiler.
In addition to above, Thereadign is gettign standardized, so will be
there soon in C++
http://www.youtube.com/watch?v=JffvCivHEHU&feature=channel
http://www.youtube.com/watch?v=mrvAqvtWYb4

==============================================================================
TOPIC: multiple inheritance, name collision in base classes
http://groups.google.com/group/comp.lang.c++/t/8b796c69e0e14079?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 29 2009 12:25 am
From: James Kanze

On Jan 28, 3:36 pm, JenC <jcarl...@gmail.com> wrote:

> I have a problem regarding multiple inheritance and name
> collision in the base classes.
> The problem looks like:

> class BaseA
> {
> ...
> public:
> virtual unsigned int Run();
> ...
> }

> class BaseB //note, BaseB is an abstract class
> {
> ...
> public:
> virtual customType Run() = 0;
> ...
> }

> class Derived: public BaseA, public BaseB
> {
> ...
> public:
> virtual customType Run(); //only need to implement/override
> BaseB's Run()
> }

> The problem is that both base classes have a function
> Run(void) differing only in their return types, and hence I
> get a compilation error. Is there a way that I can specify
> that in class Derived I am overriding BaseB's Run() method?

Not directly.

> Changing the functions signature of BaseB::Run() is a last
> resort option (BaseA cannot be changed), but it will affect a
> large amount of code, so I would rather find a different less
> invasive solution. Any ideas??

The classical solution is to introduce an intermediate class
which "renames" the function:

class BaseB2 : public BaseB
{
public:
virtual customType Run()
{
return doRun() ;
}

virtual customType doRun() = 0 ;
} ;

class Derived : public BaseA, public BaseB2
{
public:
virtual customType doRun() ;
} ;

--
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

==============================================================================
TOPIC: How to understand the C++ specification?
http://groups.google.com/group/comp.lang.c++/t/28b14a1308974070?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Jan 29 2009 12:30 am
From: James Kanze

On Jan 28, 6:17 pm, Noah Roberts <n...@nowhere.com> wrote:
> James Kanze wrote:
> > What it means is that I don't use constructs I (or my collegues)
> > can't understand, and that we don't know what they do.

> ...and of course you know exactly what everything in C++ does without
> looking at the standard...ever.

> Well, James, looks like I'm just not as smart as you are. In
> order to know what things do in C++ I have to read how the
> various combinations of constructs work within C++. Only then
> can I write maintainable code I understand.

If you have to look things up in the standard, then you're not
writing code you (or someone else) can maintain. You're working
too near the limits (and the code wouldn't pass code review in
any place I've worked).

== 2 of 2 ==
Date: Thurs, Jan 29 2009 12:37 am
From: James Kanze

On Jan 28, 6:24 pm, Noah Roberts <n...@nowhere.com> wrote:
> Oh, and...

> James Kanze wrote:
> > Getting the job done, in my case, means writing code that
> > works, and that can be maintained. I know that that's an
> > unusual requirement. It's much more fun to experiment.

> I think you just proved my point. If you've never HAD to experiment
> then you've simply never written anything particularly difficult. I
> suppose you spent your entire learning period not experimenting too.
> That's just sad.

Isn't it beautiful, people who like to play word games, instead
of worrying about real issues.

Obviously, I experiment. But I don't deliver experimental code.
And I don't need to look things up in the standard to
experiment, since I know that if I do, even if the experiment
works, I can't use it, because 1) my collegues won't understand
the code, and 2) it's likely that some compiler will not get it
right either (and in the end, what matters isn't what the
standard says, but what the compiler does). I don't experiment
with the language much (except for amusement); I have enough
other problems which have to be solved. (As one employer put
it: I'm not being paid to stress test the compiler. *IF* you're
employed to test a compiler for compliance, then of course you
will read the standard. A lot. But that's not the case of most
of us.)

> Yes, I'm proud to admit that much of my knowledge comes from
> experimenting, failing, and having to look at the standard to
> see why what I'm doing is nonsense.

I fail to see how you can find out whether something is nonsense
by looking it up in the standard. (For that matter, the
standard is often "wrong", compared to the compilers I'm using.)

> My knowledge came from years of hard work and many, many
> mistakes. Where did yours come from?

Most of it comes from communicating with collegues. I've
learned an awful lot from other peoples mistakes. And vice
versa, of course. My collegues learn from my code. Which is
one of the reasons why it's so important to make it readable.

==============================================================================
TOPIC: Not really late to greet myself too
http://groups.google.com/group/comp.lang.c++/t/6672566c0f395884?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 29 2009 12:36 am
From: gentlerobbin@gmail.com

But hey! to all that celebrate and enjoy this special occasion,
::::::::*****.....$$$ Happy New Year $$$...... *****:::::::::
::::::::*****.....$$$ Happy New Year $$$...... *****:::::::::

*****Ali, Marie, Susie, Bobbie (Y), Tina etc, of course Me too*****

==============================================================================
TOPIC: Closing file streams
http://groups.google.com/group/comp.lang.c++/t/ba834866d238a9fa?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 29 2009 12:41 am
From: James Kanze

On Jan 28, 6:39 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> James Kanze wrote:
> > And I'm not too sure what you mean by "sharing" here.

> I was talking about shared ownership (rather than shared
> usage). In other words, the last owner cleans up (and the last
> owner might change from execution to execution). This
> obviously cannot be done with raw pointers only.

Interestingly, I've never encountered a case where shared
ownership (as a design concept) applied in a real application.
Sometimes, with C++, you use it in cases where there is no real
ownership at the design level, because the lack of garbage
collection in C++ means that you often need to artificially
introduce ownership into the design where it isn't appropriate,
but this is "implementation design". I don't think of it as
"shared ownership", but as a technical work-around of a weakness
in the language.

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

== 1 of 4 ==
Date: Thurs, Jan 29 2009 1:06 am
From: James Kanze

On Jan 28, 3:38 pm, ManicQin <Manic...@gmail.com> wrote:

> I have a list of COperation* and I add Operations, each
> Operation has a scale and before I execute the list i want to
> sort them

> I have the next snip:

> class COperation
> {
> public:
> virtual int GetScale() const { return -1; }
> };

> typedef COperation* PCOperation;
> typedef std::list<PCOperation> tOpStack;

> struct greaterScale : public std::greater<PCOperation>
> {
> bool operator()(const PCOperation& x,const PCOperation& y)
> {
> if (x->GetScale() != -1 && y->GetScale() != -1 && y->GetScale() > x->GetScale())
>
> {
> return true;
> }
> return false;
> }
> };

> later I try to call:
> tOpStack m_OpStack;
> m_OpStack.sort(greaterScale());

That's not a legal predicate for sort. Sort (and all other
ordering functions in the standard library) require that the
expression pred(a, b) && pred(b, a) define an equivalence
relationship. Equivalence relationships must be transitive,
i.e. a===b and b===c iff a===c. Your predicate doesn't have
this characteristic---if b.GetScale() returns -1, b will be
equivalent to a and c, even if a and c aren't equivalent.

> when I enter the sort I see that instead of using my
> greaterScale pred he is using the normal greater pred...

That would surprise me. How do you conclude this?

> I'm guessing that my greaterScale isn't using the correct
> signature and the compiler cant deduce the correct operator()
> but why?

The greaterScale::operator() should be const, so you formally
have undefined behavior. But in practice, if it compiles, it
will work.

> what am I doing wrong?

Not fulfilling the requirements on the ordering predicate.
Resulting in undefined behavior.

A few other minor comments (not related to your actual problem,
but important for writing good code):

-- The C prefix for classes is used by MFC. It's best to avoid
it in your own code. (Now that we have namespaces, there's
not really a need of a prefix anyway.)

-- The typedef for the pointer is more obfuscation than
anything else. If you're using pointers, the reader should
be able to easily see this. (The typedef might be justified
in order to easily migrate to boost::shared_ptr, or some
other intelligent pointer. In that case, however, the name
should indicate that it is a pointer, e.g. OperationPointer.
My own convention in such cases is to use a typedef in the
class, e.g. in class Operation, something like:
typedef Operation* Pointer ;
or
typedef boost::shared_ptr< Operation > Pointer ;
This results in Operation::Pointer, which seems reasonably
readable.)

-- And using a single if to return true or false is confusing
as well, at least to anyone who knows what a bool is. Just
return the expression.

== 2 of 4 ==
Date: Thurs, Jan 29 2009 1:13 am
From: James Kanze

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.)

== 3 of 4 ==
Date: Thurs, Jan 29 2009 1:24 am
From: ManicQin

On Jan 28, 6:57 pm, "Thomas J. Gritzan" <phygon_antis...@gmx.de>
wrote:
> ManicQin schrieb:
>
> > If it was a function I should call without the brackets but because
> > it's a functor
> > I need to call it with...
> > I Copy Pasted the next code chopped it for un-relevant things so dont
> > try to understand
> > the point behind it.
> > I tested it with VS6 and it didn't work... (it's compiling ok)
> > Any thoughts people?
>
> [...]
> > struct greaterScale : public std::greater<PCOperation>
>
> struct greaterScale : public std::binary_function<PCOperation,
> PCOperation, bool>
>
> > {
> > bool operator()(PCOperation x,PCOperation y)
>
> bool operator()(PCOperation x, PCOperation y) const
>
>
>
> > {
> > if (x->GetScale() != -1 && y->GetScale() != -1 && y->GetScale() > x-
> >> GetScale())
> > {
> > return true;
> > }
>
> > return false;
> > }
> > };
>
> > int main()
> > {
> > tOpStack blabla;
>
> > blabla.push_back(new CLiftNozzle_(1));
> > blabla.push_back(new CReturnNozzle_(1));
>
> > blabla.sort(greaterScale());
> > return 0;
> > }
>
> --
> Thomas

Ok... Forget about the -1 in the pred.
My question is specifically about the reason why it is not using my
pred and not why the sort is weird...
Thomas I tried it already but 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 *>'
If I dont inherit I get the same error BTW

About the -1 in the predicate.
I need to sort only a few items and I have "Anchors" that should not
be moved.
If my list is -1 -1 -1 5 4 3 -1 -1 9 -1
I want it to be -1 -1 -1 3 4 5 -1 -1 9 -1
But again this is not relevant to my question please ignore it.

== 4 of 4 ==
Date: Thurs, Jan 29 2009 1:33 am
From: ManicQin

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.)
>
> --
> James Kanze (GABI Software) email:james.ka...@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

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 *>

==============================================================================
TOPIC: Beginner: where to next?
http://groups.google.com/group/comp.lang.c++/t/b583f7cfdd2b32d4?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Jan 29 2009 1:07 am
From: Bart van Ingen Schenau

On Jan 28, 10:52 pm, eminha...@googlemail.com wrote:
> hi all,
>
> i've just learned the basics of c++ and was wandering where to go from
> here.
> should i go looking for libraries(perhaps boost?) or learn more of the
> c++ syntax? erm, you see
> the thing is i get bored writing programs that add numbers or store
> data in text files... i want to get to
> the interesting stuff e.g graphics,networking,process's...
> but i'm not sure i'll understand it all...
>
> well, if i have i'll continue on the syntax and language structure but
> i'd prefer to get down and dirty. :-)
>
> thanks e.h.k

I would say, if you feel reasonably comfortable with the syntax and
the basic ideas of C++ (functions, variables, classes, control
statements, using templates), then by all means go ahead and start on
an interesting project.
Unless you are an exceptionally gifted programmer, there _will_ be
times that you don't know how things are supposed to work or how to
continue. That is no shame.
Just come by and ask questions about what you don't understand. Only,
don't be offended if we redirect you to another source of information.
Sometimes, those interesting things are just impossible in standard C+
+ and you need a platform-specific solution for which the experts
reside elsewhere.

Regards,
Bart v Ingen Schenau

== 2 of 2 ==
Date: Thurs, Jan 29 2009 1:19 am
From: nick_keighley_nospam@hotmail.com

On 28 Jan, 22:27, Christopher <cp...@austin.rr.com> wrote:
> On Jan 28, 3:52 pm, eminha...@googlemail.com wrote:

> > i've just learned the basics of c++ and was wandering where to go from
> > here.
> > should i go looking for libraries(perhaps boost?) or learn more of the
> > c++ syntax? erm, you see
> > the thing is i get bored writing programs that add numbers or store
> > data in text files... i want to get to
> > the interesting stuff e.g graphics,networking,process's...
> > but i'm not sure i'll understand it all...
>
> > well, if i have i'll continue on the syntax and language structure but
> > i'd prefer to get down and dirty. :-)
>
> All those things take years and years of research and experience. Just
> like when you pick up the guitar, you can't expect to jump on stage
> and be an instant star playing Van Halen. Get good at all those boring
> things because they are going to be required to do the more
> interesting things.

I think that's a mistake. It's as if the budding guitar player was
told "you aren't Van Halen[1] so you must only do scales".

Yes you need all that basic stuff but you don't have to
memorize the entire C++ spec before you write a single
useful or fun application.

If you want to do graphics then a find a C++ graphics
library[2] you like and write something simple. Draw a graph,
bounce a ball, Penrose tile a plane. Your first cut
may be bad code but you can hardly fail to learn something
from it. Isn't programming supposed to be *fun*?!

[1] he's a guitarist, right?
[2] I did it on windows using Win32. That may
not be the best choice but it's easily available.

--
Nick Keighley

==============================================================================
TOPIC: template specialization for a non-member function
http://groups.google.com/group/comp.lang.c++/t/cba66df25baa90e2?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 29 2009 1:19 am
From: James Kanze

On Jan 28, 7:52 pm, Noah Roberts <n...@nowhere.com> wrote:
> puzzlecracker wrote:

> > would you refresh my memory, before I start a compiler, as
> > to whether standard supports partial template specialization
> > non-member function? references would be appreciated too!

> Before you start a compiler I'd recommend you have the standard on hand
> and have it pretty well memorized...at least those sections before the
> library description.

I think (or hope, at least) that he meant "start a compile", and
not "start a compiler"; i.e. that he is going to compile some
code, and not write a compiler. If he's going to write code
using templates, he probably should have read the Josuttis and
Vandevoorte, and have it handy. The standard's not much use in
such cases, however, since it's fairly unreadable, and real
compilers don't always follow it that closely anyway. (The
Josuttis and Vandevoorte is actually exceptional in this regard,
in that it treats both the theory and the practice, making it
quite clear which is which.)

==============================================================================
TOPIC: Reference question
http://groups.google.com/group/comp.lang.c++/t/1f51f5f50a68e14f?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Jan 29 2009 1:28 am
From: James Kanze

On Jan 28, 7:24 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> Larry.Mart...@gmail.com wrote:
> > I have only been working with C++ for 3 years, and I've come across
> > some code I don't understand.

> > static struct ct {
> > char ns, fl;
> > short sf;

> > struct st
> > {
> > char sy, fq;
> > ct* n;
> > } __attribute__ ((packed)) * sta;

> > st& os() const
> > {
> > return (st&) sf;
> > }
> > } __attribute__ ((packed)) *mc;

> > My confusion is about the os method. It appears to me that
> > it returns a reference to the st struct. But how does
> > returning sf become a reference to st?

> Beats me. They are probably trying to rely on some obscure
> memory layout compatibility that exists between the beginning
> of the 'st' struct and a 'short'. Generally speaking a cast
> like that is a VERY BAD IDEA(tm).

The key, I think, is the presence of __attribute__((packed)) all
over the place. This is obviously very platform dependent code
(and probably very low level); without knowing the exact
platform, and the context in which it occurs, we can't say any
more (and knowing all that, of course, the response would be off
topic here). Generally speaking, as you say, the cast like that
is a very bad idea, but I can imagine cases in the kernel of an
OS where it might be appropriate.

(One thing does worry me a bit---the __attribute__ is g++
syntax, so I would assume g++. And g++ generates bad code when
such casts are used, on the grounds that the results are
undefined behavior. So the "implementation defined" behavior of
what he is doing is "undefined behavior".)

== 2 of 2 ==
Date: Thurs, Jan 29 2009 5:05 am
From: Pete Becker

On 2009-01-28 19:37:52 -0500, Jeff Schwab <jeff@schwabcenter.com> said:

> Pete Becker wrote:
>> On 2009-01-28 18:43:40 -0500, Jeff Schwab <jeff@schwabcenter.com> said:
>>
>>> Chris Gordon-Smith wrote:
>>>
>>>> I used to write 'Molecule_Type', but now I write 'MolType'.
>>>
>>> Why? Doesn't your editor support auto-completion? Don't get me wrong;
>>> if it's your code, you get to choose the names. Those kinds of
>>> abbreviations can make life a lot less pleasant, though, for anyone
>>> else who has to maintain the code.
>>
>> Reading code with long names can be frustrating, especially if you have
>> to scroll the screen to see the entire line, or if lines have to be
>> broken at odd places in order to fit on a screen. Operators, being one
>> or two characters, can be hard to find in a welter of words.
>
> That's a sign that it's past time to refactor. The solution is not to
> start abbreviating. If you have a bunch of names that all start with
> Molecule, there probably ought to be a molecule namespace. Given
> crappy code, the solution is not to make it crappier.

I don't see how changing Molecule_type to Molecule::Type relieves the problem.

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

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

== 1 of 1 ==
Date: Thurs, Jan 29 2009 4:04 am
From: "abhijith.net@gmail.com"

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.

Also why we need inline constructors ?

==============================================================================
TOPIC: book?
http://groups.google.com/group/comp.lang.c++/t/69579148c0037034?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 29 2009 4:40 am
From: "abhijith.net@gmail.com"

On Jan 29, 9:08 am, want to learn <rsseni...@gmail.com> wrote:
> hi,
> can you please suggest any good book to study c++.

"The C++ Programming Language" By Bjarne himself.

==============================================================================
TOPIC: Corruption of the heap
http://groups.google.com/group/comp.lang.c++/t/3e995d2ee9c2a78e?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 29 2009 5:01 am
From: Pete Becker

On 2009-01-29 01:04:19 -0500, Rolf Magnus <ramagnus@t-online.de> said:

> gw7rib@aol.com wrote:
>
>> On 20 Jan, 22:17, ssylee <staniga...@gmail.com> wrote:
>>> This is going to be my last post on the topic. Apparently, there was a
>>> buffer overrun. After I made some minor changes to an object
>>> instantiation, that problem is gone.
>>
>> "Apparently"?? I'd recommend having a look though the code as it was,
>> and as it is now, to check that there was a problem before and that it
>> is now fixed. For one thing, this will make sure that the problem has
>> indeed gone, and is not simply lurking there ready to find a new way
>> of showing itself, and also, you may think of other bits of the
>> program which also need checking.
>
> As a general rule of thumb: A bug isn't fixed as long as you don't know
> exactly why it's fixed.

Another way to put it is bugs that go away by themselves come back by
themselves.

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

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

== 1 of 1 ==
Date: Thurs, Jan 29 2009 5:31 am
From: Michael

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! 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 'const int*&'
from expression of type 'int*'

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;
}

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

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

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, January 29, 2009

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

No comments:

Blog Archive

About Me