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

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

comp.lang.c++@googlegroups.com

Today's topics:

==============================================================================
TOPIC: call a C++ function from C?
http://groups.google.com/group/comp.lang.c++/t/934c5e8f367583af?hl=en
==============================================================================

== 1 of 3 ==
Date: Sun, Mar 29 2009 5:40 am
From: MiB

Another guess: did you really create "file2.c" or is it "file2.C" ?
I remember vaguely this made a difference for the assumed programming
language for gcc.

MiB

== 2 of 3 ==
Date: Sun, Mar 29 2009 6:03 am
From: Pallav singh

On Mar 29, 5:40 pm, MiB <Michael.Boehni...@gmail.com> wrote:
> Another guess: did you really create "file2.c" or is it "file2.C" ?
> I remember vaguely this made a difference for the assumed programming
> language for gcc.
>
> MiB

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++

can we call member functions (incl. virtual functions) of Class in C++
from C ?

== 3 of 3 ==
Date: Sun, Mar 29 2009 9:08 am
From: MiB

On Mar 29, 3:03 pm, Pallav singh <singh.pal...@gmail.com> wrote:

> can we call member functions (incl. virtual functions) of Class in C++
> from C ?

For non-static member functions, you need an object for that kept by
the C++ wrapper.

Note, the following code is just a sketch. Essentially, a repository
of created objects is kept and is
referenced by handles of type integer.

I am sure it can be done much nicer and needs extra work for thread
safety and fault tolerance. The performance
can be improved by using a std::vector<> instead of a map but you may
need to keep track of used and free entries
in the repository.

The scheme works with polymorphism, though - if the factory function
"CreateMyClassObject()", or extra functions
added for this purpose, create objects of derived classes, virtual
member functions are called properly.
Make sure the MyBaseClass destructor is virtual to avoid pitfalls
here.

-------------------------------------------------------------------------------------------------
ExampleUsage.c:

#include "Wrapper.h"

...
int handle = CreateMyClassObject();

printf( "%d\n", ExampleMemberFunc( handle, 42 ) );

DestroyMyClassObject( handle );

-------------------------------------------------------------------------------------------------
MyClass.hpp:

class MyClass {
public:
int ExampleMemberFunc( int x );
};

-------------------------------------------------------------------------------------------------
Wrapper.h:

extern "C" {

int CreateMyClassObject(); // you need to add parameters as your
constructor requires.
void DestroyMyClassObject( int handle );
int ExampleMemberFunc( int handle, int x ); // note the added handle
param.

}

-------------------------------------------------------------------------------------------------
Wrapper.cc:

#include "MyClass.hpp" // defines the class you want to wrap.
#include <map>

static std::map<int, MyClass*> myclassrepository;

extern "C" {

int CreateMyClassObject() { // you need to add parameters as your
constructor requires.
myclassrepository[ myclassrepository.size() ] = new MyClass();
return myclassrepository.size() - 1; // index of created object.
}

void DestroyMyClassObject( int handle ) {
std::map<int, MyClass*>::iterator p = myclassrepository.find
( handle );
if ( p != myclassrepository.end() ) {
delete p->second;
myclassrepository.remove( p );
}
}

int ExampleMemberFunc( int handle, int x ) {
std::map<int, MyClass*>::iterator p = myclassrepository.find
( handle );
if ( p == myclassrepository.end() ) {
// Error Handling, no object for this handle.
return 0;
}

return p->second->ExampleMemberFunc( x );
}

} // extern "C"

==============================================================================
TOPIC: Standard C++ way to generate a Jump Table ???
http://groups.google.com/group/comp.lang.c++/t/7686e7082cfac191?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Mar 29 2009 5:52 am
From: "Peter Olcott"

"Paavo Helde" <paavo@nospam.please.ee> wrote in message
news:Xns9BDD7CFB6C50Enobodyebiee@216.196.109.131...
> "Peter Olcott" <NoSpam@SeeScreen.com> kirjutas:
>>
>> This can be easily corrected as a type mismatch compile
>> time
>> error. Only enumeration names would be allowed as
>> specified
>> enumeration values. These names could be cast to
>> integers,
>> but, the reverse cast would be disallowed.
>
> Except that this would probably break lots of existing
> code, and introduce
> a serious discrepancy with C. The current standard is
> carefully worded to
> allow using enum values composed from bit flags, and I
> believe there are
> many programs using that feature. Also deserialization of
> enum values from
> an external source would become much more complicated.
>
> For helping the compiler to optize away impossible
> branches, I would prefer
> to mark them explicitly, e.g.
>
> switch(x) {
> case a: break;
> case b: break;
> default: std::never();
> }
>
> This would work the same as MSVC __assume(0), but avoiding
> the logical
> ping-pong of first assuming falsehood and then deriving
> something out of
> it.
>
> Paavo
>
>
>

Okay, that sounds like an improvement over what I said. I
don't think that referring to it as a part of the standard
template library is ideal, some other equivalent syntax may
provide the next increment of additional improvement.

== 2 of 2 ==
Date: Sun, Mar 29 2009 10:27 am
From: "Peter Olcott"

"Paavo Helde" <paavo@nospam.please.ee> wrote in message
news:Xns9BDB5D92C2CDBnobodyebiee@216.196.109.131...
> "Peter Olcott" <NoSpam@SeeScreen.com> kirjutas:
>
>> This is as close as I could get to generating the
>> equivalent
>> of an assembly language jump table:
>>
>> switch(N)
>> {
>> case 0:
>> case 1:
>> case 2:
>> case 3:
>> case 4:
>> case 5:
>> case 6:
>> case 7:
>> }
>>
>> mov eax, DWORD PTR _N$[esp-4]
>> cmp eax, 7
>> ja SHORT $LN1_TestSpeed
>> jmp DWORD PTR $LN14_TestSpeed[eax*4]
>>
>> I am looking for a way to be able to specify C++ code
>> such
>> that the second and third line of the assembly language
>> would not be generated. The only way that I can think to
>> do
>> this is to delete the two lines and compile it as
>> assembly
>> language.
>
> Out of curiosity - have you measured how much effect
> deleting these two
> lines would give you? (Presuming of course there are some
> non-empty cases,
> otherwise the compiler should optimize the whole
> construction away.)

By keeping optimization in sharp focus throughout every
aspect of the detailed design the final performance will be
at least 10-fold faster than if the speed of every
alternative was not carefully weighed when selecting
detailed design alternatives.

>
>> Are there any possible standard C++ ways to do this?
>>
>
> Standard C++ requires the code to work also if N is
> outside of [0,7], so it
> cannot strip away the code for that. You could try to
> declare N as unsigned
> char and provide all 256 cases.
>
> FWIW, MSVC++ provides the __assume keyword as an
> extension, letting one to
> tell the optimizer things like that. The example in the
> MSDN documentation
> is exactly about optimizing out the default branch of a
> switch.
>
> Paavo
>

==============================================================================
TOPIC: Cheap air jordan shoes nike shoes wholesale/retail at www.guoshitrade.
com
http://groups.google.com/group/comp.lang.c++/t/23a0f188bd94684c?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Mar 29 2009 6:37 am
From: jersey1234@126.com

Discount Nike air jordans (www.guoshitrade.com)
Discount Nike Air Max 90 Sneakers (www.guoshitrade.com)
Discount Nike Air Max 91 Supplier (www.guoshitrade.com)
Discount Nike Air Max 95 Shoes Supplier (www.guoshitrade.com)
Discount Nike Air Max 97 Trainers (www.guoshitrade.com)
Discount Nike Air Max 2003 Wholesale (www.guoshitrade.com)
Discount Nike Air Max 2004 Shoes Wholesale
(www.guoshitrade.com)
Discount Nike Air Max 2005 Shop (www.guoshitrade.com)
Discount Nike Air Max 2006 Shoes Shop (www.guoshitrade.com)
Discount Nike Air Max 360 Catalogs (www.guoshitrade.com)
Discount Nike Air Max Ltd Shoes Catalogs (www.guoshitrade.com)
Discount Nike Air Max Tn Men's Shoes (www.guoshitrade.com)
Discount Nike Air Max Tn 2 Women's Shoes (www.guoshitrade.com)
Discount Nike Air Max Tn 3 Customize (www.guoshitrade.com)
Discount Nike Air Max Tn 4 Shoes Customize
( www.guoshitrade.com)
Discount Nike Air Max Tn 6 Supply (www.guoshitrade.com)
Discount Nike Shox NZ Shoes Supply (www.guoshitrade.com)
Discount Nike Shox OZ Sale (www.guoshitrade.com)
Discount Nike Shox TL Store (www.guoshitrade.com)
Discount Nike Shox TL 2 Shoes Store (www.guoshitrade.com)
Discount Nike Shox TL 3 Distributor (www.guoshitrade.com)
Discount Nike Shox Bmw Shoes Distributor (www.guoshitrade.com)
Discount Nike Shox Elite Shoes Manufacturer
(www.guoshitrade.com)
Discount Nike Shox Monster Manufacturer (www.guoshitrade.com)
Discount Nike Shox R4 Running Shoes (www.guoshitrade.com)
Discount Nike Shox R5 Mens Shoes (www.guoshitrade.com)
Discount Nike Shox Ride Womens Shoes (www.guoshitrade.com)
Discount Nike Shox Rival Shoes Wholesaler (www.guoshitrade.com)
Discount Nike Shox Energia Wholesaler (www.guoshitrade.com)
Discount Nike Shox LV Sneaker (www.guoshitrade.com)
Discount Nike Shox Turbo Suppliers (www.guoshitrade.com)
Discount Nike Shox Classic Shoes Suppliers
(www.guoshitrade.com)
Discount Nike Shox Dendara Trainer (www.guoshitrade.com)
Discount Nike Air Jordan 1 Seller (www.guoshitrade.com)
Discount Nike Air Jordan 2 Shoes Seller (www.guoshitrade.com)
Discount Nike Air Jordan 3 Collection (www.guoshitrade.com)
Discount Nike Air Jordan 4 Shoes Collection
(www.guoshitrade.com)
Discount Nike Air Jordan 5 Chaussure Shoes
(www.guoshitrade.com)
Discount Nike Air Jordan 6 Catalog (www.guoshitrade.com)
Discount Nike Air Jordan 7 Shoes Catalog (www.guoshitrade.com)
Discount Nike Air Jordan 8 Customized (www.guoshitrade.com)
Discount Nike Air Jordan 9 Shoes Customized
(www.guoshitrade.com)
Discount Nike Air Jordan 10 Wholesalers (www.guoshitrade.com)
Discount Nike Jordan 11 Shoes Wholesalers (www.guoshitrade.com)
Discount Nike Air Jordan 12 Factory (www.guoshitrade.com)
Discount Nike Air Jordan 13 Shoes Factory (www.guoshitrade.com)
Discount Nike Air Jordan 14 Shoes Sell (www.guoshitrade.com)
Discount Nike Air Jordan 16 Exporter (www.guoshitrade.com)
Discount Nike Air Jordan 17 Shoes Exporter
(www.guoshitrade.com)

==============================================================================
TOPIC: Nomenclature for interger size in C/C++
http://groups.google.com/group/comp.lang.c++/t/d94de8ebc4095151?hl=en
==============================================================================

== 1 of 12 ==
Date: Sun, Mar 29 2009 6:41 am
From: Giuliano Bertoletti

Balog Pal ha scritto:

>
> If starting a port like this I'd certainly pick the latest version of the
> compiler, not just one on the road. The work effort is about the same, and
> I'd lose 3 years difference for the next such update, and the new features
> too.
>

Compiled with VC2005 SP1. I'm not aware of the existence of any SP2.
I won't think it's a bug anyway. It would be far too obvious, a CString
is a foundamental component in MFC.

>
> Sure, did I say it has no costs of any kind? But just listing the costs of
> conversion does not mean necessarily they are less than the lock-in.

Which doesn't mean necessarily the opposite either: i.e that they are
more than the lock-in.

As I suggested in a previous post, it has to be evaluated case by case.

>> If this were true, I would opt for staying with the old, bad but known
>> stuff rather than diving in the old, equally bad and unknown stuff.
>
> So you admit that your arguments are not really meand, just attempting to
> fight cognitive dissonance? You have the verdict before listening the
> witnesses.
>

I never tried newer features of MFC in VC8/9. I would have been happy if
they just kept compatibility with older system, but they didn't and
porting was required.

I've managed, just out of curiosity, to attempt to convert some basic
projects but the plethora of errors I received was enough to discourage
me to stand the effort. Plus I read somewhere (long ago) that MS was
slowly abandoning MFC framework and promoting .NET.

Frankly I do not think there can be only one verdict for everyone.

I only exposed my concerns regarding the upgrading, concerns that were
obviously related to my own projects. I never stated that everyone
should follow me.

Regards,
Giuliano Bertoletti.

== 2 of 12 ==
Date: Sun, Mar 29 2009 7:26 am
From: "Balog Pal"

"Giuliano Bertoletti" <gbe32241@libero.it>
> Suppose I somewhere serialize a structure to disk like this:
>
> fwrite(&mys, 1, sizeof(mys), h1); // C struct serialization
>
> are you sure the new compiler packs the structure in the same way ?

This is conidered dangerous at original design phase for the very reason. If
a system choses that, it uses safeguards around (i.e. #pragma pack with
ensurance it has compiler support, test cases to verify sizes and read/write
known files with verification...)

Even with the same compiler the packing strategy can be adjusted by command
line switch (per file!) or a #pragma pack accidentally picked up from an
early include.

> This is a potential problem which goes unnoticed at compile time.

Your current project carries that danger if it is so. Porting adds little
new danger.

> You may object, I should have not serilized the struct that way in the
> first place.

Not *blindly*, hoping it will just work.

> Maybe, but if for example I serialize each member I would probably loose
> efficiency (repeated calls to the OS) which may or may not be critical.

Not likely measurable, unless your serialisation is ineffective to start
with, or extreme case dumping megabytes having directly in one structure.
Normally you want to serialize out to a buffered file, and the cost of more
function calls is way less than the actual i/o of the buffer flush.

> Again, it's a choice.

It is, but between what, as told before, bnary bump is not forbidden just
shall be reinforced.

> - Second, troubles often come with automatically generated code which
> makes heavy use of macros that I have ignored all along because it worked
> as expected and never caused problems.
>
> Once I realize the prototypes of the new compiler are different, I may be
> forced to look at what that code really does and find proper workarounds.

If those are MFC macros defined in MFC headers, they work the same
semantics, don't they.

Sure if you have a set of hand-crafted macros, they count like normal code.
But at least can be done at one place.

> - Third you may also consider potential problems in my code that never
> showed up with the old compiler and may be triggered by the new (due for
> example to a different memory layout).

You mean existing code has undefined behavior masked by black magic, and you
hope the actual behavior is 'just fine'? Unless you have a proof in
design of the behavior (what would trivially help porting) it is just unfair
(IMHSHO) to push such thing to production and end user.

> Yes, I know that would be problems of my code and not the compiler.
> But let's face reality: I wrote the code, I and my customers tested it for
> a decade. It works and we're satisfied.

Well, if they are truly satisfiesfied -- and not just suffering silently
form the same lock-in.

In my practice I met many situations where 'customer satisfection' brought
very different results if you asked a manager who paid for the stuff and the
users in everyday work.

Normally testing is activity made not by the customer either...

== 3 of 12 ==
Date: Sun, Mar 29 2009 7:29 am
From: "Balog Pal"

"Vaclav Haisman" <v.haisman@sh.cvut.cz>
> It is not that you cannot use latest C++ constructs. You cannot use C++
> constructs that are valid C++ about 10 years now. What is worse, you
> cannot
> even use C++ constructs as simple assignment of std::string, since its
> implementation is buggy wrt/ threads in VC6.

You don't use stl with VC6, so that is not a practical problem. (especially
not mixed with MFC)

== 4 of 12 ==
Date: Sun, Mar 29 2009 7:57 am
From: "Balog Pal"

"Giuliano Bertoletti" <gbe32241@libero.it>
>> [CString direct vs copy init from "ss"]
>
> Compiled with VC2005 SP1. I'm not aware of the existence of any SP2.
> I won't think it's a bug anyway. It would be far too obvious, a CString is
> a foundamental component in MFC.

Then possibly as the other post mentioned, you may have unicode setting or
something. It is weird in any case, as either both ot neither forms should
compile for a copyable type as CString...

>> Sure, did I say it has no costs of any kind? But just listing the costs
>> of conversion does not mean necessarily they are less than the lock-in.
>
> Which doesn't mean necessarily the opposite either: i.e that they are more
> than the lock-in.
>
> As I suggested in a previous post, it has to be evaluated case by case.

Sure, definitely.

>>> If this were true, I would opt for staying with the old, bad but known
>>> stuff rather than diving in the old, equally bad and unknown stuff.
>>
>> So you admit that your arguments are not really meand, just attempting to
>> fight cognitive dissonance? You have the verdict before listening the
>> witnesses.
>>
>
> I never tried newer features of MFC in VC8/9. I would have been happy if
> they just kept compatibility with older system, but they didn't and
> porting was required.
>
> I've managed, just out of curiosity, to attempt to convert some basic
> projects but the plethora of errors I received was enough to discourage me
> to stand the effort. Plus I read somewhere (long ago) that MS was slowly
> abandoning MFC framework and promoting .NET.

MS changes mind on such stuff. Around '96 they were decided to not support
C++ and go another way. (VC6.0 is the end-product of that era...) Then found
standard C++ is worth support after all, and made 7.0 approximatin, 7.1
pretty close. And on the same track ever since. While working on C++/CLI
top speed on another task.

MFC looks like a similar story, at least hard to understand OOB update any
other way.

> Frankly I do not think there can be only one verdict for everyone.

There isn;t and shouldn't. Just common observations suggest staying with
the past becomes increasingly painful. I am generally in the camp of 'stay
with what works' and don't even consider brand new stuff immediately, but
wait others to find the mines and join after a SP or too. And switch
versions jumping over several. (I.e I still use office'97, switched ftom
NT4 to XP around 2004 etc...)
And definitely would not suggest switching away from VS6 in 2004, when it
had all the same attributes. But by now it is aged too far, and the new
stuff went forward too much. And if your project will be around next year,
and planned live for a few more, and especially adding new featires, I'm
failry convinced you will lose out on staying, even without knowing many
details. (If you consider it by end of life, sure, why bother.)

> I only exposed my concerns regarding the upgrading, concerns that were
> obviously related to my own projects. I never stated that everyone should
> follow me.

Ok.

You know that VS2008 professional is available for DL as a 90 day trial? You
may try to install it as experiment and try conversion. I didn't use 2005
for a second, it may be far behind in addressing your kind of problem.

== 5 of 12 ==
Date: Sun, Mar 29 2009 7:50 am
From: Vaclav Haisman

Vaclav Haisman wrote, On 29.3.2009 16:44:
> <http://support.microsoft.com/kb/813810>.
More of fun reading on similar note: <http://support.microsoft.com/kb/172396>

--
VH

== 6 of 12 ==
Date: Sun, Mar 29 2009 7:44 am
From: Vaclav Haisman

Giuliano Bertoletti wrote, On 29.3.2009 14:16:
> Vaclav Haisman ha scritto:
>
>> It is not that you cannot use latest C++ constructs. You cannot use C++
>> constructs that are valid C++ about 10 years now.
>
> I guess you're right. But what are these constructs ?
for(;;) induction variable scoping is annoying enough. The fact that operator
::new can return NULL is terrible.

> The ones presented in Alexandrescu's book: "Modern's Design Patterns in
> C++" for example ?
>
> Well, I highly respect that book and the author. I found its reading
> very interesting and illuminating. I'm very happy that such a book exists.
>
> Still I've never found a practical use for that code. Mostly because
> it's difficult to fully master templates at such level and once you do,
> you ask yourself: "...and now what?"
>
> That book delivers the knowledge but not the experience which allows to
> use such a constructs. One thing is to use them because they're cool,
> another because you need them.
You do not have to use them yourself. You are limiting yourself from using
libraries that use them in their implementation.

>
>
>> What is worse, you cannot
>> even use C++ constructs as simple assignment of std::string, since its
>> implementation is buggy wrt/ threads in VC6.
>>
>
> I've never shared an std::string among multiple threads and I wasn't
> aware of the problem. Anyway, I'm pretty sure that upon facing such a
> scenario I would have asked myself: "Is STL thread safe ?".
You are apparently not aware of the bug. The scenario is like this: You have
a string A and you create a copy B = A, everything in a single thread. Now,
you would expect those two to be completely separate and that you can use
each in separate threads independently. Well, guess what, VC6 uses reference
counted std::string which does not lock the reference count
increment/decrement operation. Sooner or later (on boxes with multi core CPUs
sooner), VC6 compiled application will fuck up the reference count which
usually results in segfault and crash. See
<http://support.microsoft.com/kb/813810>.

>
> It's difficult to prove, but I think I would have answered myself: "I've
> never seen mentioning thread safety in STL, nor in C++" and then I would
> have played on the safe side and synchronized the access myself.
>
> Maybe my answer isn't satisfying, I understand, but frankly speaking I
> would not consider that scenario a pitfall I were likely to fall in.
>
> On the other hand, one strong point in which I will probably upgrade, is
> when Win64 applications become the norm.

--
VH

== 7 of 12 ==
Date: Sun, Mar 29 2009 9:55 am
From: Giuliano Bertoletti

Balog Pal ha scritto:
> "Vaclav Haisman" <v.haisman@sh.cvut.cz>
>> It is not that you cannot use latest C++ constructs. You cannot use C++
>> constructs that are valid C++ about 10 years now. What is worse, you
>> cannot
>> even use C++ constructs as simple assignment of std::string, since its
>> implementation is buggy wrt/ threads in VC6.
>
> You don't use stl with VC6, so that is not a practical problem. (especially
> not mixed with MFC)
>
>

Why not ? With the latest service pack STL works just fine (at least on
a single thread) with MFC.

I also use multithreading, but did never stumble on the std::string
reference counting issue because the model adopted is the worker thread
doing a long job and the main thread responding to user inputs (usually
reacting on an abort request).

I do not remember having ever passed strings from one thread to another.

Multiple threads are also rare for my GUI applications which need to
react instantly on user input (except for long jobs as above).

A different scenario is for networking oriented services which higly
relay on threads to service multiple clients but they usually don't
share string based data among them. These would probably less
troublesome to port to new compiler.

But there may be applications which do and std::string is indeed a VC6
problem.

Alas, also newer compilers have bugs (especially in the latest and more
complex features) and they are possibly less known due to their lower age.

Compiler bugs are a double edged sword: is it better an old compiler
with known bugs and workarounds or a new compiler with possibly unknown
ones ?

Regards,
Giuliano Bertoletti

== 8 of 12 ==
Date: Sun, Mar 29 2009 10:31 am
From: Giuliano Bertoletti

Balog Pal ha scritto:
>
>> This is a potential problem which goes unnoticed at compile time.
>
> Your current project carries that danger if it is so. Porting adds little
> new danger.
>

Which may make the difference between standing on the edge of a cliff
and falling down. :-(

Anyway I did not write such a sloppy code, but sometime others do and
you have to take decisions with what you have. No use to complain it
shouldn't have been done that way.

>
> It is, but between what, as told before, bnary bump is not forbidden just
> shall be reinforced.
>

Yes, absolutely. Still when you decide to upgrade you have to take also
this in consideration.

>>
>> Once I realize the prototypes of the new compiler are different, I may be
>> forced to look at what that code really does and find proper workarounds.
>
> If those are MFC macros defined in MFC headers, they work the same
> semantics, don't they.
>

If a component like a CString is being replaced with something (a
template ?) with the same name but different interface, I would expect
the compiler tossing out the code with disgust.

>> - Third you may also consider potential problems in my code that never
>> showed up with the old compiler and may be triggered by the new (due for
>> example to a different memory layout).
>
> You mean existing code has undefined behavior masked by black magic, and you
> hope the actual behavior is 'just fine'? Unless you have a proof in
> design of the behavior (what would trivially help porting) it is just unfair
> (IMHSHO) to push such thing to production and end user.
>

Wait a minute. This is not intentional.

The fact is: you write the code, you believe it's correct. You and your
team test it several times and it always works.
Eventually you go into production, what else can you do ?

If the code is correct it works now and it will work on another compiler
too. If it is not it may crash now and also on another compiler, but
chances are that the current compiler won't trigger the defect while the
other does.

Consider for example the (wrong) assumption that global objects are
initialized in a particular order.

>
> Well, if they are truly satisfiesfied -- and not just suffering silently
> form the same lock-in.
>
> In my practice I met many situations where 'customer satisfection' brought
> very different results if you asked a manager who paid for the stuff and the
> users in everyday work.
>

What I mean is that software is buggy. Patches and service packs keep
being release to correct defects. A programmer should try to minimize
the impact of bugs, whatever the means.

As soon as they're spotted they must be corrected and a defensive
programming style is also preferable.

But you should also limit the risks of triggering dormant bugs if possible.

Regards,
Giuliano Bertoletti.

== 9 of 12 ==
Date: Sun, Mar 29 2009 10:42 am
From: "Balog Pal"

"Giuliano Bertoletti" <gbe32241@libero.it>
>> "Vaclav Haisman" <v.haisman@sh.cvut.cz>
>>> It is not that you cannot use latest C++ constructs. You cannot use C++
>>> constructs that are valid C++ about 10 years now. What is worse, you
>>> cannot
>>> even use C++ constructs as simple assignment of std::string, since its
>>> implementation is buggy wrt/ threads in VC6.
>>
>> You don't use stl with VC6, so that is not a practical problem.
>> (especially not mixed with MFC)
>
> Why not ? With the latest service pack STL works just fine (at least on a
> single thread) with MFC.

Because
- std::string is an abomination in its own right
- you have CString around anyway that is superior in ALL respects
- having multiple kinds of strings withoin a project is a royap pain

For the other stuff you also have stock solutions in MFC, that were around
for long, much better documented, and with direct recognition/support in the
frameworks.

The STL version shipping with VC6 was something around CD2 (i.e. with the
completely broken auto_ptr). IIRC Dincum offered an update of the lib for
extra $$$ after the standard was out, but ....

> I also use multithreading, but did never stumble on the std::string
> reference counting issue because the model adopted is the worker thread
> doing a long job and the main thread responding to user inputs (usually
> reacting on an abort request).

Yeah, that looks more like a 'theoretical' problem where attention is put to
sharing objects between threads -- but if you just use CString you get more
without headache, don't you?

> I do not remember having ever passed strings from one thread to another.
>
> Multiple threads are also rare for my GUI applications which need to react
> instantly on user input (except for long jobs as above).

Depends on what you do. Most of my programs had threads for socket or COM
port communication... Or processing stuff on behalf of multiple clients,
using the GUI only mostly as visual feedback.

> Alas, also newer compilers have bugs (especially in the latest and more
> complex features) and they are possibly less known due to their lower age.

IMO the quality at MS improved vastly starting the 2000 security push
(starting fruits a few years later). And compilers are given out as
freebies (the Express versions, faurly long-timed trials), and early betas,
so have a good chance for less hitting bugs.

Certainly Murphy does not sleep. But VS6 was never such a stable, I recall
the IDE reutinely crashed after 24 hours of work, and all kinds on INTERNAL
COMPILER ERRORs were common visitors.

> Compiler bugs are a double edged sword: is it better an old compiler with
> known bugs and workarounds or a new compiler with possibly unknown ones ?

Depends on which hits YOU ;-) actually -- in this race I would not bet my
money on VC6 however old and spreadly used it is/was.

(I recall being hit by at leas one proved code-generation bug too. Had to
specificly disable some optimisations in all builds afterwards...)

== 10 of 12 ==
Date: Sun, Mar 29 2009 10:45 am
From: "Balog Pal"

"Vaclav Haisman" <v.haisman@sh.cvut.cz>

>>> It is not that you cannot use latest C++ constructs. You cannot use C++
>>> constructs that are valid C++ about 10 years now.
>>
>> I guess you're right. But what are these constructs ?
> for(;;) induction variable scoping is annoying enough.

#define for if(0); else for
cures it for good...

== 11 of 12 ==
Date: Sun, Mar 29 2009 10:58 am
From: "Balog Pal"

"Vaclav Haisman" <v.haisman@sh.cvut.cz>
>> <http://support.microsoft.com/kb/813810>.
> More of fun reading on similar note:
> <http://support.microsoft.com/kb/172396>

This has little to do with MS or a specific compiler version -- using
objects across DLL boundaries always had problems, and programmers shall be
aware of them.

The most kown problem is probably tied to memory allocation/deallocation
that is suggested to be done always at the same place.

With DLLs I always rtied to restrict to a pure C-stlye interface and
carefully packed structures. If that is not feasible, it's better to write
a COM object and pay the marshaling.

== 12 of 12 ==
Date: Sun, Mar 29 2009 11:57 am
From: Giuliano Bertoletti

Balog Pal ha scritto:
> "Vaclav Haisman" <v.haisman@sh.cvut.cz>
>
>>>> It is not that you cannot use latest C++ constructs. You cannot use C++
>>>> constructs that are valid C++ about 10 years now.
>>> I guess you're right. But what are these constructs ?
>> for(;;) induction variable scoping is annoying enough.
>
> #define for if(0); else for
> cures it for good...
>

Congratulations! Brilliant disguise.

I knew of:

{for(;;) {
}}

but yours definitly outperforms this.

Regards,
Giuliano Bertoletti

==============================================================================
TOPIC: Laguna Beach Womens Jeans - Discount Laguna Beach Jeans
http://groups.google.com/group/comp.lang.c++/t/2ea40143ce99572a?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Mar 29 2009 8:33 am
From: amamark858@gmail.com

If you are looking for discount Laguna Beach jeans,you can always
Laguna Beach Womens Jeans online for you to find the ones that can
satisfy your taste and your budget...

Our Designer Laguna Beach Womens Jeans are fine quality.
You can check them:
http://www.luxury-fashion.org/static/Apparels/Laguna-Beach-Womens-Jeans-07.html

And find more new fashion apparels please view :
www luxury-fashion org

Welcome check our other pages or feel free contact us.
You can find what do you want here!

==============================================================================
TOPIC: disadvantages of using STL
http://groups.google.com/group/comp.lang.c++/t/fb1f5fcc56ce965e?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Mar 29 2009 8:33 am
From: coal@mailvault.com

On Mar 29, 12:09 am, "Tony" <t...@my.net> wrote:
> "SG" <s.gesem...@gmail.com> wrote in message
>
> news:d768e33e-f3fe-437a-9381-77592563b90d@z9g2000yqi.googlegroups.com...
> On 27 Mrz., 07:41, "Tony" <t...@my.net> wrote:
>
> > "Noah Roberts" <n...@nowhere.com> wrote in message
> > > Anyone can obfuscate a design in their implementation.
> > Cliches are like assholes.
>
> "Hello Tony,"
>
> No need to be formal (seesh).
>
> "it seems you don't have a lot to contribute to this (or any?)
> discussion."
>
> Give to receive. (Or is that too a cliche?).
>
> " I went through the trouble of reading all your posts in
> this thread and the thread "C++ is complicated" again and the only
> things that have stuck are:"
>
> ("only", as if you are omniscient).
>
> "* STL is supposedly complicated."
>
> I said "obfuscated", didn't I?
>
> " It's more complicated than your container library."
>
> From an implementation standpoint, yes. (You're not talking about design
> outside of the language/syntax domain are you?) Think about it this way: why
> would I have created and evolved something else if I thought STL was "the
> bomb"?
>

You remind me of "Le Chaud Lapin" on comp.lang.c++.moderated. He
goes on and on about his code, but doesn't ever publish it. I asked
him about that a couple years ago and he said he would in a year or
so. I don't know for sure, but I wouldn't be surprised if he hasn't
published anything yet. If you don't have a growing number of users
for your software, I don't think it will mature. I once thought the
STL was "the bomb," but have changed my mind now. In a number of
ways the containers in the Boost Intrusive library are better than
the STL. Anyway, your talk of another approach without giving much
detail or publishing anything doesn't work for me.

> In many instances, even container choice makes little difference.
> Personally, I use a container that fits the problem even if "a simple array"
> could do it more efficiently a lot of times. If I was developing genome
> programs or such, I would probably choose the highest performing beast
> available: STL (template-based gives high perf).

I would use a combination of the Boost Intrusive containers and the
STL.
Boost Intrusive doesn't have anything like vector or deque so I'd use
those where it made sense. In places where there is a choice between
an STL container and a Boost Intrusive container, I'd favor using the
Boost Intrusive container.

>I think that the concept of
> one library that would span the needs of a programmer that needs to develop
> utility programs in adjunct to network/system administration, to the
> scientific programmer, a non-practical idea. Rogue-Wave and Borland both
> went to "enterprise development". Did they "cave in" because of the C++ std
> library? I know how companies evolve. And when the substance walks out the
> door (and gets "let go"), the company stagnates to a period of
> inter-management boom ("enterprise" sounds kinda fitting huh?).
>
> You're a bit behind the current times though apparently: you are saying that
> if one uses C++, then the std C++ library is the way to go. I don't think
> C++ is the way to go and haven't for quite awhile. It has been a great
> learning experience, but times have changed.
>

What do you suggest? Do tell.

Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

== 2 of 2 ==
Date: Sun, Mar 29 2009 10:56 am
From: zr

On Mar 17, 10:31 pm, Pallav singh <singh.pal...@gmail.com> wrote:
> Q What are the disadvantages of using STL ?
>
> Thanks in advance
> Pallav Singh

Since no one mentioned it, what about code bloat? Is this still an
issue in recent implementations?

==============================================================================
TOPIC: templates and friends
http://groups.google.com/group/comp.lang.c++/t/bd903f388d4a1f19?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Mar 29 2009 9:56 am
From: "F. P. Beekhof"

Hello,

could anybody tell what I'm doing wrong?

template <typename T, std::size_t D>
class DTree;

template <class is, typename T, std::size_t D>
is& operator>>(is& i_stream, DTree<T, D> &tree);

template <typename T, std::size_t D>
class DTreeProxy
{
public:
template <class is, typename TT, std::size_t DD>
friend is& operator>> (is& i_stream, DTree<T, D> &tree);

private: typedef int Blah;
};

template <class is, typename T, std::size_t D>
is& operator>>(is& i_stream, DTree<T, D> &tree)
{
typedef typename DTreeProxy<T, D>::Blah Blah; // Error
}

The error is then that Blah is private in the operator>>() context.

I'm lost. How should it be done ?

Many thanks in advance,

Fokko Beekhof

== 2 of 2 ==
Date: Sun, Mar 29 2009 10:57 am
From: litb

On 29 Mrz., 18:56, "F. P. Beekhof" <fpbeek...@gmail.com> wrote:
> Hello,
>
> could anybody tell what I'm doing wrong?
>
> template <typename T, std::size_t D>
> class DTree;
>
> template <class is, typename T, std::size_t D>
> is& operator>>(is& i_stream, DTree<T, D> &tree);
>
> template <typename T, std::size_t D>
> class DTreeProxy
> {
> public:
> template <class is, typename TT, std::size_t DD>
> friend is& operator>> (is& i_stream, DTree<T, D> &tree);
>
> private: typedef int Blah;
>
> };
>
> template <class is, typename T, std::size_t D>
> is& operator>>(is& i_stream, DTree<T, D> &tree)
> {
> typedef typename DTreeProxy<T, D>::Blah Blah; // Error
>
> }
>
> The error is then that Blah is private in the operator>>() context.
>
> I'm lost. How should it be done ?
>

The bug lies here: You have to use DD and TT - not D and T in the
parameter list of the function.

template <class is, typename TT, std::size_t DD>
friend is& operator>> (is& i_stream, DTree<TT, DD> &tree);

As far as i know, it's not possible to declare a friend given a
partial set of template arguments. Either you have to declare
particular instances as friends, or all possible instances of a
template. The above declares all ones as friends. The below declares
one particular instance as friend.

friend istream& operator>> <>(istream& i_stream, DTree<T, D> &tree);

Now, whether the specialization was instantiated or explicitly
specialized - it will be a friend.

==============================================================================
TOPIC: Design question: polymorphism after object creation
http://groups.google.com/group/comp.lang.c++/t/b748f0f3d941a3ba?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Mar 29 2009 10:06 am
From: Boris Rasin

On Mar 29, 2:34 am, Marcel Müller <news.5.ma...@spamgourmet.com>
wrote:
> A union with a few types and a stable common base class would be nice.
> If the base is virtual, the memory layout could match the requirements
> in theory - but only in theory.
> Like this:
> +------------------------+
> | Base |
> +-------+--------+-------+
> | File | Folder | Other |
> +-------+ | |
> + free | +-------+
> +-------+--------+-------+
>
> This could turn into 4 different classes (if Base is not abstract)
> without the need to change the Pointer to Base.

Just out of curiosity, here is what I came up with:

------------------ polymorph.h ------------------
#include <cstddef>
#include <type_traits> // or <boost\tr1\type_traits.hpp>
using std::tr1::aligned_storage;
using std::tr1::alignment_of;

template <typename T1, typename T2>
struct max_size
{
static const std::size_t value = sizeof (T1) > sizeof (T2) ? sizeof
(T1) : sizeof (T2);
};

template <class base, class derived1, class derived2>
class polymorph
{
//static_assert (std::has_virtual_destructor<base>::value);
//static_assert (std::is_base_of<base, derived1>::value);
//static_assert (std::is_base_of<base, derived2>::value);
public:
polymorph() : object_ptr (reinterpret_cast<base*> (&object_space))
{
new ((void*)object_ptr) base;
}

~polymorph()
{
object_ptr->~base();
}

base* operator -> () { return object_ptr; }

template <class T>
void change_type()
{
//base temp (std::move (*object_ptr));
object_ptr->~base();

object_ptr = const_cast<base* volatile> (object_ptr);

new ((void*)object_ptr) T; // (std::move (temp));
}
private:
// Even though object_ptr always points to object_space,
// it is needed to provide memory barrier when object type changes
// (invalidate compiler's cache of object's const members including
vptr).

base* object_ptr;

typename aligned_storage<max_size<derived1, derived2>::value,
alignment_of<base>::value>::type object_space;
//char object_space /*[[align(base)]]*/ [max_size<derived1,
derived2>::value];

};
------------------ polymorph.h ------------------

And the test code:

------------------ polymorph_test.cpp -----------
#include <iostream>
using std::cout;

#include "polymorph.h"

struct base
{
base() { cout << "base()\n"; }
virtual ~base() { cout << "~base()\n"; }
virtual void func() { cout << "base::func()\n"; }
};

struct derived1 : base
{
derived1() { cout << "derived1()\n"; }
~derived1() { cout << "~derived1()\n"; }
virtual void func() { cout << "derived1::func()\n"; }
};

struct derived2 : base
{
derived2() { cout << "derived2()\n"; }
~derived2() { cout << "~derived2()\n"; }
virtual void func() { cout << "derived2::func()\n"; }
};

typedef polymorph<base, derived1, derived2> object_type;

void main()
{
object_type obj;
obj->func();

obj.change_type<derived1>();
obj->func();

obj.change_type<derived2>();
obj->func();
}
------------------ polymorph_test.cpp -----------
Here is the output:

base()
base::func()
~base()
base()
derived1()
derived1::func()
~derived1()
~base()
base()
derived2()
derived2::func()
~derived2()
~base()

When type is changed object is actually destroyed and re-created, so
you need some way to transfer state. But all references remain valid.
This implementation does provide some performance benefits compared to
standard proxy approach, but unless you really need those, I don't
know if I would use something like this in production code.

Boris.

==============================================================================
TOPIC: wholesale nike max 95 sneakers
http://groups.google.com/group/comp.lang.c++/t/b459d2922c17f301?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Mar 29 2009 12:15 pm
From: abc7989@hotmail.com

Dear friend: Welcome to http://www.sellstockshoes.com where you can
find the latest
all kinds brand shoes.We offer Nike Jordan1-23 , Air Max, Air Shox,
Dunk SB,
Adidas, Puma ,Gucci, Prada,
Timberland,D&G,Converse,Locaste,Coach,Chanel,
Bape,Kappa,Richmond,Ed Hardy LV shoes and sneakers. We also have a
wide
selection of top great brand woman fashion shoes for your choice such
as
nike ,adidas,puma daphne ect.. and other brand goods,such as cheap
bags
include women's handbags, coach handbags discount, cheap gucci
handbag...
and wholesale clothes,jeans,hats, and brand ties,clips etc.We hope to
build
mutual benefits and long term business relationships with all
customers.
If you are interested in our products and have any question, welcome
to
contact us. we will be honest to answer your all problem .and welcome
to
test our honesty.

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

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

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

No comments:

Blog Archive

About Me