Teaching new tricks to an old dog (C++ -->Ada)

[Turamnvia Suouriviaskimatta]

I 'm following various posting in "comp.lang.ada, comp.lang.c++ ,
comp.realtime, comp.software-eng" groups regarding selection of a
programming language of C, C++ or Ada for safety critical real-time
applications. The majority of expert/people recommend Ada for safety
critical real-time applications. I've many years of experience in C/C++ (and
Delphi) but no Ada knowledge.

May I ask if it is too difficult to move from C/C++ to Ada?
What is the best way of learning Ada for a C/C++ programmer?

[REH]

"Ioannis Vranos" <iv*@remove.this.grad.com> wrote in message
news:1112185337.193940@athnrd02...

Strictly speaking one shouldn't use such variable names. However this is not easy to check all those things. C++ aims to be an *enabling* language. For example one could have written the following code for a system:
int* f()
{
// For setting panel indication.
int *p =reinterpret_cast <int *>(0x148);

// For reading external thermometer
volatile const int *r= reinterpret_cast<volatile const int *>(329);

// ...

return p;
}

The Ada equivalent would be something like:

-- For setting panel indication.
p : integer;
for p'address use 16#148#;

-- For reading external thermometer
r : integer;
for r'address use 329;
pragma volatile(r);

[Ioannis Vranos]

fabio de francesco wrote:

Yes, with the only problem that the stack has already released space
reserved for that variable called "a".

Yes, however I think it is difficult for the compiler to protect from this at compile
time. Check my other example with pointers pointing to system-specific memory areas (my
example that includes the volatile pointer).
--
Ioannis Vranos

http://www23.brinkster.com/noicys

[R Adsett]

In article <1112194359.789857@athnrd02>, iv*@remove.this.grad.com says...

fabio de francesco wrote:

Yes, with the only problem that the stack has already released space
reserved for that variable called "a".

Yes, however I think it is difficult for the compiler to protect from this at compile
time. Check my other example with pointers pointing to system-specific memory areas (my
example that includes the volatile pointer).

Certainly far from impossible though, This is what I get from lint for
that

|
{
e:\cygwin\home\radsett\newlib-lpc\fram.c 98 Note 957: Function 'fun'
defined
without a prototype in scope

|
p = &a;
e:\cygwin\home\radsett\newlib-lpc\fram.c 100 Info 789: Assigning
address of
auto variable 'a' to static

Robert

"Ioannis Vranos" <iv*@remove.this.grad.com> wrote in message
news:1112011700.94455@athnrd02...

You can't protect a bad programmer from doing bad programming, unless you forbid him to continue programming. :-)

You can provide tools that help the good programmer be a better
programmer. In my experience, Ada does just that.

I am one of those people who appeciates having tools that make
my job easier, whether for software development or for other
activities. I would rather use a socket wrench of the right
dimensions than an adjustable wrench. I prefer to use a bread
knife for my sourdough bread than a paring knife. I find it
easier, and safer, to use sharp axe for splitting logs than a
small hatchet. In each case, I can do the job with the less
effective tool, but the specialization of the tool makes my
life a little better.

There is rarely a programming problem I cannot express in
Ada. Sometimes I need to use one of the libraries instead
of the language itself. An example, in a separate thread,
is the use of decimal fraction exponent in a power expression.
The math library is required. This is a little safer that having
it directly in the language. It also simplifies the compiler a
bit. If I really need to do address arithmetic, I can, but I
rely on one of the child units of package System for this. That
library unit reduces the chances of my making stupid mistakes.

As Pascal Obry noted, Ada does forbid some things in the
core language. It forbids some unsafe things. However,
we can, if we wish, relax the rules of the language to do
unsafe things. There are all kinds of unchecked features,
and because they are unchecked, the programmer knows
the dangers. There are specialized packages that help
the programmer circumvent otherwise unsafe constructs.

It is easier to start with a language where the default for
most constructs is "safe" and relax the safety than it is
to start with a language such as C++ where the default is
generally "unsafe" and make it safer. In fact, with an
unsafe language there is little incentive for most programmers
to even try to find ways to make it more safe. I speak from
experience here. I have seen no end of C++ activity where
the programmers blithely grind out code where the compiler
cannot detect the unsafe parts of the program from those that
might be (we cannot be sure) safe.

Safe programming might be possible in C++. It is not common
in C++ programming practice. Unsafe programming might be
possible in Ada, but it is not common in Ada practice.

Richard Riehle

[red floyd]

ad******@sbcglobal.net wrote:

"Ioannis Vranos" <iv*@remove.this.grad.com> wrote in message
news:1112011700.94455@athnrd02...

You can't protect a bad programmer from doing bad programming, unless you

forbid him to

continue programming. :-)

You can provide tools that help the good programmer be a better
programmer. In my experience, Ada does just that.

We used to joke that a bad programmer could write FORTRAN IV code in any
language, even Ada!

[Martin Dowie]

red floyd wrote:

ad******@sbcglobal.net wrote:

You can provide tools that help the good programmer be a better
programmer. In my experience, Ada does just that.

We used to joke that a bad programmer could write FORTRAN IV code in any
language, even Ada!

I have seen a guy attempt to write COBOL in Ada - and he didn't even
know COBOL!!! :-)

[Peter Koch Larsen]

"Tapio Kelloniemi" <sp****@thack.org> skrev i en meddelelse
news:S9***************@reader1.news.jippii.net...

"Peter Koch Larsen" <pk*****@mailme.dk> wrote:

"Tapio Kelloniemi" <sp****@thack.org> skrev i en meddelelse
news:IQ*****************@reader1.news.jippii.net ...

The question is not only about compiler warnings or errors. Ada (as a
language) has been designed so that it is possible for the
compiler to check many mistakes which may cause bad results at run time.
Ada also makes it easier for the user to notice this kind of errors.
For example:

procedure X is

type Metres is new Natural;
type Seconds is new Natural;

M : Metrses := 0;
S : Seconds := 10;
begin
if M < S then -- Error, < is not defined for these types
But now you have problems calculating the velocity, right?

type Velocity is new Natural;
V: Velocity = M/S; // probably a compiler error.

Yes, but I can tell the compiler that I know better:
V : Velocity := Velocity (Integer (M) / Integer (S));

You can't be serious here. You just did what corresponds to a C-style cast
here. Would anyone accept that in production-code? The other proposal (to
create a function) simply requires a vast amount of stupid code if all
"normal" generic dimensions.
Also other readers of my code now know surely that this is what I meant.
So they say, the ones who abuses C-style casts.

This is a bit more verbose than using pure int instead of Metres and
Seconds, but if I wanted a C++ compiler to check this kind of error, I'm
afread that the resulting C++ code would be much more verbose.
Not so. There is an excellent library which does exactly what you want -
using templates, of course.

That is a good thing. If all C++ programmers used it, I think their
programs would benefit a lot of it.

Such mistakes as using a pointer to nothing and writing past the array
bounds don't often happen in Ada.

What makes you believe they happen regularly in C++?

They just happen. Why people had otherwise created such tools as valgrind
(http://valgrind.kde.org/). I also use it myself for Ada to eliminate
memory
leaks. Writing past array bounds unintentionally is quite easy. In Ada
Constraint_Error is raised, but C++ program segfaults. Or even worse, it
does not segfault immediately, but when the function is exited (as the
return address has been destroyed). STL is safer, but it cannot always be
used (eg. when interfacing to foreign code).

An example. First compile with the default behaviour, then with all
warnings tu
rned on: [--] If a replace I < J; with null; the result is:
gcc -c -gnatg temp.adb
temp.adb:2:04: warning: "I" is not modified, could be declared constant
temp.adb:2:04: warning: variable "I" is not referenced
temp.adb:3:04: warning: "J" is not modified, could be declared constant
temp.adb:3:04: warning: variable "J" is not referenced
gnatmake: "temp.adb" compilation error

I see no real difference here between a good-quality C++ compiler and Ada.

Another example:

int* f()
{
int i = 3;
int& l = *(new int);

l = i;
int* p = &i; // Should be int* p = &l;

return p;
}

int main()
{
int* p = f();
*p = 4;
return 0;
}

# g++ -Wall -o temp temp.cc
#

Not even a warning and the program does not crash on my system! Valgrind
revealed the error (and thought it was a G++ bug).
If the code above is modified a bit, even the best compiler cannot
know for sure that we are doing evil things.

Noone denies that writing code such as this is possible in C++. Apparantly
you can also do it in Ada. In neither language will you see such stuff in
production-code. This at least is my sincere hope ;-)

The same in Ada:

procedure Temp is
type Int_Ptr is access Integer;

function F return Int_Ptr is
I : Integer := 3;
L : Int_Ptr := new Integer;
P : Int_Ptr;
begin
L.all := I;
P := I'Access; -- Should be P := L;
return P;
end F;

A : Int_Ptr;
begin
A := F;
A.all := 4;
end Temp;

# gcc -c -gnatg temp.adb
temp.adb:5:04: (style): subprogram body has no previous spec
temp.adb:11:12: prefix of "Access" attribute must be aliased

So if I really want to pass a pointer to a local to the caller, I should
change
I : Integer := 3;
to
I : aliased Integer := 3;

Also note that the lines which were "mistyped" are much closer to each
other in C++ than in Ada.

--
Tapio

/Peter

[Martin Krischik]

R Adsett wrote:

In article <1112194359.789857@athnrd02>, iv*@remove.this.grad.com says...

fabio de francesco wrote:

> Yes, with the only problem that the stack has already released space
> reserved for that variable called "a".

Yes, however I think it is difficult for the compiler to protect from
this at compile time. Check my other example with pointers pointing to
system-specific memory areas (my example that includes the volatile
pointer).

Certainly far from impossible though, This is what I get from lint for
that

|
{
e:\cygwin\home\radsett\newlib-lpc\fram.c 98 Note 957: Function 'fun'
defined
without a prototype in scope

|
p = &a;
e:\cygwin\home\radsett\newlib-lpc\fram.c 100 Info 789: Assigning
address of
auto variable 'a' to static

Yes if only it where build into the compiler. And yes I do use lint - but
lint build into the compiler would be more helpfull.

BTW: this example is not far fetched because I actually hat problem. And not
as a beginner - this can problem invisibly happen in combination with an
implicit type convertsion.

The type conversion creates a - hidden - temporary whose address is then
passed into on.

Which brings be to a little C++ language lawyer question. Who was right IBM
or MS:

(For my defence in making that silly mistake: the code was scattered over
several files.)

//
// consider that key() returns a reference with sufficient livespan.
//
class Data
{
unsigned&
key ();
}

//
// For a template a free key () function was needed which returns a
// reference to the key data.
//
int&
key (Data const& Element)
{
return Element.key();
}

IBM C++ converts unsigned& -> int&
MS C++ converts unsigned& -> unsigned -> int -> int&

So which compiler was right, which wrong?

(Please don't tell my how to fix it: Once found I knew what to do.)

Martin

--
mailto://kr******@users.sourceforge.net
Ada programming at: http://ada.krischik.com

[Martin Krischik]

Peter Koch Larsen wrote:

"Tapio Kelloniemi" <sp****@thack.org> skrev i en meddelelse
news:S9***************@reader1.news.jippii.net...

"Peter Koch Larsen" <pk*****@mailme.dk> wrote:

"Tapio Kelloniemi" <sp****@thack.org> skrev i en meddelelse
news:IQ*****************@reader1.news.jippii.ne t...

But now you have problems calculating the velocity, right?

type Velocity is new Natural;
V: Velocity = M/S; // probably a compiler error.

Yes, but I can tell the compiler that I know better:
V : Velocity := Velocity (Integer (M) / Integer (S));

You can't be serious here. You just did what corresponds to a C-style cast
here.
Not, actually it is checked convertion:

http://en.wikibooks.org/wiki/Program...ked_Conversion
Would anyone accept that in production-code?
I think so. After all it is not an unchecked convertion:

http://en.wikibooks.org/wiki/Program...ked_Conversion
The other proposal (to
create a function) simply requires a vast amount of stupid code if all
"normal" generic dimensions.

Yes that is indeed a sore point - and no solution in sight.

Martin
--
mailto://kr******@users.sourceforge.net
Ada programming at: http://ada.krischik.com

[Martin Dowie]

Martin Krischik wrote:

The other proposal (to
create a function) simply requires a vast amount of stupid code if
all "normal" generic dimensions.

Yes that is indeed a sore point - and no solution in sight.

There is one solution from Christoph Grein, see

http://home.t-online.de/home/Christ-...in/Ada/SI.html

But a solution 'built-in' to the language didn't make it into Ada0Y. The
reference implementation for it is available but it doesn't solve 100%
of cases, so was dropped.

I believe Tucker had an idea for another proposal involving pragmas
but time ran out, so I don't think that even made it into an AI.

Cheers

-- Martin

[Ioannis Vranos]

Martin Krischik wrote:

Yes if only it where build into the compiler. And yes I do use lint - but
lint build into the compiler would be more helpfull.

BTW: this example is not far fetched because I actually hat problem. And not
as a beginner - this can problem invisibly happen in combination with an
implicit type convertsion.

The type conversion creates a - hidden - temporary whose address is then
passed into on.

Which brings be to a little C++ language lawyer question. Who was right IBM
or MS:

(For my defence in making that silly mistake: the code was scattered over
several files.)

//
// consider that key() returns a reference with sufficient livespan.
//
class Data
{
unsigned&
key ();
}

You shouldn't return a non-const reference to the data of a Class.

//
// For a template a free key () function was needed which returns a
// reference to the key data.
//
int&
key (Data const& Element)
{
return Element.key();
}

IBM C++ converts unsigned& -> int&

This doesn't make any sense. You mean it did something like:
unsigned u;

int &r= u;

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Martin Krischik]

Ioannis Vranos wrote:

Martin Krischik wrote:

Yes if only it where build into the compiler. And yes I do use lint - but
lint build into the compiler would be more helpfull.

BTW: this example is not far fetched because I actually hat problem. And
not as a beginner - this can problem invisibly happen in combination with
an implicit type convertsion.

The type conversion creates a - hidden - temporary whose address is then
passed into on.

Which brings be to a little C++ language lawyer question. Who was right
IBM or MS:

(For my defence in making that silly mistake: the code was scattered over
several files.)

//
// consider that key() returns a reference with sufficient livespan.
//
class Data
{
unsigned&
key ();
}

You shouldn't return a non-const reference to the data of a Class.
Don't tell me - I allready know. Tell the IBM Team which developed the Open
Class Library. While I like the OCL more then the STL the implementation
for key access for the IKeySortedSet had potential for improvement.
//
// For a template a free key () function was needed which returns a
// reference to the key data.
//
int&
key (Data const& Element)
{
return Element.key();
}

IBM C++ converts unsigned& -> int&

This doesn't make any sense. You mean it did something like:
Did you read the posting? I never said it made sense - I said it was a
programming mistake I made a few yeast ago which is still nagging me.

M:\AAA\BBB\CCC\XXX.hpp:
unsigned u;
N:\DDD\EEE\FFF\YYY.cpp:
int &r= u;

Am I the only C++ programmer in the world who understands that those little
programming mistakes never ever happen in two lines of code - one needly
above the other.

No they happen because one line is in one file and the other in another
file. Both files of course in different directories. And on OS/2 / Windows
both Directories on different drives. And - last not least - both written
by different programmers.

But that is all off topic - as I wanted a clarification from a language
lawyer if a temporary should be used in an implicit convertion of unsigned&
to int&.

Martin
--
mailto://kr******@users.sourceforge.net
Ada programming at: http://ada.krischik.com

[Ioannis Vranos]

Martin Krischik wrote:

This doesn't make any sense. You mean it did something like:

Did you read the posting? I never said it made sense - I said it was a
programming mistake I made a few yeast ago which is still nagging me.

I was talking about whether the compiler did something like (notice the "it did" part):

unsigned u;

int &r= u;

The compiler did something like that? Well if yes, I suppose the compiler uses the same
implementation of signed and unsigned references, so it did it directly.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Falk Tannhäuser]

Martin Krischik wrote:

But that is all off topic - as I wanted a clarification from a language
lawyer if a temporary should be used in an implicit convertion of unsigned&
to int&.

IANALL, but binding an lvalue of type unsigned to a reference to int
(or more generally an lvalue of one type to a reference to a different
type when there is no inheritance relationship between these types)
is not allowed and will be rejected by any conforming compiler.
What is possible is:
- Binding an lvalue to a reference of another (incompatible) type
using a cast:
unsigned u = 42;
int& ri = reinterpret_cast<int&>(u);
In this case, no temporary is involved, 'ri' is just an alias for 'u'
but with a different type.
or
- Binding a value (not necessarily an lvalue) to a const-qualified
reference:
unsigned u = 42;
int const& ri1 = u;
int const& ri2 = 666;
Here, temporaries are created that will live as long as does the
reference they are bound to.

Falk

[Martin Krischik]

Falk Tannhäuser wrote:

Martin Krischik wrote:

But that is all off topic - as I wanted a clarification from a language
lawyer if a temporary should be used in an implicit convertion of
unsigned& to int&.

IANALL, but binding an lvalue of type unsigned to a reference to int
(or more generally an lvalue of one type to a reference to a different
type when there is no inheritance relationship between these types)
is not allowed and will be rejected by any conforming compiler.

Thank you, that is indeed good news since there is hope that silly bugs like
that won't happen in future.

Martin
--
mailto://kr******@users.sourceforge.net
Ada programming at: http://ada.krischik.com

[Martin Krischik]

Ioannis Vranos wrote:

Martin Krischik wrote:

This doesn't make any sense. You mean it did something like:

Did you read the posting? I never said it made sense - I said it was a
programming mistake I made a few yeast ago which is still nagging me.
I was talking about whether the compiler did something like (notice the
"it did" part):

Ahh, sorry. Well - they did - both IBM C++ V 3.08 and MS-C V. 7.00.

unsigned u;
>>
int &r= u;

The compiler did something like that? Well if yes, I suppose the compiler
uses the same implementation of signed and unsigned references, so it did
it directly.

Only they both did it differently - one (IBM) directly and the other (MS)
using a temporary.

Now do guess my supprise. The code did work for 3 or 4 years and then was
ported to MS-C++ and kaboom.

And since it was legacy code it took ages to debug. Normally you look at the
most recent changes. But having made no changes at all - only porting from
one compiler to the next - there where no starting point all all - just a
program which crashes deep inside the container library.

Martin
--
mailto://kr******@users.sourceforge.net
Ada programming at: http://ada.krischik.com

[Ioannis Vranos]

Martin Krischik wrote:

Only they both did it differently - one (IBM) directly and the other (MS)
using a temporary.

Now do guess my supprise. The code did work for 3 or 4 years and then was
ported to MS-C++ and kaboom.

And since it was legacy code it took ages to debug. Normally you look at the
most recent changes. But having made no changes at all - only porting from
one compiler to the next - there where no starting point all all - just a
program which crashes deep inside the container library.

Well, you can't depend on having an unsigned int pointed by a signed reference. However I
wonder how it did compile. For example the code:
class SomeClass
{
unsigned x;

public:

unsigned &getx() { return x; }
};
int &crazyfunc(SomeClass &obj)
{
return obj.getx();
}

int main()
{
SomeClass obj;

int &r= crazyfunc(obj);
}
produces the following errors, when used directly without any compiler switch:
GCC 3.4.2:

temp.cpp: In function `int& crazyfunc(SomeClass&)':
temp.cpp:13: error: invalid initialization of reference of type 'int&' from expr
ession of type 'unsigned int'
VC++ 2003:

temp.cpp
temp.cpp(13) : error C2440: 'return' : cannot convert from 'unsigned int' to 'in
t &'
A reference that is not to 'const' cannot be bound to a non-lvalue
Intel C++ 8.1:

temp.cpp
temp.cpp(13): error: a reference of type "int &" (not const-qualified) cannot be
initialized with a value of type "unsigned int"
return obj.getx();
^

compilation aborted for temp.cpp (code 2)

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Martin Krischik]

Ioannis Vranos wrote:

Martin Krischik wrote:

Only they both did it differently - one (IBM) directly and the other (MS)
using a temporary.

Now do guess my supprise. The code did work for 3 or 4 years and then was
ported to MS-C++ and kaboom.

And since it was legacy code it took ages to debug. Normally you look at
the most recent changes. But having made no changes at all - only porting
from one compiler to the next - there where no starting point all all -
just a program which crashes deep inside the container library.

Well, you can't depend on having an unsigned int pointed by a signed
reference. However I wonder how it did compile. For example the code:

Falk Tannhäuser allready pointed out that is is illegal and am glad for
that.
VC++ 2003:

temp.cpp
temp.cpp(13) : error C2440: 'return' : cannot convert from 'unsigned int'
to 'in t &'
A reference that is not to 'const' cannot be bound to a
non-lvalue

Again Good news (dam that we ported 7.0 and not 7.1). Also there where more
indirections in the actual code then in this simplified example. After all
it was all done for a container class template.

Martin

--
mailto://kr******@users.sourceforge.net
Ada programming at: http://ada.krischik.com

[Ioannis Vranos]

Some interesting news regarding .NET support by another language (from WinInfo Daily
Update newsletter):

Python Expands To IronPython

You might have heard of Python, a popular and powerful cross-
platform open-source programming language. Python, which is the
creation of Jim Hugunin, is described as "an interpreted, interactive,
object-oriented programming language ... often compared to Java, Perl,
Scheme, or Tcl." The basic description says a lot (for more information
about Python, see the URL below). Even behemoths such as Google rely
heavily on Python to develop their solutions. Microsoft has also
recently gotten into the act.
http://list.windowsitpro.com/t?ctl=6431:275FF
Last year, Hugunin decide to expand on Python by creating IronPython
(see the first URL below), a new implementation that works within the
Microsoft .NET Framework and the cross-platform Mono environment, which
Novell sponsors (see the second URL below). Version 0.6 was released to
the public in July, when Hugunin also announced that he was joining
Microsoft to continue working on IronPython's evolution. Last week
(some 8 months after Hugunin joined the company), Microsoft released
IronPython pre-alpha version 0.7 to the public. Incidentally, Microsoft
stresses on its download page that IronPython is a codename, so
undoubtedly the company plans to come up with another name for the
final release.
http://list.windowsitpro.com/t?ctl=6430:275FF
http://list.windowsitpro.com/t?ctl=642F:275FF
IronPython is faster than the original Python and lets programmers
handle diverse sets of styles, interfaces, and subsystems. You can also
use the language to communicate with hardware and to develop the same
functionality as programs written in other languages--but with far
fewer lines of code. With IronPython, you can also produce static
runtime executables (.exe files) and DLLs.
The main thrust of IronPython seems to be that it supports
Microsoft's Common Language Runtime (CLR) environment (see the first
URL below), which allows seamless integration of code written in
numerous languages, such as C++, C#, Java, and Visual Basic (VB). If
you want a flexible cross-platform language, be sure to check out
Python, and if you're developing for .NET Framework, you should
certainly check out IronPython 0.7 (see the second URL below).
IronPython also has a message board, documentation, and a bug-tracking
facility (see the third URL below) and a mailing list you can join (see
the fourth URL below), although Hugunin implied in a message to the
list that it might eventually be closed in favor of the message board.
http://list.windowsitpro.com/t?ctl=642A:275FF
http://list.windowsitpro.com/t?ctl=6423:275FF
http://list.windowsitpro.com/t?ctl=6426:275FF
http://list.windowsitpro.com/t?ctl=6427:275FF

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Dave Thompson]

On 24 Mar 2005 17:59:39 -0500, jayessay <no****@foo.com> wrote:

"Jerry Coffin" <jc*****@taeus.com> writes:

Martin Dowie wrote: <snip>

That 'problem' isn't unique to Ada - I can't think of another
language that *does* define a pre-processor.

PL/I. And (no surprise) it includes nearly everything.

COBOL supports pre-compile token sequence(!) replacement, like a very
weak type-1 language, as well as file-ish inclusion, which is so
common it's arguable whether it's really preprocessing. I've heard in
the 2002 revision they added some more but I haven't looked yet.

Fortran officially has an option for conditional compilation and file
inclusion, 1539-3. At least before the "2003" revision -- I don't see
a new one. But -3 doesn't seem to be widely implemented or used;
Fortran programmers who need preprocessing at all seem mostly to make
do with cpp, or m4 or such, or write custom.

(Also there are bindings/embeddings for SQL that are typically
implemented by preprocessors, but I'm not sure they're standard, and
anyway that's not a preprocessor _for the language_.)
A preprocessor per so, no. The type of capabilities is a different
story. For example, Lisp includes macros. Most assemblers include (much
more extensive) macros as well as an eqiuvalent of C's
#if/#ifdef/#ifndef/#endif.

Lisp macros are _not_ a preprocessor and they are _vastly_ more
capable than what people typically think of when they see/hear
"macros". Lisp macros are full code analyzing and generating
constructs. Things like C/C++ preprocessor/"macro" simplistic text
substitutions are not in any way related to them. <snip>

They're not just text (really lexeme) substitution, and are much more
powerful, yes. But they transform the code as written before
compilation, and to me that is the definition of _a_ preprocessor.

It depends on who is 'hearing' 'macro': C/C++ macros are quite weak,
but some of the classic macro assemblers like S/360 and PDP-10 are
pretty powerful, and I would say TECO and TEX and maybe some of the
other text formatters like SCRIBE come close to Lisp in functionality
though not remotely in clarity and usability.

- David.Thompson1 at worldnet.att.net

[Dave Thompson]

On Mon, 28 Mar 2005 18:12:48 +0300, Ioannis Vranos
<iv*@remove.this.grad.com> wrote:

Dave Thompson wrote:

Where available, alloca does allocate on the stack. AFAICS this can
do, at a lower/less-safe level, everything Ada can do at function
scope. It can't do allocation _and deallocation_ for a block within a
function, nor cross-function like function-return-unconstrained. It
almost has to be special-cased/inlined so it should be efficient.

In C++ you can always do:

<snip> void somefunc()
{
unsigned char obj[sizeof(SomeClass)]; <snip placement new and (later corrected) delete> }
In addition to the alignment problem, which can be more or less hacked
around, that's not 'indefinite' (runtime) size, which is what alloca
is good for, and was exactly the snipped question I was answering.

<snip> SomeClass *somefunc()
{
static unsigned char obj[sizeof(SomeClass)];

return new(obj)SomeClass;
}
int main()
{
SomeClass *p= somefunc();

delete p;
}
Here the object is created in the stack.

No it's not, it's static. And if it was it wouldn't survive the return
from somefunc, exactly the same issue I said occurs with alloca().

And it still wouldn't be variable size; C++ has no _declared_ (stack
or static) variable size items. It does have _pointers_ and
_references_ to differing and/or varying type (within hierarchy) or
size items; that's not the same thing. As long as we're at it, C99
(and GNU89) has Variable Length Arrays, only within a scope thus
including a subblock but not returned, and Flexible Array Members
which only access but don't allocate variable size.

To stack-allocate and/or return a fixed-size aggregate, you don't need
any such shenanigans, just use a C struct or a C++ copyable class.

- David.Thompson1 at worldnet.att.net

[Adrien Plisson]

Ioannis Vranos wrote:

Some interesting news regarding .NET support by another language (from
WinInfo Daily Update newsletter):
where do they get their info from ???
You might have heard of Python, a popular and powerful cross-
platform open-source programming language. Python, which is the
creation of Jim Hugunin, [...]

Python is the creation of Guido van Rossum at Stichting Mathematisch
Centrum (CWI <http://www.cwi.nl/>) in the Netherlands !

--
rien

[Ioannis Vranos]

Adrien Plisson wrote:

Python is the creation of Guido van Rossum at Stichting Mathematisch
Centrum (CWI <http://www.cwi.nl/>) in the Netherlands !

Yes, they corrected this in another newsletter mailing.

--
Ioannis Vranos

http://www23.brinkster.com/noicys