soft and program: comp.lang.c++ - 15 new messages in 8 topics

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

comp.lang.c++@googlegroups.com

Today's topics:

* casting int's to an enum - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/c1c282ce004187e6?hl=en
* I don't have to tell you... - 6 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/f615b948e5cca45b?hl=en
* HashTable - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c++/t/5a6dd10761e736f9?hl=en
* 田^_^田Whoelsale Brand new Nokia N97 and Apple Iphone 3Gs 16gb and 32gb,
Iphone 3G mobiles - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/340c589dd3a98a25?hl=en
* ♧♧♧♧♧♧Hot Sale Fashion Hoody Christina Audigier,Edhardy,Smet,Lacoste,BBC,EVS,
Coogi,Adidas,Bape,Polo Hoody ,BEST QUALITY - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/db08e84030c2e52c?hl=en
* Segmentation fault but now errors when running Valgrind - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/245ee50d3f1cbab8?hl=en
* ===Welcome to comp.lang.c++! Read this first. - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/1ff61ad698a84157?hl=en
* C++ Middleware Writer version 1.10 is now on line - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/291ac5193f237b76?hl=en

==============================================================================
TOPIC: casting int's to an enum
http://groups.google.com/group/comp.lang.c++/t/c1c282ce004187e6?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Nov 28 2009 3:22 pm
From: Angus

On 28 Nov, 15:06, Jonathan Lee <cho...@shaw.ca> wrote:
> On Nov 28, 6:00 am, Gert-Jan de Vos <gert-
>
> jan.de....@onsneteindhoven.nl> wrote:
> > You want runtime validation of a large range of values (ints) to a
> > small range and make a well defined mapping. Like this:
>
> > testenum get_testenum(int value)
> > {
> > switch (value)
> > {
> > case in: return in;
> > case out: return out;
> > case append: return append;
> > }
> > throw std::runtime_error("bad enum conversion");
>
> > }
>
> Agreed. Only change I would (possibly) make would be to return an
> "enumInvalid" value instead of throwing. Usually I define this to
> be -1. But that's only if you _expect_ or are going to handle the
> invalid conversions.
>
> --Jonathan

Or just call it unknown type if invalid type found.

== 2 of 2 ==
Date: Sat, Nov 28 2009 5:31 pm
From: Active Volcano

On Nov 28, 11:06 pm, Jonathan Lee <cho...@shaw.ca> wrote:
> On Nov 28, 6:00 am, Gert-Jan de Vos <gert-
>
> jan.de....@onsneteindhoven.nl> wrote:
> > You want runtime validation of a large range of values (ints) to a
> > small range and make a well defined mapping. Like this:
>
> > testenum get_testenum(int value)
> > {
> > switch (value)
> > {
> > case in: return in;
> > case out: return out;
> > case append: return append;
> > }
> > throw std::runtime_error("bad enum conversion");
>
> > }
>
> Agreed. Only change I would (possibly) make would be to return an
> "enumInvalid" value instead of throwing. Usually I define this to
> be -1. But that's only if you _expect_ or are going to handle the
> invalid conversions.
>
> --Jonathan

It seems that you want to change the type of creating file.
You need to give a default prameter. I recommend this type:

testEnum getFileCreat(int value)
{
testEnum ret = in;

switch (value)
{
case in:
ret = in;
break;

case out:
ret = out;
break;

case append:
ret = append;
break;

default:
ret = in;
}

return ret;
}

also,you need pay attention to the enum{in, out, append},
the value of enum is same with the std::in,std::out,std::append

==============================================================================
TOPIC: I don't have to tell you...
http://groups.google.com/group/comp.lang.c++/t/f615b948e5cca45b?hl=en
==============================================================================

== 1 of 6 ==
Date: Sat, Nov 28 2009 3:34 pm
From: Paavo Helde

Joshua Maurice <joshuamaurice@gmail.com> wrote in news:0695f935-8faf-40c0-
8828-0698d026169d@9g2000yqa.googlegroups.com:

> After reading more, I'm still not quite clear on what Howard Beale
> want, so I ask again. More clearly: what is wrong with C++, its order
> of construction and destruction, and how virtual calls interact.
>
> Let's first presuppose that constructors and destructors themselves
> are not broken. Correct me if you think they are.
>
> That leaves us with this heated, and quite unclear, discussion about
> which function should be called when you call a virtual function in a
> constructor or destructor. I think our options are:
>
> 1- Call function on uninitialized (or destroyed) derived class. This
> will almost certainly be bad, and not what the programmer intended (or
> the programmer is not familiar with the language and good code design,
> and the design is bad).

I think what he really wants is to define a function in derived class,
which can be called during construction and destruction of base class. As
such, this function cannot touch derived class data, neither call other
derived class functions which do this. This means that the function
effectively is a base class function, but defined in the derived class, and
presumably overrides some behavior of the base class function having the
samen name.

I just gave a C++ implementation example of such a function in another
post.

Regards
Paavo

== 2 of 6 ==
Date: Sat, Nov 28 2009 3:50 pm
From: "Alf P. Steinbach"

* Paavo Helde:
> Joshua Maurice <joshuamaurice@gmail.com> wrote in news:0695f935-8faf-40c0-
> 8828-0698d026169d@9g2000yqa.googlegroups.com:
>
>> After reading more, I'm still not quite clear on what Howard Beale
>> want, so I ask again. More clearly: what is wrong with C++, its order
>> of construction and destruction, and how virtual calls interact.
>>
>> Let's first presuppose that constructors and destructors themselves
>> are not broken. Correct me if you think they are.
>>
>> That leaves us with this heated, and quite unclear, discussion about
>> which function should be called when you call a virtual function in a
>> constructor or destructor. I think our options are:
>>
>> 1- Call function on uninitialized (or destroyed) derived class. This
>> will almost certainly be bad, and not what the programmer intended (or
>> the programmer is not familiar with the language and good code design,
>> and the design is bad).
>
> I think what he really wants is to define a function in derived class,
> which can be called during construction and destruction of base class. As
> such, this function cannot touch derived class data, neither call other
> derived class functions which do this. This means that the function
> effectively is a base class function, but defined in the derived class, and
> presumably overrides some behavior of the base class function having the
> samen name.
>
> I just gave a C++ implementation example of such a function in another
> post.

Uhm, this issue is covered in the FAQ.

Cheers & hth.,

- Alf

== 3 of 6 ==
Date: Sat, Nov 28 2009 5:16 pm
From: Howard Beale

Joshua Maurice wrote:

I think it's pretty clear from his first handful of posts that Howard Beale
just doesn't care much for C++ or OOP in general.

> Let's first presuppose that constructors and destructors themselves
> are not broken. Correct me if you think they are.

Well, more explicit control might be nice. For example, have the compiler
only call the most-derived class's constructor/destructor and allow the
programmer to call bases classes' constructors/destructors if and when
needed, in whatever order is safe. Then any virtual methods involved in
the process could also safely resolve to the most-derived class. And it
would just be more consistent, in general, because then constructors and
destructors would work like any other virtual method: code in the base
classes is overridden (not executed) unless explicitly called or
duplicated.

> That leaves us with this heated, and quite unclear, discussion about
> which function should be called when you call a virtual function in a
> constructor or destructor.

That was actually just one of the issues named, and everyone latched onto
that, specifically. Probably because it's fairly commonly a topic of
discussion here.

== 4 of 6 ==
Date: Sat, Nov 28 2009 5:23 pm
From: Howard Beale

Krice wrote:

> There is no other problem than people who suck as
> programmers. Some of them learn to become better programmers,
> others blame the programming language/paradigm.

Well, there you have it. Krice has settled the issue for us all. C++ is
perfect and if you complain about it you are an ugly, lame, retarded loser
with no life and no girlfriend and bad breath and skid marks in your
underwear. Thank you, Krice. Sorry that the rest of us are taking up
valuable space in your discussion group. I have just killfiled all users
in this group other than Krice, including myself, so that I can get right
down to the good stuff.

== 5 of 6 ==
Date: Sat, Nov 28 2009 11:25 pm
From: Joshua Maurice

On Nov 28, 12:29 pm, Pavel
<pauldontspamt...@removeyourself.dontspam.yahoo> wrote:
> BTW, I just found the reference to this article of Scott Meyers ibid in
> Wikipedia:http://www.artima.com/cppsource/nevercall.html. I think
> logically those who agree with this his opinion should agree to us
> (Howard and myself) as well: what a point in having a "safety feature"
> that is recommended to be used .. never?
>
> I say "logically" because Scott himself would apparently disagree:
>
> "... That's how every part of C++ will treat it, and the treatment makes
> sense: the BuyTransaction-specific parts of the object haven't been
> initialized yet, so it's safest to treat them as if they didn't exist".
>
> I, on the other hand, cannot see a big difference between calling any
> function within a constructor (where some parts of an object may not
> have been initialized yet) and calling a virtual function ibid. I
> believe that treating the derived-class object as "non-existing" before
> entering its construction function is an arbitrary and not very useful
> choice of the Standard.

Simple example.

//
#include <string>

struct F
{
virtual std::string const& name() const =0;
};
struct G : F
{
std::string name_;
virtual std::string const& name() const { return name_; }
};
//

Now, if I wrote that sample correctly, let's look at F and G. Suppose
F's constructor calls name() for debugging purposes. If it were to go
to the most derived but not yet constructed object G, then it would
return a reference to the not yet construct string sub-object, and any
attempt to use it would probably crash because it's not initialized:
the internal pointer of std::string would point to garbage and
dereferencing it would crash or be equivalently bad. Moreover, if
instead of string you had an object with virtual functions, then
calling anything on it would be bad because it's virtual table has not
yet been set up, so calling any virtual function on the sub-object
would horribly fail.

To repeat your statement:

> I
> believe that treating the derived-class object as "non-existing" before
> entering its construction function is an arbitrary and not very useful
> choice of the Standard.

Generally speaking, calling any sort of member function on any
nontrivial class which has not been initialized will dereference an
uninitialized pointer or do some equally bad thing because of the
uninitialized data. That's the reasoning behind this decision by the
standard to make virtual calls not go to member functions of classes
which have not yet been initialized or started initialization. I would
claim that it's quite a rare class which it makes sense to call member
functions on it without basic initialization of the data. (Well,
unless that member function is a setter, aka that member function is
initialization.)

It's a very useful guarantee to know that in a constructor that all of
your sub-objects (base class sub-objects and member sub-objects) have
been constructed. It's part of the whole thrust of C++ to not (easily)
allow access to unconstructed or destroyed objects. Ex: The "new"
operator returns a fully constructed object, you can't access an
uninitialized object through virtual pointers, etc. The whole language
and standard are built around this idea. I like it. It works for 99%
of cases. I don't recall yet seeing a case which I would actually want
to define a different construction order, nor call functions on an
object which has not been initialized.

== 6 of 6 ==
Date: Sat, Nov 28 2009 11:43 pm
From: Joshua Maurice

On Nov 28, 5:16 pm, Howard Beale <n...@none.none> wrote:
> Joshua Maurice wrote:
> > After reading more, I'm still not quite clear on what Howard Beale
> > want, so I ask again. More clearly: what is wrong with C++, its order
> > of construction and destruction, and how virtual calls interact.
>
> I think it's pretty clear from his first handful of posts that Howard Beale
> just doesn't care much for C++ or OOP in general.
>
> > Let's first presuppose that constructors and destructors themselves
> > are not broken. Correct me if you think they are.
>
> Well, more explicit control might be nice. For example, have the compiler
> only call the most-derived class's constructor/destructor and allow the
> programmer to call bases classes' constructors/destructors if and when
> needed, in whatever order is safe. Then any virtual methods involved in
> the process could also safely resolve to the most-derived class. And it
> would just be more consistent, in general, because then constructors and
> destructors would work like any other virtual method: code in the base
> classes is overridden (not executed) unless explicitly called or
> duplicated.

At this point, I think your opinions are rather irrelevant because
you're attacking all of OOP, not just this one small aspect of C++.
You're saying that X sucks because of some inherent quality of X. In
other words, I now see this as not really an attack on constructor
destructor order. Any sane OOP requires this constructor destructor
order. You just dislike OOP in general.

I still think you're wrong, but at least you're not longer acting as
if blatantly trolling. Your arguments have been much more civil and
reasonable.

To reply to this specific point:

> For example, have the compiler
> only call the most-derived class's constructor/destructor and allow the
> programmer to call bases classes' constructors/destructors if and when
> needed, in whatever order is safe.

My succinct reply is that I find automatic calling of sub-object
constructors to be a very useful syntactic sugar which saves typing
time and bugs (from not having to remember to construct my base class
sub-objects). In my years of programming I have never once found
myself wishing "If only I could delay construction of a sub-object for
just a little longer", or at least when I have wanted that, I just
change the member sub-object into a pointer and new and delete the
former sub-object whenever I need. (Maybe in a really crazy embedded
system this might come up, but then I really wouldn't be using such
OOP idioms anyway as I'm under different fundamental constraints.)

> > That leaves us with this heated, and quite unclear, discussion about
> > which function should be called when you call a virtual function in a
> > constructor or destructor.
>
> That was actually just one of the issues named, and everyone latched onto
> that, specifically. Probably because it's fairly commonly a topic of
> discussion here.

So, do you really want to allow calling functions on uninitialized or
de-initialized objects? Again, it breaks all of the standard idioms
and practices of C++, those which say you're only allowed to operate
on a "live" object. You rarely need to do anything else, and in those
rare situations, OOP isn't really what you'd be doing anyway, and you
can still do that other stuff in C++. C++ doesn't restrict you to
this, but it offers it to you. The best of both worlds for the
programmer who knows what he's doing.

==============================================================================
TOPIC: HashTable
http://groups.google.com/group/comp.lang.c++/t/5a6dd10761e736f9?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Nov 28 2009 4:10 pm
From: "Chris M. Thomasson"

"carl" <carl@.com> wrote in message
news:4b119ed2$0$275$14726298@news.sunsite.dk...
>I have found various hash_table implementation in c++ on the net. But I
>have not found any that returns the chain of objects associated with a
>hased index.
>
> When more that one object hash to the same index it gets added to a chain
> of elements.

Sometimes.

> Are there any implmentations that returns the whole chain based on a
> hashed index?

Perhaps. It would be trivial to create one yourself. Just create a static
hash table with a container per-bucket. Add a lookup function which returns
a reference to the hashed container.

> Its pretty much the functionality of a std::map that for each key contains
> a list (or std::vector) of the stored objects. But I would like the
> constant time lookup of the hash-table instead of the lg n time of a map.

== 2 of 2 ==
Date: Sat, Nov 28 2009 6:53 pm
From: Pavel

carl wrote:
> I have found various hash_table implementation in c++ on the net. But I
> have not found any that returns the chain of objects associated with a
> hased index.
>
> When more that one object hash to the same index it gets added to a
> chain of elements. Are there any implmentations that returns the whole
> chain based on a hashed index?
>
> Its pretty much the functionality of a std::map that for each key
> contains a list (or std::vector) of the stored objects. But I would like
> the constant time lookup of the hash-table instead of the lg n time of a
> map.
The functionality in std::map is actually slightly different and it *is*
available in hash maps:

You can iterate a sequence of objects with keys "Equal" or more
precisely, equivalent, to your given key using equal_range() methods of
both std::[multi]map and unordered_[multi]map (available in many current
C++ implementations in std::tr1 namespace or you can use
boost::unordered_map that provides the identical functionality).
(unordered_map is a hash table).

Additionaly to equal_range(), the following hash table-specific
functionality is available in unordered_map: you can retrieve a bucket
with bucket(key) call and iterate through the bucket but, if my reading
of C++0x specs is correct, you may encounter more than one hashcode in
the bucket (although it is guaranteed that you you will receive all
objects with the hash value equal to the one of your key in one bucket
and that the *average* length of the bucket is not greater than a
reasonably low constant).

If neither of the above alternatives is right for you, you may have to
implement your own hash table (or use the existing one and somehow
support the list or vector of elements with the equal hash codes on your
own). I am not aware of an implementation that does exactly what you
described (this certainly does not mean it is not available).

Hope this will help
-Pavel

==============================================================================
TOPIC: 田^_^田Whoelsale Brand new Nokia N97 and Apple Iphone 3Gs 16gb and 32gb,
Iphone 3G mobiles
http://groups.google.com/group/comp.lang.c++/t/340c589dd3a98a25?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Nov 28 2009 6:11 pm
From: "www.toptradea.com"

田^_^田Whoelsale Brand new Nokia N97 and Apple Iphone 3Gs 16gb and 32gb,
Iphone 3G mobiles
"Apple [www.toptradea.com ]
Nokia [www.toptradea.com ]
Blackberry [www.toptradea.com ]
Samsung [www.toptradea.com ]
Sony Ericsson [www.toptradea.com ]
HTC [www.toptradea.com ]
"

==============================================================================
TOPIC: ♧♧♧♧♧♧Hot Sale Fashion Hoody Christina Audigier,Edhardy,Smet,Lacoste,
BBC,EVS,Coogi,Adidas,Bape,Polo Hoody ,BEST QUALITY
http://groups.google.com/group/comp.lang.c++/t/db08e84030c2e52c?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Nov 28 2009 6:12 pm
From: "www.toptradea.com"

♧♧♧♧♧♧Hot Sale Fashion Hoody Christina
Audigier,Edhardy,Smet,Lacoste,BBC,EVS,Coogi,Adidas,Bape,Polo
Hoody ,BEST QUALITY
"Hoody Serieswww.toptradea.com

LRG-hoody www.toptradea.com

EVS-hoody www.toptradea.com

Coogi-hoody www.toptradea.com

Adidas-hoody www.toptradea.com

Bape-hoody www.toptradea.com

Polo-hoody www.toptradea.com

Lacoste-hoody www.toptradea.com

Ed hardy-hoody www.toptradea.com

Christina Audigier-hoody www.toptradea.com

BBC-hoody www.toptradea.com

Smet-hoody www.toptradea.com "
"Coat (www.toptradea.com)
Edhary-Coat (www.toptradea.com)

Juicy-Coat (www.toptradea.com)

Sweater (www.toptradea.com)
Juicy-Sweater (www.toptradea.com)

Edhardy-Sweater (www.toptradea.com)

High Heels (www.toptradea.com)
Edhardy-High-Heels (www.toptradea.com)

Louboutin-High-Heel (www.toptradea.com)

Louboutin-Heel-New (www.toptradea.com)"
"Necklace( www.toptradea.com ^_^)

Chanel-Necklace( www.toptradea.com ^_^)

Coach-Necklace( www.toptradea.com ^_^)

D&G-Necklace( www.toptradea.com ^_^)

Dior-Necklace( www.toptradea.com ^_^)

Juicy-Necklace( www.toptradea.com ^_^)

==============================================================================
TOPIC: Segmentation fault but now errors when running Valgrind
http://groups.google.com/group/comp.lang.c++/t/245ee50d3f1cbab8?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Nov 28 2009 7:28 pm
From: Ian Collins

carl wrote:
>
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:7ncc6uF3jv846U1@mid.individual.net...
>> carl wrote:
>>> I have made an application that throws a segmentation fault when I
>>> run it.
>>>
>>> ./MyApp
>>> Segmentation fault
>>
>> What happens when you run the application under a debugger?
>>
>
> I have tried that but the error first appears when a subrutine is called
> after 20.000 to 30.000 iterations. I have made something like this:

So? Let it run and let the debugger catch the seg fault.

--
Ian Collins

==============================================================================
TOPIC: ===Welcome to comp.lang.c++! Read this first.
http://groups.google.com/group/comp.lang.c++/t/1ff61ad698a84157?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Nov 28 2009 9:30 pm
From: Shiva

Welcome to comp.lang.c++! Read this first.

This post is intended to give the new reader an introduction to reading
and posting in this newsgroup. We respectfully request that you read
all the way through this post, as it helps make for a more pleasant
and useful group for everyone.

First of all, please keep in mind that comp.lang.c++ is a group for discussion
of general issues of the C++ programming language, as defined by the ANSI/ISO
language standard. If you have a problem that is specific to a particular system
or compiler, you are much more likely to get complete and accurate answers in a
group that specializes in your platform. A listing of some newsgroups is given
at the end of this post.

The FAQ (Frequently Asked Question) list has a wealth of information for
both the new and veteran C++ programmer. No matter what your experience
level, you are encouraged to read the entire list, if only to familiarize
yourself with what answers are available to minimize redundant replies.
The comp.lang.c++ FAQ is available at http://www.parashift.com/c++-faq-lite/

If the FAQ list does not help, then many regular readers of this group
are happy to assist with problems of standard C++. We have only a few
requests that we ask be adhered to, for the benefit of all:

* Please put a short summary in the subject line. Descriptions such as
"HELP!!!!!!" are not helpful, and many regular posters ignore such
requests. A good example is, "Problem with Virtual Functions."

* State the question or the problem clearly and concisely. Describe what
you are trying to do, and the problem you are running into. Include all
relevant error messages.

* Include the smallest, complete and compilable program that exhibits your
problem. As a rule, posters in comp.lang.c++ will not do homework, but will
give helpful hints if you have shown some willingness to try a solution.

* comp.lang.c++ is forum for discussion, and as such some regular posters do
not give E-mail replies. Very often follow-ups to postings have corrections,
so plan on taking part in the discussion if you post a question. If you
do receive e-mail replies, it is considered polite to post a summary.

* Don't post in HTML format. Many readers of this newsgroup don't use
newsreaders which can handle HTML postings.

* If you have to include source code in your post, include the
source in the message body. Don't use attachments. A lot
of contributors to this newsgroup won't even notice the existence
of attachments or won't open them. You try to get any help
you can get, don't you?

Some netiquette topics which frequently crop up on comp.lang.c++ are
also answered in the FAQ.

* Should I post job advertisements and/or resumes on comp.lang.c++?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.10

* What if I really need a job; should I post my resume on comp.lang.c++?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.11

* What should I do to someone who posts something off-topic?
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.12

A note on comp.lang.c++ etiquette: Accuracy is valued very highly in this
newsgroup; therefore posts are frequently corrected, sometimes perhaps
too harshly, and often to the annoyance of new posters who consider the
correction trivial. Do not take it personally; the best way to fit in
with comp.lang.c++ is to express gratitude for the correction, move on,
and be more careful next time.

This is a very busy group, so these requests are designed to make it as
pleasant and efficient an experience as possible. We hope it proves
a valuable commodity to you.

A list of some Newsgroups :
Languages and Programming
-------------------------
comp.lang.c The C Programming Language
comp.lang.asm.x86 x86 assembly language programming
comp.programming Non-language specific programming
comp.graphics.algorithms Issues of computer graphics

Operating Systems
-----------------
comp.os.msdos.programmer DOS, BIOS, Memory Models, interrupts,
screen handling, hardware
comp.os.ms-windows.programmer.win32 MS/Windows: Mice, DLLs, hardware
comp.os.os2.programmer.misc OS/2 Programming
comp.sys.mac.programmer.misc Macintosh Programming
comp.unix.programmer General Unix: processes, pipes, POSIX,
curses, sockets
comp.unix.[vendor] Various Unix vendors

Microsoft VC++
-------------
microsoft.public.vc.language VC++ issues
microsoft.public.vc.mfc MFC Issues
microsoft.public.dotnet.languages.vc C++/CLR Issues
microsoft.public.dotnet.framework .Net Framework

Borland C++ Builder
-------------------
borland.public.cppbuilder.language Borland C++ Builder
borland.public.cpp.language
borland.public.cppbuilder

-Shiva
http://www.slack.net/~shiva/welcome.txt

Sun Nov 29 00:30:00 EST 2009

==============================================================================
TOPIC: C++ Middleware Writer version 1.10 is now on line
http://groups.google.com/group/comp.lang.c++/t/291ac5193f237b76?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Nov 28 2009 11:43 pm
From: Brian

Release 1.10 of the C++ Middleware Writer is now available
on line. This release has the following changes:

1. Support added for stream constructors. Previously types
were required to have default constructors in order to be
(de)marshalled by the C++ Midddle Writer. A function named
Receive was then called to demarshall the object. Below is
an example of how the code has changed in this area. The
old version is shown first with some added comments to
indicate how things have changed in the new version.

inline void
Base::BuildPolyInstance(Buffer* buf, Base*& p)
{
unsigned short type_num; // --> uint16_t

buf->PersistentRead(&type_num, sizeof(type_num));
switch (type_num) {
case Base_num:
p = new Base; // --> p = new Base(buf);
break;

case Derived_num:
p = new Derived; // --> p = new Derived(buf);
break;

default:
throw failure("Base::BuildPolyInstance: Unknown type");
}

p->Receive(buf); // This typically virtual function call
} // is no longer needed.

// new version as of release 1.10.
inline void
Base::BuildPolyInstance(Buffer* buf, Base*& p)
{
uint16_t type_num;

buf->PersistentRead(&type_num, sizeof(type_num));
switch (type_num) {
case Base_num:
p = new Base(buf);
break;

case Derived_num:
p = new Derived(buf);
break;

default:
throw failure("Base::BuildPolyInstance: Unknown type");
}
}

2. Support added for int8_t, int16_t, int32_t, uint8_t,
uint16_t and uint32_t.

3. The command line interface to the C++ Middleware Writer --
http://webEbenezer.net/build_integration.html -- has been
tested on a big-endian Mac. The program also works on
little-endian machines.

I'm interested in hearing what your thoughts are on the
C++ Middleware Writer.

Shalom
Brian Wood
http://webEbenezer.net

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

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

Sunday, November 29, 2009

comp.lang.c++ - 15 new messages in 8 topics - digest

No comments:

Blog Archive

About Me