VC7.1 availability??
max
- Does anyone know when VC7.1 (the microsoft's standard-compliant compiler)
is going to ba available?
- Is there a beta-testing program?
- Also, will it be available as an upgrade to VC.NET of do you have to buy
the whole thing all over (a rather costly proposal)??
- Also, has the VC.NET or VC7.1 optimizer been improved over VC6?
thanx,
--
========================================
Max Khesin, software developer -
m...@NcOvSiPAsionMtech.com
[check out our image compression software at www.cvisiontech.com, PDF
compression @
www.cvisiontech.com/cvistapdf.html]
Neil Butterworth
news:Fw979.1739$1r.5...@twister.nyc.rr.com...
> A bunch of q-s:
> - Does anyone know when VC7.1 (the microsoft's standard-compliant
compiler)
> is going to ba available?
> - Is there a beta-testing program?
> - Also, will it be available as an upgrade to VC.NET of do you have to buy
> the whole thing all over (a rather costly proposal)??
> - Also, has the VC.NET or VC7.1 optimizer been improved over VC6?
Ask these questions in the VC++ support newsgroups on the
msnews.microsoft.com news server.
NeilB
Vincent Finn
microsoft.public.vc.stl
would be the group to post to
I remember some of these question being asked there already
Vin
Dmitry Shulga
VC7.(hell, do not know what it here) is VC++.NET
Ioannis Vranos
> - Does anyone know when VC7.1 (the microsoft's standard-compliant
compiler)
> is going to ba available?
If you mean the upcoming release of Visual Studio codenamed Everett,
MS intends to have it on sale at the end of this year.
The current VC++ (7) .NET is much standard compliant. It is
(enormously to my opinion) more standard compliant than VC++ 6.
> - Is there a beta-testing program?
I do not know.
> - Also, will it be available as an upgrade to VC.NET of do you have
to buy
> the whole thing all over (a rather costly proposal)??
I do not know. I *assume* that an upgrade version will be available
since even for VS (7) .NET languages there are upgrade versions.
> - Also, has the VC.NET or VC7.1 optimizer been improved over VC6?
Well i have not much programming experience with VC++ 6, but VC++ .NET
(7) seems to produce tight and efficient code.
--
Ioannis
* Ioannis Vranos
* Programming pages: http://www.noicys.cjb.net
* Alternative URL: http://run.to/noicys
Richard Cavell
The answer to this question is definitely yes. MS claims that the average
program will speed up by 5%. If you're writing a computer game/physics
simulator/other time-intensive app, this can be a godsend.
As to the standards compliance, it's only important if you're into STL and
other esoteric areas. Good code should compile on VC without modification.
If people will answer gnu-specific questions here, I'll answer VC.Net
questions here.
Jon Bills
"Richard Cavell" <richar...@mail.com> wrote in message
news:ajl90u$2u85$1...@otis.netspace.net.au...
> "max" <m...@cvisiontech.com> wrote in message
> news:Fw979.1739$1r.5...@twister.nyc.rr.com...
> > - Also, has the VC.NET or VC7.1 optimizer been improved over VC6?
>
> The answer to this question is definitely yes. MS claims that the average
> program will speed up by 5%. If you're writing a computer game/physics
> simulator/other time-intensive app, this can be a godsend.
>
> As to the standards compliance, it's only important if you're into STL and
> other esoteric areas.
What is esoteric about a well established and well documented library, a
large part of which made it into the C++ Standard Library?
> Good code should compile on VC without modification.
If it won't compile on VC without modification is it then bad code? Does
Loki represent bad code? Is the use of template-template parameters bad
coding?
> If people will answer gnu-specific questions here, I'll answer VC.Net
> questions here.
Two wrongs don't make a right.
Pete Becker
>
> If it won't compile on VC without modification is it then bad code? Does
> Loki represent bad code? Is the use of template-template parameters bad
> coding?
>
If your goal is to write portable code, then the answer to all three
questions is yes.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Ioannis Vranos
news:ajl90u$2u85$1...@otis.netspace.net.au...
>
VC.Net
> questions here.
Ehehehe (i thought i should say that).
Ioannis Vranos
news:ajlc0s$hce$1...@knossos.btinternet.com...
>
> "Richard Cavell" <richar...@mail.com> wrote in message
> news:ajl90u$2u85$1...@otis.netspace.net.au...
> > "max" <m...@cvisiontech.com> wrote in message
> > news:Fw979.1739$1r.5...@twister.nyc.rr.com...
> >
STL and
> > other esoteric areas.
>
> What is esoteric about a well established and well documented
library, a
> large part of which made it into the C++ Standard Library?
Ok, he meant that compared to VC+++ 6, VC++ 7 compliance has vastly
improved.
>
> > Good code should compile on VC without modification.
>
> If it won't compile on VC without modification is it then bad code?
Does
> Loki represent bad code? Is the use of template-template parameters
bad
> coding?
I agree with your wording here. He should have used the term "usual
code".
> > If people will answer gnu-specific questions here, I'll answer
VC.Net
> > questions here.
>
> Two wrongs don't make a right.
I agree here too. Both are off topic. But he is right too, GNU
questions are usually answered without mentioning that the subject is
off topic.
Ioannis Vranos
news:3D5E4095...@acm.org...
> Jon Bills wrote:
> >
> > If it won't compile on VC without modification is it then bad
code? Does
> > Loki represent bad code? Is the use of template-template
parameters bad
> > coding?
> >
>
> If your goal is to write portable code, then the answer to all three
> questions is yes.
No. If his primary compiler is not VC++ 7, he can use whatever ANSI
structure compiles to his current compiler. We must code with open
mind. ANSI C++ code that happens to not compile in a particular
version of a compiler, is almost certain tthat it will compile in an
upcoming version of that compiler. The standard is recent, and as time
passes things will be improving concerning ANSI C++ compliance.
Pete Becker
>
> ANSI C++ code that happens to not compile in a particular
> version of a compiler, is almost certain tthat it will compile in an
> upcoming version of that compiler.
And when that upcoming version of that compiler becomes avaiable, if it
compiles that code then that code is more portable than it was. If it
doesn't compile today on significant compilers then it isn't portable,
no matter what the future might bring.
Jon Bills
> >
> > If it won't compile on VC without modification is it then bad code? Does
> > Loki represent bad code? Is the use of template-template parameters bad
> > coding?
> >
>
> If your goal is to write portable code, then the answer to all three
> questions is yes.
What I responded too was "Good code should compile on VC without
modification". I don't believe that the inability of VC to compile some
code, without having to first make VC-specific compromises, necessarily
makes that code "bad" (whatever bad really means here). To take this
further, the only way to be certain that code will port to a particular
compiler is to port it and modify accordingly. That does not make the
hypothetical unported code "bad".
> --
> Pete Becker
> Dinkumware, Ltd. (http://www.dinkumware.com)
Cheers,
Jon.
Pete Becker
>
> What I responded too was "Good code should compile on VC without
> modification". I don't believe that the inability of VC to compile some
> code, without having to first make VC-specific compromises, necessarily
> makes that code "bad" (whatever bad really means here).
Unless, of course, "bad" means "doesn't compile on significant
compilers," i.e. code that isn't portable.
Okan AKALIN
> As to the standards compliance, it's only important if you're into STL and
> other esoteric areas. Good code should compile on VC without modification.
>
> If people will answer gnu-specific questions here, I'll answer VC.Net
> questions here.
I think the standarts compliance is one of the most important
issues for a widely used compiler, but when microsoft's attempts
to divide the community [and conquer with new standarts and
languages etc. using the power of its big share in the market]
are taken into account, releasing noncompliant versions, even
after 4th year of the release of ISO standart, seems very
logical... Java is the most portable oop language, that is one
of factors that makes it so popular. Although c++ is even more
popular, I believe that c++ usage will decrease in next years if
a solution is not provided [I have read in one of Stroustrup's
articles that a virtual machine is among the proposals for the
upcoming standart 0x]. The situation is not that bad, but it
is also a possibility. Also the extension of the standart
library is going to provide us with the tools that were left out
in the old standart, but first of all the community should be one
and whole, not be grouped as the GNU users and VS .Net users and
whatever else...
Okan AKALIN
Ioannis Vranos
news:b55056e2.02081...@posting.google.com...
>
> I think the standarts compliance is one of the most important
> issues for a widely used compiler, but when microsoft's attempts
> to divide the community [and conquer with new standarts and
> languages etc. using the power of its big share in the market]
> are taken into account, releasing noncompliant versions, even
> after 4th year of the release of ISO standart, seems very
> logical...
VC++ .NET is very standard compliant, at least at the same level as
the mean level of other popular compilers. An example is the code:
int main() try
{}
catch(...)
{}
which compiles ok in VC++ .NET but does not compile in Borland's
compiler.
> Java is the most portable oop language,
Nope.
> that is one
> of factors that makes it so popular.
I would say we hear about it a lot. This is a hype phenomenon. Sun
pays a lot of money to let Java be heared. According to IDC
Developer's report Java was far behind C++ & VB (i do not recall its
exact position).
Also Java is not standardised.
> Although c++ is even more
> popular, I believe that c++ usage will decrease in next years if
> a solution is not provided
Naturally you are wrong. How will they write the JVM without C++? :)
Also a solution for what?
> [I have read in one of Stroustrup's
> articles that a virtual machine is among the proposals for the
> upcoming standart 0x].
No. The god simply says that he wishes the standard to mention
explicitly that garbage collection is an acceptable technique, in
situations it can be applied (that is in situations without severe
space/time constraints). An example is .NET.
> The situation is not that bad, but it
> is also a possibility. Also the extension of the standart
> library is going to provide us with the tools that were left out
> in the old standart,
The situation is not bad at all. :)
The following standard will probably concentrate on library extensions
not "left-out" in the old standard. Simply new high level facilities.
> but first of all the community should be one
> and whole, not be grouped as the GNU users and VS .Net users and
> whatever else...
I think it is in the human nature to split in various groups. :)
Okan AKALIN
> VC++ .NET is very standard compliant, at least at the same level as
> the mean level of other popular compilers. An example is the code:
>
> int main() try
> {}
>
> catch(...)
> {}
>
>
> which compiles ok in VC++ .NET but does not compile in Borland's
> compiler.
The idea of templates opened new directions in software
development [beside generic programming] but yet MSVC does
not support partial specialization :) This is an important
deficiency.
>
> I would say we hear about it a lot. This is a hype phenomenon. Sun
> pays a lot of money to let Java be heared. According to IDC
> Developer's report Java was far behind C++ & VB (i do not recall its
> exact position).
This one of the advantages of being a money-oriented language :)
and it works, but java's increasing popularity can not be denied.
Nowadays the trend is towards languages that support better error
handling schemes [dynamic semantic checks, exception handling,
language supported assertions etc.] and better static analysis
of the source which improves coders performance [by pointing
the bugs in the first place] and makes it easier to write
software [I don't underestimate the influence of web programming,
of course]. The latest benchmarks show the evolution of Java
in runtime performance [though not good as compiled code, of
course]. I don't think that these are also hype. When combined
with portability, this makes Java a good alternative. But unlike
Java, c++ opens up new possibilities in software development,
provides multiple alternatives for problem solution and the
power of expressiveness makes it my first choice...
> Also Java is not standardised.
>
Although it is not standardised, it has the support of a
big corporation...[As I mentioned before some companies
want to make the privilage of having international standart
just a symbolic honor.]
> > Although c++ is even more
> > popular, I believe that c++ usage will decrease in next years if
> > a solution is not provided.
>
>
> Naturally you are wrong. How will they write the JVM without C++? :)
>
> Also a solution for what?
I see portability as the main problem in C/C++. [I hate
polluting my source files with #ifdefs, #defines etc... I wonder
whether CPP was designed to make the source code look ugly.] C is
famous for its portable [but unreadable!] code.
> > [I have read in one of Stroustrup's
> > articles that a virtual machine is among the proposals for the
> > upcoming standart 0x].
>
>
> No. The god simply says that he wishes the standard to mention
> explicitly that garbage collection is an acceptable technique, in
> situations it can be applied (that is in situations without severe
> space/time constraints). An example is .NET.
>
I must apologize for this big mistake. You are absolutely
right. I thought he talked about a vm in C++ 0x Future
Directions [not as a proposal but as an extension that
vendors may provide].
>
> > The situation is not that bad, but it
> > is also a possibility. Also the extension of the standart
> > library is going to provide us with the tools that were left out
> > in the old standart,
>
>
> The situation is not bad at all. :)
> The following standard will probably concentrate on library extensions
> not "left-out" in the old standard. Simply new high level facilities.
>
Not all of the ideas were left out, only some [the classic
example of hash_map] because of time constrains.
The focus of discussion has changed a little bit :)
Okan AKALIN
P.J. Plauger
news:b55056e2.02081...@posting.google.com...
news:<10296357...@athprx02.forthnet.gr>...
> The idea of templates opened new directions in software
> development [beside generic programming] but yet MSVC does
> not support partial specialization :) This is an important
> deficiency.
Yes. Fixed in V7.1, which is one of the reasons this thread began.
> > Also Java is not standardised.
> >
> Although it is not standardised, it has the support of a
> big corporation...
Uh, why is this a Good Thing (TM) for Java and a Bad Thing (TM)
for VC++?
> I see portability as the main problem in C/C++. [I hate
> polluting my source files with #ifdefs, #defines etc... I wonder
> whether CPP was designed to make the source code look ugly.] C is
> famous for its portable [but unreadable!] code.
Java solves the problem by not having a preprocessor. It relies on
a JVM written in C (with ifdefs) to achieve portability at the cost
of performance.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Ioannis Vranos
news:b55056e2.02081...@posting.google.com...
>
> development [beside generic programming] but yet MSVC does
> not support partial specialization :) This is an important
> deficiency.
It is a deficiency. I do not know how important for usual programs.
But naturally it has to be implemented.
> This one of the advantages of being a money-oriented language :)
> and it works, but java's increasing popularity can not be denied.
C++ use is increasing too (i guess you did not suspect that).
> Nowadays the trend is towards languages that support better error
> handling schemes [dynamic semantic checks, exception handling,
> language supported assertions etc.] and better static analysis
> of the source which improves coders performance [by pointing
> the bugs in the first place] and makes it easier to write
> software [I don't underestimate the influence of web programming,
> of course].
From the above, C++ has the most. About garbage collection. C++
supports the resource "acquistion is initialization technique" which
creates bullet-proof code while at the same time preserving maximum
space/time efficiency and can bee applied on *any* resource.
Consider an example:
class file
{
FILE *fp;
public:
file(const string & name, comst string &mode)
{
// fopen the file and perform success check.
// Throw an exception if something unexpected took place
}
// ... the rest of the interface
~file() { fclose(fp); }
};
If a file object reaches the end of its scope, it cleans itself
automatically. Also if an exception is thrown it clears itself
automatically, so no resource is lost. This can be applied to any
resource, ip connections, *memory* etc. The most standard library
containers support "resource acquistion is initialization" technique.
> The latest benchmarks show the evolution of Java
> in runtime performance [though not good as compiled code, of
> course]. I don't think that these are also hype. When combined
> with portability, this makes Java a good alternative.
Java is advertised as a panacea. Naturally it can't be truth.
> But unlike
> Java, c++ opens up new possibilities in software development,
> provides multiple alternatives for problem solution and the
> power of expressiveness makes it my first choice...
>
>
> > Also Java is not standardised.
> >
> Although it is not standardised, it has the support of a
> big corporation...[As I mentioned before some companies
> want to make the privilage of having international standart
> just a symbolic honor.]
And this is a drawback. In the C++ standardisation committee
representatives from SUN, Microsoft, IBM annd other companies
participate to make it fulfil diverse needs. I think of Java something
like VB with the additional ability to create nice web applets too.
It's nothing more. Naturally it has its place on the world, but do not
think that "Java will remain and C++ will vanish". C++ cannot vanish,
even if it stops being a mainstream language (which i do not think it
will happen anytime soon), it is a standardised language and someone
will be able forever to find a compiler for his architecture (examples
are pascal, ada, ...).
> I see portability as the main problem in C/C++. [I hate
> polluting my source files with #ifdefs, #defines etc... I wonder
> whether CPP was designed to make the source code look ugly.]
I do not place any #ifdefs etc to control compiler dependencies in my
portable code. I place the portable code in one part and the
non-portable on another.
> C is
> famous for its portable [but unreadable!] code.
I disagree. But i have to give you the doubt of personal taste. :)
> I must apologize for this big mistake. You are absolutely
> right. I thought he talked about a vm in C++ 0x Future
> Directions [not as a proposal but as an extension that
> vendors may provide].
You must understand that VM is not needed in C++. You can apply the
"resource acquisition is initalization" technique. But naturally
garbage collection can be applied on systems with space/time
constraints.
> Not all of the ideas were left out, only some [the classic
> example of hash_map] because of time constrains.
Yes probably we will see a hash_map in the standard library in the
future.
> The focus of discussion has changed a little bit :)
Never mind. :) I think it's a nice discussion.
Ioannis Vranos
news:3d5fe4fb$0$9015$724e...@reader2.ash.ops.us.uu.net...
> "Okan AKALIN" <hid...@candledreams.net> wrote in message
> news:b55056e2.02081...@posting.google.com...
> > "Ioannis Vranos" <noi...@spammers.get.lost.hotmail.com> wrote in
message
> news:<10296357...@athprx02.forthnet.gr>...
>
> > The idea of templates opened new directions in software
> > development [beside generic programming] but yet MSVC does
> > not support partial specialization :) This is an important
> > deficiency.
>
> Yes. Fixed in V7.1, which is one of the reasons this thread began.
VC++ 7.1 is on sale? As far as i know only VC++ 7 exists (and it would
be very stranfe if we had another VC++ within 2 months).
Ioannis Vranos
> You must understand that VM is not needed in C++. You can apply the
> "resource acquisition is initalization" technique. But naturally
> garbage collection can be applied on systems
> with space/time
without.
> constraints.
Gafoor
> >
> > If it won't compile on VC without modification is it then bad code? Does
> > Loki represent bad code? Is the use of template-template parameters bad
> > coding?
> >
>
> If your goal is to write portable code, then the answer to all three
> questions is yes.
Which means the STL in the standard was mostly a standard
for bad code, coz many parts couldn't be done on many
compilers :-)
P.J. Plauger
> > If your goal is to write portable code, then the answer to all three
> > questions is yes.
>
>
> Which means the STL in the standard was mostly a standard
> for bad code, coz many parts couldn't be done on many
> compilers :-)
Indeed. STL as proposed to the C++ committee in 1994 worked with existing
compiler technology. The committee saw fit, over the next several years,
to change the specification so that critical parts of STL required features
just being introduced into the C++ language. That's a major reason why we
now have so many not-quite-complete implementations of the Standard C++
language and library.
Still, Pete's point is a good one. If your goal is to write code that's
easy to move across platforms (the de facto definition of portable) then
it behooves you to avoid using stuff that's known to be still in a state
of flux. You can scream that the C++ Standard requires it 'til the cows
come home, but that doesn't make your code any more portable. At least
not today.
Ioannis Vranos
>
> Indeed. STL as proposed to the C++ committee in 1994 worked with
existing
> compiler technology. The committee saw fit, over the next several
years,
> to change the specification so that critical parts of STL required
features
> just being introduced into the C++ language. That's a major reason
why we
> now have so many not-quite-complete implementations of the Standard
C++
> language and library.
>
> Still, Pete's point is a good one. If your goal is to write code
that's
> easy to move across platforms (the de facto definition of portable)
then
> it behooves you to avoid using stuff that's known to be still in a
state
> of flux. You can scream that the C++ Standard requires it 'til the
cows
> come home, but that doesn't make your code any more portable. At
least
> not today.
Exactly, not today. But tomorrow is very near. I rememeber the
yesterday of VC++ 6 era. We must not code with close mind. If ANSI C++
code compiles ok in our current compiler, we should not worry so much
that it doesn't compile to some other compiler. This will not be
happening for much time.
Pete Becker
>
> If ANSI C++
> code compiles ok in our current compiler, we should not worry so much
> that it doesn't compile to some other compiler.
>
Yes, that's one implication of what I said: if you don't care about
portability then just do whatever works with your current compiler. But
don't complain when some other company takes business away from you
because your code doesn't work on the compilers your customers use.
Okan AKALIN
I think I couldn't express my ideas clearly in my previous
messages. I wanted to point some issues that I see as a
problem in C++ but I was treated as a java fanatic :) Some
parts were completely misunderstood, I think it is better
not to comment than to comment based on assumptions.
> C++ use is increasing too (i guess you did not suspect that).
This is also a natural fact [I didn't make any guesses about
its current situation].
> From the above, C++ has the most. About garbage collection. C++
> supports the resource "acquistion is initialization technique" which
> creates bullet-proof code while at the same time preserving maximum
> space/time efficiency and can bee applied on *any* resource.
>
> Consider an example:
>
>
> class file
> {
> FILE *fp;
> public:
> file(const string & name, comst string &mode)
> {
> // fopen the file and perform success check.
> // Throw an exception if something unexpected took place
> }
> // ... the rest of the interface
> ~file() { fclose(fp); }
> };
>
>
> If a file object reaches the end of its scope, it cleans itself
> automatically. Also if an exception is thrown it clears itself
> automatically, so no resource is lost. This can be applied to any
> resource, ip connections, *memory* etc. The most standard library
> containers support "resource acquistion is initialization" technique.
>
This is a resource management technique which proves
to be very useful when an exception is thrown [as the call stack
is unwound, the destructors for local objects are called so
this gives a chance to serialize and do the final clean up
of the resource to the programmer]. But I don't think that the
main reason for including resource handler classes in the
stl is to support [shortly] RAII; providing realistic
abstractions with a clean interface while hiding the internal
details is one of the primary aims of OOP paradigm as everyone
already knows [fitting this into only one sentence is hard].
These classes are more than just wrapper types. Direct
support for RAII in c++ is given through the auto_ptr class.
You can't compare RAII to garbage collection because they
relate to conceptually different subjects [RAII is provided
for exception safety of resources and to help the programmer
while using resources in a pre-known scope and it is centered
around the 'scope' while gc is centered around the references,
scope is not an issue].
In the examples I gave in my previous message, C++ does not
have the most [while saying C++ I refer to the ISO standart]
but many vendors provide these facilities as an optional
extension. Yet the formal description of the language doesn't
limit the programmer [and sometimes gives too much freedom
because of the backwards compatibility with C].
> > The latest benchmarks show the evolution of Java
> > in runtime performance [though not good as compiled code, of
> > course]. I don't think that these are also hype. When combined
> > with portability, this makes Java a good alternative.
>
>
> Java is advertised as a panacea. Naturally it can't be truth.
>
---
> Naturally it has its place on the world, but do not
> think that "Java will remain and C++ will vanish". C++ cannot vanish,
> even if it stops being a mainstream language (which i do not think it
> will happen anytime soon), it is a standardised language and someone
> will be able forever to find a compiler for his architecture (examples
> are pascal, ada, ...).
>
Many people [including the experts of the field] make different
assumptions about the subject. I'm in your opinion [I am not in
contradiction with my previos propositions... The next standart
will provide some solutions]
> > I see portability as the main problem in C/C++. [I hate
> > polluting my source files with #ifdefs, #defines etc... I wonder
> > whether CPP was designed to make the source code look ugly.]
>
>
> I do not place any #ifdefs etc to control compiler dependencies in my
> portable code. I place the portable code in one part and the
> non-portable on another.
>
>
This is also an option if you have much free time [If you mean
writing a new version of the same module for every platform].
Also a fair criticism of CPP can be found in "The Design and
Evolution of C++".
>
> You must understand that VM is not needed in C++. You can apply the
> "resource acquisition is initalization" technique. But naturally
> garbage collection can be applied on systems with space/time
> constraints.
>
This vm is off topic, it would be just an example.
Shortly I believe CPP doesn't provide a good way of writing
portable code. C++ must provide language level support for
#include directive and the low [operating system] level
facilities should be abstracted in standart library so that
we should not have to worry about system specific peculiarities.
Many of these will be added to the upcoming library but it should
include even more...:)
Okan AKALIN
Okan AKALIN
should be replaced as "C++ also provides auto_ptr facility which
also supports RAII, for automatic pointers."
I didn't wait for the message because it takes about 9 hours
through google...
Ioannis Vranos
news:b55056e2.02081...@posting.google.com...
>
> messages. I wanted to point some issues that I see as a
> problem in C++ but I was treated as a java fanatic :)
Well i think you are, just a bit. :) I am a C++ fanatic, just a bit
too.
>
> This is a resource management technique which proves
> to be very useful when an exception is thrown [as the call stack
> is unwound, the destructors for local objects are called so
> this gives a chance to serialize and do the final clean up
> of the resource to the programmer].
And not only for exception safety, also when the objects reach the end
of their scope, they clean themselves automatically which is cool for
resources. You can't have resource leaks.
> But I don't think that the
> main reason for including resource handler classes in the
> stl is to support [shortly] RAII;
I do not know, but the fact is that they support it too.
> providing realistic
> abstractions with a clean interface while hiding the internal
> details is one of the primary aims of OOP paradigm as everyone
> already knows [fitting this into only one sentence is hard].
Yes.
> These classes are more than just wrapper types.
> [C++ also provides auto_ptr facility which
> also supports RAII, for automatic pointers.]
For single objects, not arrays on the free store.
> You can't compare RAII to garbage collection because they
> relate to conceptually different subjects [RAII is provided
> for exception safety of resources and to help the programmer
> while using resources in a pre-known scope and it is centered
> around the 'scope' while gc is centered around the references,
> scope is not an issue].
RAII is not only for exception safety, but for bullet-proof code, that
is without any leakage, not only in exceptions case.
For example, instead of using manual memory allocation & deallocation
on the free store (or rely on a garbage collector), you should use a
standard library container (in general situations vector).
> In the examples I gave in my previous message, C++ does not
> have the most [while saying C++ I refer to the ISO standart]
> but many vendors provide these facilities as an optional
> extension.
> Yet the formal description of the language doesn't
> limit the programmer [and sometimes gives too much freedom
> because of the backwards compatibility with C].
The formal description of the language (the ANSI/ISO standard)
defines what is portable and what is not, and provides the necessary
guidelines and guarrantees for the fundamental functionality of the
language.
> Many people [including the experts of the field] make different
> assumptions about the subject. I'm in your opinion [I am not in
> contradiction with my previos propositions... The next standart
> will provide some solutions]
>
> This is also an option if you have much free time [If you mean
> writing a new version of the same module for every platform].
> Also a fair criticism of CPP can be found in "The Design and
> Evolution of C++".
Well this particular #ifdef subject is too generic. When we say
"portable code", no ifdefs are required. Code using #ifdefs to work
among some compilers is not portable in the general sense. I would use
the term "ported".
> This vm is off topic, it would be just an example.
>
> Shortly I believe CPP doesn't provide a good way of writing
> portable code.
Of course it does. For example the code:
inline int sum(int x, int y)
{
return x+y;
}
is perfectly portable.
I have the sense that with portable you mean, a standard graphics
library and so on (panacea). Naturally this kind of stuff fail to take
advantage of the particular characteristics of a machine and thus is
suboptimal (and i think it is stupid to be forced to live with that).
Also, if you want to have that, for these system-dependent
characteristics there are portable C++ libraries (for GUIs and so on).
> C++ must provide language level support for
> #include directive
I do not understand this.
> and the low [operating system] level
> facilities should be abstracted in standart library so that
> we should not have to worry about system specific peculiarities.
It provides! I do not work low-level in C++. Using manual memory
allocation and deallocation for regular tasks for example must be
avoided. It is bad-style C++.
> Many of these will be added to the upcoming library but it should
> include even more...:)
:)
Okan AKALIN
>
>
> > You can't compare RAII to garbage collection because they
> > relate to conceptually different subjects [RAII is provided
> > for exception safety of resources and to help the programmer
> > while using resources in a pre-known scope and it is centered
> > around the 'scope' while gc is centered around the references,
> > scope is not an issue].
>
>
> RAII is not only for exception safety, but for bullet-proof code, that
> is without any leakage, not only in exceptions case.
> For example, instead of using manual memory allocation & deallocation
> on the free store (or rely on a garbage collector), you should use a
> standard library container (in general situations vector).
>
RAII is less than a technique for writing bullet-proof code. It
is an evident advantage of being a [lexical or static scoped] OOP
language which supports local objects... Using containers etc.
is not something specific to C++. Local objects are never garbage.
Yes C++ supports the automatic release of the objects on the free
store but only for the objects whose lifetimes are already known
[same as its pointer]. This is also a limited functionality. I
am not trying to compare any languages, I just want to say
that RAII should not be confused with gc.
> > This is also an option if you have much free time [If you mean
> > writing a new version of the same module for every platform].
> > Also a fair criticism of CPP can be found in "The Design and
> > Evolution of C++".
>
>
>
> Well this particular #ifdef subject is too generic. When we say
> "portable code", no ifdefs are required. Code using #ifdefs to work
> among some compilers is not portable in the general sense. I would use
> the term "ported".
>
>
>
> > This vm is off topic, it would be just an example.
> >
> > Shortly I believe CPP doesn't provide a good way of writing
> > portable code.
>
>
> Of course it does. For example the code:
>
> inline int sum(int x, int y)
> {
> return x+y;
> }
>
> is perfectly portable.
>
You misunderstood me. When I want to mean C++, I use "C++". CPP
stands for C PreProcessor...
> I have the sense that with portable you mean, a standard graphics
> library and so on (panacea). Naturally this kind of stuff fail to take
> advantage of the particular characteristics of a machine and thus is
> suboptimal (and i think it is stupid to be forced to live with that).
[Are you forced to live with the insufficient auto_ptr?
Absolutely no. You can always use the facilities that Boost provide,
or you may use the Loki library etc... Does auto_ptr add an extra
overhead when you don't use it? Once again no. But it satisfies
the basic needs. If the parts that can take advantage of some
characteristics of some machines are hidden from the interface
[so implementing them if possible is up to the implementator],
there won't be a problem [the library provider will take care
of that]. You speak as if that there is only right way of doing
something for you... You can consider the other options too.]
>
> > C++ must provide language level support for
> > #include directive
>
>
> I do not understand this.
>
The #include directive should not be handled at the preprocessing
phase [so not by the preprocessor but the compiler itself]. This
also means the exclusion of '#'. This is a perfect solution for
the include guards [it will also lower the need for CPP].
> > and the low [operating system] level
> > facilities should be abstracted in standart library so that
> > we should not have to worry about system specific peculiarities.
>
>
>
> It provides! I do not work low-level in C++. Using manual memory
> allocation and deallocation for regular tasks for example must be
> avoided. It is bad-style C++.
>
There is more than file, memory resources, anyway there is
already an ongoing work...
Okan AKALIN
Ioannis Vranos
>
> RAII is less than a technique for writing bullet-proof code. It
> is an evident advantage of being a [lexical or static scoped] OOP
> language which supports local objects... Using containers etc.
> is not something specific to C++. Local objects are never garbage.
Of course they can be. Encapsulated resources like ip connections and
allocated memory. And it is much specific to C++ because as far as i
know Java has not destructors.
> Yes C++ supports the automatic release of the objects on the free
> store but only for the objects whose lifetimes are already known
> [same as its pointer]. This is also a limited functionality. I
> am not trying to compare any languages, I just want to say
> that RAII should not be confused with gc.
RAII can be used so as to have bullet proof code and have no need of
garbage collection. For example (when i do not have specific needs for
another container type) i use vector instead of new[] and delete[].
> [Are you forced to live with the insufficient auto_ptr?
I do not use auto_ptr almost at all.
> Absolutely no. You can always use the facilities that Boost provide,
> or you may use the Loki library etc...
Unfortunately i do not know these libraries yet. In fact i am still
learning C++. :)
> Does auto_ptr add an extra
> overhead when you don't use it? Once again no. But it satisfies
> the basic needs. If the parts that can take advantage of some
> characteristics of some machines are hidden from the interface
> [so implementing them if possible is up to the implementator],
> there won't be a problem [the library provider will take care
> of that]. You speak as if that there is only right way of doing
> something for you... You can consider the other options too.]
No, i am saying the opposite. It seems we agreee here. There is no
panacea. :) I am currently learning .NET too which has garbage
colletion and stuff. But i intend to be using .NET only as an
interface above my portable bullet-proof code. I do not need .NET __gc
arrays for example, i have vector, valarray & stuff.
> The #include directive should not be handled at the preprocessing
> phase [so not by the preprocessor but the compiler itself]. This
> also means the exclusion of '#'. This is a perfect solution for
> the include guards [it will also lower the need for CPP].
Well we could have a standardised #pragma directive. Like #pragma
once. I think #include functionality at the preprocessing phase is
needed, how we will then #include our source code files? Except of
that, keep in mind that a compiler can deal with the #include
directive for standard header files as a switch and not to #include
anything in reality. Simply it must behave as if it does so.
[Ref.: TC++PL3 on page 202 in the beginning of 9.2.2].
> There is more than file, memory resources, anyway there is
> already an ongoing work...
Yes and garbage collection cannot cover everything. While RAII can. We
should not use RAII on *everything*, only on critical resources. When
the object dies (either by exception or reaches the end of its scope),
the destructor is called and the resources are automatically
deallocated. Isn't this bullet-proof code?