On Mon,  3 Sep 2001 21:37:10 GMT, Phlip <phlip_cpp@my-deja.com> wrote:

>>
>> - Introducing an optional garbage collection mechanism to simplify
>>   memory management.
>
>You can get one and add it to your build. They have them on the 'net -
>platform-specific, of course.
>
>But the problem with MM is that C++ either does it right (you don't pay for
>what you don't use), or C++ does not do it. There is no right way to do MM.
>ActiveX and Perl both use an MM that can leak objects held by cyclic
>references. Java can fill memory up with "zombie" objects awaiting
>destruction.
>
Eiffel?
functional languages?
--
**********************************************************************************
The Politician's Slogan
'You can fool all of the people some of the time and some of the
people all of the time, but you can't fool all of the people all of the time.
Fortunately only a simple majority is required.'
**********************************************************************************
Mad Hamish
Hamish Laws
h_laws@bigpond.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

This (not having to include header files) should be quite doable. An example
implementation can be found in the VisualAge C++ 4.0 compiler (IBM), which they
don't seem to support no more unfortunately.

Philip Koester wrote:

> > - Introducing an option to work without #include files. (i.e. you do
> >   not have to include the files, type information is communicated via
> >   metadata). This would allow you to embed C++ code into HTML pages.
>
> I *strongly* agree and suggest to go all the way and make the preprocessor
> obsolete altogether. Speaking for myself, having to maintain consistency
> between declarations and implementations has always been THE major nuisance
> in C (for me). And all these #ifndef #if ___ statements have never looked
> exactly appealing (to me). Of course, some prefer keeping declarations
> separate from implementations, and they have a point, so whoever wants can
> continue to use header files, ideally (optional of course) without the
> preprocessor. And the lazy (like me) have only one file and can explicitly
> disallow use of headers for particular compilation units. Not meaning to
> disparage the merited preprocessor, only I think it is past its time now and
> doesnt go well with scopes and identifiers. And I find it plain boring
> having to compare things as "virtual", "const", "= 0" and many more in .h
> and .cc files.
>
> There are inlines and templates, so macro functions are no longer needed.
> Compile-time constants (and possibly compiler options) can replace macro
> variables. The #if might be replaced by a compiler directive. Compiler
> directives of this kind are an attractive extension for C++ anyway (aspects,
> pre/postconditions, traces, debugging, logging etc.)
>
> Nothing of this is new. Many think so. I see a great chance here to make
> things simpler and cleaner and make C++ appear a bit less messy. And messy
> it is, more than it is wonderful (for me).
>
> Philip
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Philip Koester" <pk@polytox.com> wrote in message
news:9qv79e$vn9$05$1@news.t-online.com...

> There are inlines and templates, so macro functions are no longer needed.

Macros allow you to pass code to the macro whereas you can't get the same
effect with inlines:


#define Error(myerror, dosomething) {printf("\nError: %s", myerror);
dosomething}

e.g.

if(arg1 == NULL)
    Error("Invalid arg", return 0;)

if(IsSystemCorrupt())
    Error("System Corrupt", exit(1);)


Macros are a simple automation facility for building software.

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3BD6BC3E.AB7C0948@isg.de>, Lolke Dijkstra
<lolke.dijkstra@isg.de> writes
>This (not having to include header files) should be quite doable. An example
>implementation can be found in the VisualAge C++ 4.0 compiler (IBM), which they
>don't seem to support no more unfortunately.

The trouble is that the result is not, and I believe cannot be, a
conforming implementation of C++.

Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

> - Introducing an option to work without #include files. (i.e. you do
>   not have to include the files, type information is communicated via
>   metadata). This would allow you to embed C++ code into HTML pages.

I *strongly* agree and suggest to go all the way and make the preprocessor
obsolete altogether. Speaking for myself, having to maintain consistency
between declarations and implementations has always been THE major nuisance
in C (for me). And all these #ifndef #if ___ statements have never looked
exactly appealing (to me). Of course, some prefer keeping declarations
separate from implementations, and they have a point, so whoever wants can
continue to use header files, ideally (optional of course) without the
preprocessor. And the lazy (like me) have only one file and can explicitly
disallow use of headers for particular compilation units. Not meaning to
disparage the merited preprocessor, only I think it is past its time now and
doesnt go well with scopes and identifiers. And I find it plain boring
having to compare things as "virtual", "const", "= 0" and many more in .h
and .cc files.

There are inlines and templates, so macro functions are no longer needed.
Compile-time constants (and possibly compiler options) can replace macro
variables. The #if might be replaced by a compiler directive. Compiler
directives of this kind are an attractive extension for C++ anyway (aspects,
pre/postconditions, traces, debugging, logging etc.)

Nothing of this is new. Many think so. I see a great chance here to make
things simpler and cleaner and make C++ appear a bit less messy. And messy
it is, more than it is wonderful (for me).

Philip



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Mon, 3 Sep 2001 16:54:58, deepa@eventhelix.com (Deepa Ahluwalia)
wrote: WEEKDAY

>I was wondering if there are any attempts being made to enhance C++ so that
>it can better compete with Java and C# in the future.
>
>In my opinion, there are two things that could help the language:
>
>- Introducing an optional garbage collection mechanism to simplify
>  memory management.
>
I see problems with garbage collection on the java news groups.
I am not sure it just did not push the problem into other unexpected
corners.
They clearly need some kind of GC debugger to identify where the
problems are
in the program.
[...]
--

Remove -zamboni to reply
All the above is hearsay and the opinion of no one in particular

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

I was wondering if there are any attempts being made to enhance C++ so that
it can better compete with Java and C# in the future.

In my opinion, there are two things that could help the language:

- Introducing an optional garbage collection mechanism to simplify
  memory management.

- Introducing an option to work without #include files. (i.e. you do
  not have to include the files, type information is communicated via
  metadata). This would allow you to embed C++ code into HTML pages.

Deepa
---------------------------------------
http://www.EventHelix.com/
Real-time software tools and techniques

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Deepa Ahluwalia wrote:

> I was wondering if there are any attempts being made to enhance C++ so
> that it can better compete with Java and C# in the future.

C++ has no motivation - or corporation - to compete with other languages.
Programmers should pick the right one for a job, and trying to make C++
right for more jobs should not drag it away from its center.

> In my opinion, there are two things that could help the language:
>
> - Introducing an optional garbage collection mechanism to simplify
>   memory management.

You can get one and add it to your build. They have them on the 'net -
platform-specific, of course.

But the problem with MM is that C++ either does it right (you don't pay for
what you don't use), or C++ does not do it. There is no right way to do MM.
ActiveX and Perl both use an MM that can leak objects held by cyclic
references. Java can fill memory up with "zombie" objects awaiting
destruction.

Because there is no right way to do MM, C++ should only give us the tools
we need to do it ourself, so we can do what's right for our app.

The C languages have demonstrated how easily clean code can
manually free resources without any tool support. Use the stack, Luke!

> - Introducing an option to work without #include files. (i.e. you do
>   not have to include the files, type information is communicated via
>   metadata). This would allow you to embed C++ code into HTML pages.

Many years ago I read IBM had a new compiler that compiled into a database.
Every subsequent delta in the source code would simply ripple the minimum
elements possible in the database.

I never heard of it again. Maybe it's still out there, but it's another
attempt to solve a problem caused by the bad solution to another problem.
If you want short compile times or source code inside an HTML page, use a
language that already does these.

C++ must respect its legacy code, and we have no reason to directly put
that code into an HTML page if we can just call out to it thru the various
scripting languages.

--
Phlip

http://www.greencheese.org/SonseOne

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

[Posted only to comp.std.c++, as I don't follow comp.lang.c++]

Phlip wrote:
[...]
> > - Introducing an option to work without #include files. (i.e. you do
> >   not have to include the files, type information is communicated via
> >   metadata). This would allow you to embed C++ code into HTML pages.

But you are not obliged to interpret an include directive as meaning the
actual textual inclusion of a file content. An implementation is free to
use any technique to achieve the result of making entities declared or
defined in that "header" known to your embedded code.

[...]
> C++ must respect its legacy code, and we have no reason to directly put
> that code into an HTML page if we can just call out to it thru the various
> scripting languages.

Note that it is possible to create a standard compliant implementation
that obtains a translation unit by first extracting the code from an
HTML page. Preprocessors are certainly not ruled out by the standard!

Cheers,
Nicola Musatti

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <6a9a3562.0109021937.529fd9ef@posting.google.com>, Deepa Ahluwalia
wrote:
> I was wondering if there are any attempts being made to enhance C++ so that
> it can better compete with Java and C# in the future.

IMO the best thing C++ can do to compete with Java is to remain unchanged so
that we have a stable language with which to work. Java's reputation as a
"write once debug everywhere" language came about because it changed too much,
too fast.

> - Introducing an optional garbage collection mechanism to simplify
>   memory management.

There are several garbage collection systems for C++ that can be used when
appropriate. It is a strength of C++ that it provides programmers to manage
memory and other resources in a way that is appropriate for the application.

> - Introducing an option to work without #include files. (i.e. you do
>   not have to include the files, type information is communicated via
>   metadata). This would allow you to embed C++ code into HTML pages.

To use C++ as a web scripting language as you suggest here you would have to
have a C++-enabled browser. That is: you'd have to have a browser with a C++
compilation and runtime system built into it so that the embedded C++ code
could be compiled, linked to a suitable runtime system, and run. For security
reasons such a compilation system would probably have to generate soe sort of
intermediate code and run it in a sandbox - but it could be done.

If you had a browser with a built-in C++ system of this sort it could read
include files in exactly the same way that any other C++ compiler does (you
might have to have some metatdata to help the compiler resolve the filename in
a #include statement to a suitable URL on an appropriate server, but the link
could be resolved by the browser's compiler in much the same way that it
references an embedded graphic, say, in an HTML page.

In short, I can't think of any reason to want to include C++ in a web page, but
if you *did* want to, you would have to change the browser technology *not* the
C++ language to do it.

There are things that Java is good for - and they are generally not the same
things that C++ is good for. The same goes for C#.

Cheers,
 Daniel.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

> - Introducing an option to work without #include files. (i.e. you do
>   not have to include the files, type information is communicated via
>   metadata). This would allow you to embed C++ code into HTML pages.

This idea above is kinda interesting.  I have never heard of anything like
this being attempted, but it definately sounds cool.  If you ever plan to
work on your own to develop this, I would be interested in seeing what I
can do to help.


--
Eric Harrison / eharrison@blister-tech.com
-----------------------------
Blister Technologies, Inc.
http://www.blister-tech.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]