http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* Does anyone else wish the C++ standards committee would give us parity with
other programming languages? - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/65479c8a9a474e0b?hl=en
* Is this a good reference-counting smart pointer class? - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c++/t/41558400ad1ce160?hl=en
* How to declare variable of fixed size across all platforms? - 2 messages, 2
authors
http://groups.google.com/group/comp.lang.c++/t/07c6fc7cf3f56707?hl=en
* I love kathy - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/ac04706c1b343310?hl=en
* Nomenclature for interger size in C/C++ - 9 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/d94de8ebc4095151?hl=en
* Standard C++ way to generate a Jump Table ??? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/7686e7082cfac191?hl=en
* call a C++ function from C? - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/934c5e8f367583af?hl=en
* Some Basic QUESTIONS. - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/6ab03dcb3025b3ca?hl=en
* Cheapness discount wholesale Brand bags (PRADA Purse Gucci bags BURBERRY
Purse LV bags etc.) at china www.guoshitrade.com - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/5ed33758d9e9db10?hl=en
==============================================================================
TOPIC: Does anyone else wish the C++ standards committee would give us parity
with other programming languages?
http://groups.google.com/group/comp.lang.c++/t/65479c8a9a474e0b?hl=en
==============================================================================
== 1 of 4 ==
Date: Sat, Mar 28 2009 10:20 pm
From: Anonymous Infidel
> > > >Or better yet, force them(C#, Java, etc) to do the catch up game....
> > > Might be useful if you would clarify what in your mind is making the
> > > C++ language trail behind these other languages.
> > Simple...That would be all the things they can do that C++ can't.
>
> Which are? And what about all the things you can do in C++ that
> you can't do in Java.
Read what I said about Google.
>
> > Note: You can use Google to see the differences between C++
> > and other programming languages.
>
> Who needs to?
Clearly you do...Seeing as how you asked the question above.
>
> Most of us
So you speak for everyone now? [When was that vote held?]
>
> have actively programmed in several
> different languages. Including some of the newer ones, like
> Java or C#.
Then why did you ask me what the differences were above?
Have a nice day.
== 2 of 4 ==
Date: Sun, Mar 29 2009 12:19 am
From: Anonymous Infidel
On Mar 27, 3:53 pm, "Thomas J. Gritzan" <phygon_antis...@gmx.de>
wrote:
> Anonymous Infidel... wrote:
> > Or better yet, force them(C#, Java, etc) to do the catch up game....
>
> Why should we force the C# guys or the Java guys to catch up with C++?
>
> Well, it would be nice if those languages had support for RAII, or even
> templates, but why force them? ;-)
LOL, True...I should have been more specific and specified in certain
areas C++ is a lil behind. [IMHO, it's still the best language out
there and with asm can do all the good things other languages can]
== 3 of 4 ==
Date: Sun, Mar 29 2009 2:24 am
From: James Kanze
On Mar 29, 7:20 am, Anonymous Infidel <messiah2...@yahoo.com> wrote:
> > > > >Or better yet, force them(C#, Java, etc) to do the
> > > > >catch up game....
> > > > Might be useful if you would clarify what in your mind
> > > > is making the C++ language trail behind these other
> > > > languages.
> > > Simple...That would be all the things they can do that C++ can't.
> > Which are? And what about all the things you can do in C++
> > that you can't do in Java.
> Read what I said about Google.
In other words, you don't know of any.
As I said, I've yet to find anything important that I could do
in Java that I couldn't do in C++, and I've extensive experience
in both languages. (There is perhaps one exception: reflection.
But other than creating a class, given its name, I've not found
that much use for it. And while it takes more work in C++ to
create an instance of a class, given its name, the results are
more robust.)
> > > Note: You can use Google to see the differences between
> > > C++ and other programming languages.
> > Who needs to?
> Clearly you do...Seeing as how you asked the question above.
Clearly I don't, since you can't site any counter examples (even
if you've used Java).
> > Most of us
> So you speak for everyone now? [When was that vote held?]
I'm speaking about the people who post regularly here. I don't
know of any experienced C++ programmer who isn't competent in
several other languages as well.
> > have actively programmed in several
> > different languages. Including some of the newer ones, like
> > Java or C#.
> Then why did you ask me what the differences were above?
I didn't ask what the differences were; I know what the
differences are (and why we continue to use C++ for most serious
applications, rather than Java or C#). You claimed that there
were things you could do in Java, but not in C++. I asked you
to back up that claim. Obviously, you can't.
--
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
== 4 of 4 ==
Date: Sun, Mar 29 2009 5:07 am
From: Christof Donat
Hi,
> As I said, I've yet to find anything important that I could do
> in Java that I couldn't do in C++, and I've extensive experience
> in both languages.
I'd say, e.g. writing web applications in C++ is a bit more difficult than
just hacking a servlet. Of course it is not impossible, but it is hard
compared to Java. On the other hand hacking a servlet is more complicated
than hacking a PHP script and PHP nowadays is powerfull enough to even crete
bigger web applications.
So this is just an type of application where I wouldn't prefer to use C++ at
the moment.
> You claimed that there
> were things you could do in Java, but not in C++. I asked you
> to back up that claim. Obviously, you can't.
Of course it is enough to know, that C++ is turing complete. I guess his
point was more on things that are a lot easier to do in Java than in C++.
Other things apart from web applications that come to my mind are the more
or less standardized OR-mapper (JDO), an aspect oriented framework for
enterprise applications (spring), a standardized, platform independent UI
library (Swing, I guess Qt could fill that gap), etc.
I don't think, all of this should be in the standard, because in my oppinion
it doesn't belong there. But a set of libraries and frameworks that are
close to the standard, like the boost libraries, could help. Actually being
not close to the standard library is in my oppinion the worst drawback of
Qt.
Christof
==============================================================================
TOPIC: Is this a good reference-counting smart pointer class?
http://groups.google.com/group/comp.lang.c++/t/41558400ad1ce160?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Mar 29 2009 12:46 am
From: Juha Nieminen
douglas wrote:
> So, how do I fix it?
Share the reference counter with all the copies, rather than
replicating it.
==============================================================================
TOPIC: How to declare variable of fixed size across all platforms?
http://groups.google.com/group/comp.lang.c++/t/07c6fc7cf3f56707?hl=en
==============================================================================
== 1 of 2 ==
Date: Sun, Mar 29 2009 1:30 am
From: Obnoxious User
On Sat, 28 Mar 2009 18:02:46 -0700, EricFowler wrote:
> Sorry if this is a FAQ, I could not find it.
>
> I am writing C code that will be reading data of fixed format from
> devices. The format of this data is constant and beyond my control and
> comprises 8, 16, and 32 bit signed and unsigned values.
>
> I wish to write C code that will compile on all (well, many) platforms,
> and will have properly sized variables. The problem is in declaring a
> variable that is always (say) 16 unsigned bits.
>
> A first cut is to use __uint16_t , but I have been having a hard time
> defining that variable. It is supposedly in stdint.h but when I include
> that file, the type is undefined.
>
> I have noticed that when I include stdio.h, the type is found, but I
> don't want that header everywhere.
>
> What is the simple standard way to define a variable of fixed bit size?
>
> Don't worry about endianess; I will deal with that separately.
>
> Thanks
>
http://en.wikipedia.org/wiki/Stdint.h
--
OU
Remember 18th of June 2008, Democracy died that afternoon.
http://frapedia.se/wiki/Information_in_English
== 2 of 2 ==
Date: Sun, Mar 29 2009 2:31 am
From: James Kanze
On Mar 29, 3:02 am, EricFowler <eric.fow...@gmail.com> wrote:
> Sorry if this is a FAQ, I could not find it.
> I am writing C code that will be reading data of fixed format
> from devices. The format of this data is constant and beyond
> my control and comprises 8, 16, and 32 bit signed and unsigned
> values.
In what format? Size isn't the only aspect of representation
which varies.
> I wish to write C code that will compile on all (well, many)
> platforms, and will have properly sized variables. The problem
> is in declaring a variable that is always (say) 16 unsigned
> bits.
If you have the C99 standard header <stdint.h> (and most
compilers do), there are often types uint16_t, etc. available.
(They will be available if the platform has a type with the
corresponding size, without padding, and, in the case of signed
integers, uses 2's complement. Which covers a number of the
more wide spread general purpose computers, even if it doesn't
hold for some mainframes, embedded processors, or very old
systems.)
Having the right size, however, really only helps for unsigned
char; having 2's complement means that signed char can also be
read directly, but it stops there.
> A first cut is to use __uint16_t,
Which is a compiler extension, if it exists.
> but I have been having a hard time defining that variable. It
> is supposedly in stdint.h but when I include that file, the
> type is undefined.
The type in stdint.h is uint16_t.
> I have noticed that when I include stdio.h, the type is found,
> but I don't want that header everywhere.
In your particular implementation. Names beginning with two
underscores are reserved for the implementation, and are usually
used for things like library internals.
> What is the simple standard way to define a variable of fixed
> bit size?
> Don't worry about endianess; I will deal with that separately.
The same solution which deals with endianess deals with
different representations and sizes---once you've dealt with
one, you should have dealt with all.
--
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: I love kathy
http://groups.google.com/group/comp.lang.c++/t/ac04706c1b343310?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Mar 29 2009 1:39 am
From: "Tony"
I was battling gestapo then, I don't just love Kathy, I care about her. She
knows who I am.
==============================================================================
TOPIC: Nomenclature for interger size in C/C++
http://groups.google.com/group/comp.lang.c++/t/d94de8ebc4095151?hl=en
==============================================================================
== 1 of 9 ==
Date: Sun, Mar 29 2009 2:02 am
From: Giuliano Bertoletti
Balog Pal ha scritto:
> "Giuliano Bertoletti" <gbe32241@libero.it>
>
>>>> My MSVC++6.0 compiler is older than 1999 and doesn't know anything about
>>> Throw it away and burn it.
>
> I suggest it is well worth the effort. And unless you used weirdo code, make
> it compile should not be a big deal. Certainly testing the results is an
> effort if you don't have autotest coverage.
>
Just started from scratch a dummy project with VC2005.
It appears that he has troubles compiling the following code:
CString msg = "Simple message box.";
AfxMessageBox(msg,MB_ICONINFORMATION);
complaining that:
testmfcdlg.cpp(158) : error C2440: 'initializing' : cannot convert from
'const char [20]' to 'ATL::CStringT<BaseType,StringTraits>'
Googling around I found that a CString in VC2005 is a completely
different beast respect to VC6.
With some trial and error, I found that put in this way it compiles:
CString msg("Simple message box.");
AfxMessageBox(msg,MB_ICONINFORMATION);
Now the point is: shall I really dig into the new CString
code/documentation to see what it is and up to which point is reasonable
to expect the same behaviour as the old CString ?
> I had some fear too, and still have VC6 installed, but didn't feel like
> launch it for some time.
>
>> Even new applications written from scratch benefit using my older routines
>> which have a lot of miles under their wheels and you know they work fine.
No, they don't always do.
The example above suggests that a CString needs adaption. Once adapted,
you'd probably loose compatibility with the older compiler (unless you
work at the intersection of the two, meaning in that case loosing
functionality).
Sacrificing compatibility means you either upgrade at once all the
modules relaying on that code or branch and keep two separate versions.
Both have negative ramifications that need to be evaluated before
stepping forth.
>> Learning how to program a GUI is also a very expensive task in terms of
>> time and I would stick to Windows-MFC if possible, which is a good
>> compromise in availability, functionality, compatibility and resources
>> requirements (that's of course only my personal opinion, I know many of
>> you would argue otherwise).
>> However MFC is badly supported by new compilers that are oriented to .NET
>> framework.
>
> What you mean badly? Maybe badly comparing to their support of other stuff,
> but not worse than VC6.
>
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.
Regards,
Giuliano Bertoletti
== 2 of 9 ==
Date: Sun, Mar 29 2009 2:12 am
From: Vaclav Haisman
Giuliano Bertoletti wrote, On 28.3.2009 21:30:
> Thomas J. Gritzan ha scritto:
>
>>
>> Microsoft noticed that MFC and native C++ is still widely used and
>> released an update to MFC a year ago:
>>
>> "On April 7, 2008, Microsoft released an update to the MFC classes as an
>> out-of-band update to Visual Studio 2008 and MFC 9."
>>
>> "The MFC application wizard has also been upgraded to support the new
>> features"
>>
>
> I'm not saying that MFC isn't updated or supported.
> But, new Visual Studios are heading toward other directions and that's a
> fact.
>
> More than the library itself, the tools that support the development are
> important. These tools are nowhere experiencing the steady development
> and increase in functionality that other tools had.
>
>> Q7: Where is ClassWizard in Visual Studio .NET and in Visual Studio 2005?
>> Answer:
>> http://support.microsoft.com/?scid=kb%3Ben-us%3B313981
>>
>
> It says that ClassWizard is not present and that *some* (but not all) of
> the functionalities are carried out by other tools.
> What if the missing are the ones you use most ?
>
>
>> When you still use VC6 from 10 years ago, you don't profit from the
>> better optimizations today's compiler can do for you.
>>
>
> Of course, what you guys seems not to realize is that this has a price
> which may not be small.
>
> Let's take another point view (I'm making up the story).
>
> Suppose you're the boss of a small firm which delivers software in a
> highly specialized field (say, structural engineering).
> Your application has evolved over a decade and reached a steadly gross
> revenue of $200,000 per year including new customers and maintenance.
>
> The incomes allowed you to hire two programmes which work with you full
> time. One day one of them comes up with the idea of upgrading the
> compiler for increased benefits, although it's not immediately clear
> which they are.
>
> You perform a quick analysis and estimate the time in 3 months to
> migrate the application and another 2 months for testing that everything
> it's fine. It may be safe to account for another month due to Murphy's law.
> Conclusion, you forecast a six months stop in development due to
> code/environment migration and testing, which translates roughly in a
> $100,000 cost.
>
> You quickly realize that one or probably both programmers will loose
> their job if you agree with the upgrade.
>
> Would you still believe it's worth profitting the better optimization
> today compilers can do for you ?
This is total bullshit. You do not have to stop developing new features or
stop maintaining old code. This can be done in parallel with normal
development. What you do is that you create parallel projects for VC9 out of
the VC6 projects. Getting things to compile usually requires only very little
editing. Even huge projects with millions of lines of code usually take only
very little tweaking for the code to become compilable. This might take a
week or two, not months. In the mean time, you keep working on new features
and bug fixes using your old VC6 tools but you also keep checking that the
changes you have made do not break with the new tools. In fact, IME it is
even better to do new development in with the new tools and keep checking
that you do not break things because you have accidentally used some C++
feature that VC6 does not implement (for(;;) induction variable scoping
etc.). You can argue this can slow down your development, that's true, but
you do not need to switch big bang style all your tools at once and it
definitely does not take 6 months to convert. Moving to VC8+ has one huge
advantage from your employees point of view: You help your employees to keep
their sanity. I find it extremely hard to work with the VC6-not-C++ language.
It is as if becoming Tantalus. No developer deserves that.
--
VH
== 3 of 9 ==
Date: Sun, Mar 29 2009 2:23 am
From: Giuliano Bertoletti
Ian Collins ha scritto:
> Giuliano Bertoletti wrote:
>>
>> It's a matter of trade-offs. I've nothing against new compilers but
>> the question you may ask yourself is: should I invest time in learning
>> how to use that new compiler and then port my application or should I
>> keep developing features with what I have ?
>
> The time for that question is long past. If you had moved on sooner and
> had decent validation tests, you wouldn't be in this mess.
>
>
I'm not considering this a mess. The code compiles just fine and I've no
reason to believe that the machine code generated is buggy.
I might not be able to use the latest C++ constructs, but that's a price
I can afford (for now).
I disagree to blindly upgrade just because of new functionalities if you
don't need them or - even worse - you don't even know which they are.
On the other hand, if you're practicing, that's perfectly normal to
catch up with the latest available technology.
Regards,
Giuliano Bertoletti
== 4 of 9 ==
Date: Sun, Mar 29 2009 3:00 am
From: "Bo Persson"
Giuliano Bertoletti wrote:
> Balog Pal ha scritto:
>> "Giuliano Bertoletti" <gbe32241@libero.it>
>>
>>>>> My MSVC++6.0 compiler is older than 1999 and doesn't know
>>>>> anything about Throw it away and burn it.
>>
>> I suggest it is well worth the effort. And unless you used weirdo
>> code, make it compile should not be a big deal. Certainly
>> testing the results is an effort if you don't have autotest
>> coverage.
>
> Just started from scratch a dummy project with VC2005.
>
> It appears that he has troubles compiling the following code:
>
> CString msg = "Simple message box.";
> AfxMessageBox(msg,MB_ICONINFORMATION);
>
> complaining that:
> testmfcdlg.cpp(158) : error C2440: 'initializing' : cannot convert
> from 'const char [20]' to 'ATL::CStringT<BaseType,StringTraits>'
>
So you have now found that the default compiler settings are not the
same as the ones you have used for the last 10 years. Is that enough
for you to give up?
Bo Persson
== 5 of 9 ==
Date: Sun, Mar 29 2009 3:09 am
From: "Balog Pal"
"Giuliano Bertoletti" <gbe32241@libero.it>
> Just started from scratch a dummy project with VC2005.
>
> It appears that he has troubles compiling the following code:
>
> CString msg = "Simple message box.";
> AfxMessageBox(msg,MB_ICONINFORMATION);
>
> complaining that:
> testmfcdlg.cpp(158) : error C2440: 'initializing' : cannot convert from
> 'const char [20]' to 'ATL::CStringT<BaseType,StringTraits>'
>
> Googling around I found that a CString in VC2005 is a completely different
> beast respect to VC6.
>
> With some trial and error, I found that put in this way it compiles:
>
> CString msg("Simple message box.");
> AfxMessageBox(msg,MB_ICONINFORMATION);
Copy-init was discouraged wrt direct init for like 15 years... Though this
suboptimal code should still compile.
In VS2008 it does without problem.
Did you apply the latest service pack to your VS2005? The error message
implies it is hit by an archaic defect report, it should be corrected.
> Now the point is: shall I really dig into the new CString
> code/documentation to see what it is and up to which point is reasonable
> to expect the same behaviour as the old CString ?
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.
>> I had some fear too, and still have VC6 installed, but didn't feel like
>> launch it for some time.
>>
>>> Even new applications written from scratch benefit using my older
>>> routines which have a lot of miles under their wheels and you know they
>>> work fine.
>
> No, they don't always do.
>
> The example above suggests that a CString needs adaption.
I'd put that aside until we know it is a bug or a feature of that compiler
stepping.
> Once adapted, you'd probably loose compatibility with the older compiler
> (unless you work at the intersection of the two, meaning in that case
> loosing functionality).
I don't recall such changes from the conversion. Certainly after you start
work differences will slip in. At a time we were using 5.0 and 6.0 side by
side, and I was fighting to keep 5.0 compatibility. Though they used almost
the same version of MFC it became a nuisance.
The new MFC is completely rewritten in form. So the applcation code will
devert. Guess you can still keep 'libraries' to compile both ways, if they
are not changing much.
> Sacrificing compatibility means you either upgrade at once all the modules
> relaying on that code or branch and keep two separate versions.
> Both have negative ramifications that need to be evaluated before stepping
> forth.
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. The
price of which is easy to overlook or deny.
>>> Learning how to program a GUI is also a very expensive task in terms of
>>> time and I would stick to Windows-MFC if possible, which is a good
>>> compromise in availability, functionality, compatibility and resources
>>> requirements (that's of course only my personal opinion, I know many of
>>> you would argue otherwise).
>>> However MFC is badly supported by new compilers that are oriented to
>>> .NET framework.
>>
>> What you mean badly? Maybe badly comparing to their support of other
>> stuff, but not worse than VC6.
>>
>
> 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.
== 6 of 9 ==
Date: Sun, Mar 29 2009 4:02 am
From: Giuliano Bertoletti
Vaclav Haisman ha scritto:
>> You quickly realize that one or probably both programmers will loose
>> their job if you agree with the upgrade.
>>
>> Would you still believe it's worth profitting the better optimization
>> today compilers can do for you ?
> This is total bullshit. You do not have to stop developing new features or
> stop maintaining old code. This can be done in parallel with normal
> development.
We may discuss whether my estimates are a bit too pessimistic, but once
we estabilish that it takes N days to upgrade and test (provided the
forecast is correct), that is the time (not less, possibly more).
It really doesn't matter how you interleave the upgrading with the
development time or even how you divide the work among programmers.
At the end of the year, N days (or more due to task switch overhead)
have been consumed for the upgrade.
> What you do is that you create parallel projects for VC9 out of
> the VC6 projects. Getting things to compile usually requires only very little
> editing. Even huge projects with millions of lines of code usually take only
> very little tweaking for the code to become compilable.
- First, compilable doesn't mean it'll work.
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 a potential problem which goes unnoticed at compile time.
You may object, I should have not serilized the struct that way in the
first place.
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.
Again, it's a choice.
- 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.
- 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).
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.
Then I change the compiler and hope... What for?
- Fourth, you're assuming that I'm mastering both the new and the old
tools and for every problem I face, I choose the best solution at
disposal. But the new compiler is new...
> This might take a
> week or two, not months. In the mean time, you keep working on new features
> and bug fixes using your old VC6 tools but you also keep checking that the
> changes you have made do not break with the new tools. In fact, IME it is
> even better to do new development in with the new tools and keep checking
> that you do not break things because you have accidentally used some C++
> feature that VC6 does not implement (for(;;) induction variable scoping
> etc.).
Until you give up compatibility you're working at the intersection of
functionalities with no real gain.
Once you give up compatibility you end up with bloated code that need to
be removed.
Better to stop and upgrade; this is the minimum effort path.
> You can argue this can slow down your development, that's true, but
> you do not need to switch big bang style all your tools at once and it
> definitely does not take 6 months to convert.
Even if you carry out all the work in just one month - tests included,
it would still cost $16,000 according to the example above.
I'm not saying it's never worth the effort, but I would like to see more
detailed statements about supporting the upgrade rather than simply:
"the compiler works better, has many more features and is compliant with
the standard".
Which features ? Do we need them ?
These are the first questions you face when you step that way.
> Moving to VC8+ has one huge
> advantage from your employees point of view: You help your employees to keep
> their sanity. I find it extremely hard to work with the VC6-not-C++ language.
> It is as if becoming Tantalus. No developer deserves that.
>
I would be much more worried about the lack of new substantial libraries
rather than the language standardization.
Regards,
Giuliano Bertoletti.
== 7 of 9 ==
Date: Sun, Mar 29 2009 4:14 am
From: Vaclav Haisman
Giuliano Bertoletti wrote, On 29.3.2009 11:23:
> Ian Collins ha scritto:
>> Giuliano Bertoletti wrote:
>>>
>>> It's a matter of trade-offs. I've nothing against new compilers but
>>> the question you may ask yourself is: should I invest time in
>>> learning how to use that new compiler and then port my application or
>>> should I keep developing features with what I have ?
>>
>> The time for that question is long past. If you had moved on sooner
>> and had decent validation tests, you wouldn't be in this mess.
>>
>>
>
> I'm not considering this a mess. The code compiles just fine and I've no
> reason to believe that the machine code generated is buggy.
>
> I might not be able to use the latest C++ constructs, but that's a price
> I can afford (for now).
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.
>
> I disagree to blindly upgrade just because of new functionalities if you
> don't need them or - even worse - you don't even know which they are.
>
> On the other hand, if you're practicing, that's perfectly normal to
> catch up with the latest available technology.
--
VH
== 8 of 9 ==
Date: Sun, Mar 29 2009 5:16 am
From: Giuliano Bertoletti
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 ?
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.
> 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 ?".
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.
Regards,
Giuliano Bertoletti.
== 9 of 9 ==
Date: Sun, Mar 29 2009 5:31 am
From: Giuliano Bertoletti
Bo Persson ha scritto:
>
> So you have now found that the default compiler settings are not the
> same as the ones you have used for the last 10 years. Is that enough
> for you to give up?
>
Well, I actually never gave in. :-)
Jokes aside, that was just an example of how you can easily get in
troubles when you venture in a new path. And these were the first two
lines ever written in an MFC VC2005 project.
I swear I was not aware of such a problem until I got the error and in
no way I pushed the compiler toward a known pitfall.
I'm pretty sure there exist plenty of solutions: maybe a service pack,
maybe a compiler switch, etc.
My main objection is not that upgrading is always bad, I'm mainly
against the contrary, i.e.: upgrading is always good.
Regards,
Giuliano Bertoletti
==============================================================================
TOPIC: Standard C++ way to generate a Jump Table ???
http://groups.google.com/group/comp.lang.c++/t/7686e7082cfac191?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Mar 29 2009 2:17 am
From: Paavo Helde
"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
==============================================================================
TOPIC: call a C++ function from C?
http://groups.google.com/group/comp.lang.c++/t/934c5e8f367583af?hl=en
==============================================================================
== 1 of 5 ==
Date: Sun, Mar 29 2009 3:19 am
From: Pallav singh
Hi All,
How do I call a C++ function from C?
Thanks
Pallav
== 2 of 5 ==
Date: Sun, Mar 29 2009 3:27 am
From: Robert Hairgrove
Pallav singh wrote:
> Hi All,
>
> How do I call a C++ function from C?
>
> Thanks
> Pallav
Is the function located in an external library?
The easiest way to do this would be to compile a separate module as C++
which provides wrappers for the C++ functions, exporting them as "extern
C ...". Then you can link your C code to those functions and don't have
to worry about name decoration issues.
== 3 of 5 ==
Date: Sun, Mar 29 2009 4:00 am
From: Pallav singh
On Mar 29, 3:27 pm, Robert Hairgrove <rhairgr...@bigfoot.com> wrote:
> Pallav singh wrote:
> > Hi All,
>
> > How do I call a C++ function from C?
>
> > Thanks
> > Pallav
>
> Is the function located in an external library?
>
> The easiest way to do this would be to compile a separate module as C++
> which provides wrappers for the C++ functions, exporting them as "extern
> C ...". Then you can link your C code to those functions and don't have
> to worry about name decoration issues.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
i am getting following error
file1.cc
extern "C" void func(int );
void func(int i)
{
printf(" C++ function called %d \n", i);
}
file2.c
#include <stdio.h>
void func(int);
void cc(int i)
{ func(i); }
int main()
{
cc(1);
return 0;
}
$ g++ -g file1.cc file2.c
: In function `_Z2cci':
: undefined reference to `func(int)'
collect2: ld returned 1 exit status
== 4 of 5 ==
Date: Sun, Mar 29 2009 5:36 am
From: MiB
On Mar 29, 1:00 pm, Pallav singh <singh.pal...@gmail.com> wrote:
> $ g++ -g file1.cc file2.c
> : In function `_Z2cci':
> : undefined reference to `func(int)'
> collect2: ld returned 1 exit status
The compiler decorates function "cc" to "_Z2cci" which makes me guess
it compiles file2.c as C++ code (expecting decorated naming of "func",
too).
Try:
g++ -g file1.cc
gcc -g file2.c
g++ file1.o file2.o
- maybe this cures the problem.
MiB
== 5 of 5 ==
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
==============================================================================
TOPIC: Some Basic QUESTIONS.
http://groups.google.com/group/comp.lang.c++/t/6ab03dcb3025b3ca?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Mar 29 2009 4:08 am
From: Vaclav Haisman
kunjaan wrote, On 25.3.2009 0:32:
> I was just going through the C++ STL and it says that "the STL was
> created with four ideas in mind: generic programming, abstractness
> without loss of efficiency, the Von Neumann computation model, and
> value semantics."
>
> 1. What are value semantics?
Compare value semantics and pointer/reference semantics. If you have value
semantics, you assume that for some type T and variables A, B of the type T,
if you do A = B and then you modify B, variable A will not be affected in any
way. Opposite to that, with pointer/reference semantics (in language like
Java or Python) assignment A = B makes A point/refer to the same value as B
does, it does not make a copy of it. Any changes then done on/through B will
also be visible through A.
> 2. What kind of losses do you get with abstractions?
Abstraction often means introducing some form of indirection, often pointers.
In C++, abstraction can be achieved using virtual member functions.
Unfortunatelly, using virtual member functions usually means that compilers
cannot do inlining and other optimizations. That is loss of efficiency caused
by abstraction.
OTOH, abstracting things using generic programming and templates means that
compilers can see through all the code and function calls and can do inlining
and many other optimizations that would be inhibited by use of virtual member
functions.
--
VH
==============================================================================
TOPIC: Cheapness discount wholesale Brand bags (PRADA Purse Gucci bags
BURBERRY Purse LV bags etc.) at china www.guoshitrade.com
http://groups.google.com/group/comp.lang.c++/t/5ed33758d9e9db10?hl=en
==============================================================================
== 1 of 1 ==
Date: Sun, Mar 29 2009 5:09 am
From: jersey1234@126.com
I am a Super seller , i also do the business on Ebay with oversea
friends which come from the world.I have many suppliers in china.So I
can supply you
good items,low price, quick of deliver, win friends to trust me!The
hope can become your forever friend.
Our Bag Purse have:
Discount VERSACE True leather AAA Wholesale (www.guoshitrade.com)
Discount VERSACE bags Wholesale (www.guoshitrade.com)
Discount Chanel Purse Wholesale (www.guoshitrade.com)
Discount CHANEL bags Wholesale (www.guoshitrade.com)
Discount CHANEL True leather AAA Wholesale (www.guoshitrade.com)
Discount PRADA Purse Wholesale (www.guoshitrade.com)
Discount PRADA bags Wholesale (www.guoshitrade.com)
Discount PRADA True leather AAA Wholesale (www.guoshitrade.com)
Discount GUCCI Purse Wholesale (www.guoshitrade.com)
Discount GUCCI True leather AAA Wholesale (www.guoshitrade.com)
Discount Gucci bags Wholesale (www.guoshitrade.com)
Discount Gucci Purse True leather AAA Wholesale
(www.guoshitrade.com)
Discount Gucci bag Wholesale (www.guoshitrade.com)
Discount BURBERRY Purse Wholesale (www.guoshitrade.com)
Discount BURBERRY bags Wholesale (www.guoshitrade.com)
Discount pauesmitl bags Wholesale (www.guoshitrade.com)
Discount HERMES True leather AAA Wholesale (www.guoshitrade.com)
Discount HERMES Purse True leather AAA Wholesale
(www.guoshitrade.com)
Discount HERMES bags Wholesale (www.guoshitrade.com)
Discount LV bags Wholesale (www.guoshitrade.com)
Discount LV Purse True leather AAA Wholesale (www.guoshitrade.com)
Discount LV Purse Wholesale (www.guoshitrade.com)
Discount LV True leather AAA Wholesale (www.guoshitrade.com)
Discount D&G bag Wholesale (www.guoshitrade.com)
Discount D&G Purse Wholesale (www.guoshitrade.com)
Discount D&G bags Wholesale (www.guoshitrade.com)
Discount D&G Purse True leather AAA Wholesale
(www.guoshitrade.com)
Discount ED Purse Wholesale (www.guoshitrade.com)
Discount EDHardy bags Wholesale (www.guoshitrade.com)
Discount UGG bag Wholesale (www.guoshitrade.com)
Discount CHLOE True leather AAA Wholesale (www.guoshitrade.com)
Discount CHLOE bags Wholesale (www.guoshitrade.com)
Discount Chloe Purse True leather AAA Wholesale
(www.guoshitrade.com)
Discount JIMMY CHOO Purse True leather AAA Wholesale
(www.guoshitrade.com)
Discount JIMMYTOO bags Wholesale (www.guoshitrade.com)
Discount JIMMY THOO True leather AAA Wholesale
(www.guoshitrade.com)
Discount paul smith bags Wholesale (www.guoshitrade.com)
More detail land, address:www.guoshitrade.com
==============================================================================
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
No comments:
Post a Comment