Dean Douthat <ddouthat@faac.com> writes:
Rennie Allen wrote:
There’s no accounting for taste >
> Have you tried nedit ? It seems if
one liked vedit (with the standard bindings) then one would probably
like nedit. I’d admit that I use nedit, if converting from Emacs were
not a sin punishable by death…Don’t worry, Rennie, that’s only in MA. >
Hmmm. I’m going to be keeping an eye on both of you…
I really don’t think my statement is any more controversial than it
would have been to say “C is rapidly replacing assembly as the
development language of choice” in 1992 (3 years after ANSI C). Do
people still use assembly today ? absolutely; is it the “development
language of choice” ? absolutely not. Will people still be using C in
2010 ? absolutely, will C be the “development language of choice” at
this time ? absolutely not. I am not suggesting that QSSL drop C, only
that they take C++ very seriously. Personally, I didn’t even so much as
glance at C++ until it was standardized, now I am doing about 80% of my
development in it (from my perspective that is “rapid” - i.e.
practically nothing for 15 years, then “wham” from 0% to 80% in about 1
year). This is not because I suddenly decided that I like C++, but
because it is now clear that a practical standard is in sight, and the
utility level of C++ is about to blow past C so fast it’ll make it look
like an O…
-----Original Message-----
From: Rick Lake [mailto:rwlake@spamfree.domain.invalid]
Posted At: Wednesday, September 05, 2001 11:43 PM
Posted To: os
Conversation: gcc2.95, sizes and optimizations
Subject: Re: gcc2.95, sizes and optimizations
Rennie Allen <RAllen@csical.com> wrote:
Most important to me (at this time) is the full Dinkum lib, and a
highly
ISO compliant compiler (mind you the embedded systems I currently work
on tend to be 1Ghz processors with at least 256MB RAM and 20GB hard
drives >
come…
I really think QSSL has to start taking C++ seriously now, it is a
standard and it is rapidly replacing C as the development language of
choice (even in embedded systems).
careful, you might start a war…
regards,
rick
Since this isn’t the advocacy group, I’ll try to be brief. First off, IMO
the step from assembly to C (or to any other high level, block structured
language for that matter) is much bigger and also of a different sort,
than from C to C++. Secondly your predictions are based on your
perspective, and you didn’t say “IMO” . There are some who don’t share
your views on C++ “becoming the development language of choice”. (For
instance in the ADA camp)
Once someone mentioned a similar statement in comp.std.c and it started a
lengthy discussion about this issue…
regards,
rick
Rennie Allen <RAllen@csical.com> wrote:
I really don’t think my statement is any more controversial than it
would have been to say “C is rapidly replacing assembly as the
development language of choice” in 1992 (3 years after ANSI C). Do
people still use assembly today ? absolutely; is it the “development
language of choice” ? absolutely not. Will people still be using C in
2010 ? absolutely, will C be the “development language of choice” at
this time ? absolutely not. I am not suggesting that QSSL drop C, only
that they take C++ very seriously. Personally, I didn’t even so much as
glance at C++ until it was standardized, now I am doing about 80% of my
development in it (from my perspective that is “rapid” - i.e.
practically nothing for 15 years, then “wham” from 0% to 80% in about 1
year). This is not because I suddenly decided that I like C++, but
because it is now clear that a practical standard is in sight, and the
utility level of C++ is about to blow past C so fast it’ll make it look
like an O…-----Original Message-----
From: Rick Lake [mailto:> rwlake@spamfree.domain.invalid> ]
Posted At: Wednesday, September 05, 2001 11:43 PM
Posted To: os
Conversation: gcc2.95, sizes and optimizations
Subject: Re: gcc2.95, sizes and optimizations
Rennie Allen <> RAllen@csical.com> > wrote:
Most important to me (at this time) is the full Dinkum lib, and a
highly
ISO compliant compiler (mind you the embedded systems I currently work
on tend to be 1Ghz processors with at least 256MB RAM and 20GB hard
drives >
come…
I really think QSSL has to start taking C++ seriously now, it is a
standard and it is rapidly replacing C as the development language of
choice (even in embedded systems).careful, you might start a war…
regards,
rick
“Rennie Allen” <RAllen@csical.com> wrote in message
news:64F00D816A85D51198390050046F80C9B038@exchangecal.hq.csical.com…
I really don’t think my statement is any more controversial than it
would have been to say “C is rapidly replacing assembly as the
development language of choice” in 1992 (3 years after ANSI C). Do
people still use assembly today ? absolutely; is it the “development
language of choice” ? absolutely not. Will people still be using C in
2010 ? absolutely, will C be the “development language of choice” at
this time ? absolutely not. I am not suggesting that QSSL drop C, only
that they take C++ very seriously. Personally, I didn’t even so much as
glance at C++ until it was standardized, now I am doing about 80% of my
development in it (from my perspective that is “rapid” - i.e.
practically nothing for 15 years, then “wham” from 0% to 80% in about 1
year). This is not because I suddenly decided that I like C++, but
because it is now clear that a practical standard is in sight, and the
utility level of C++ is about to blow past C so fast it’ll make it look
like an O…
Well, thanks to a friend, I got on the C++ bandwagon very early on. But I
always had the luxery of developong projects where portability was never a
major issue. So I worked with the compiler that was available, learned its
own idosynchrosies (sp?) adn used it. Over the last decade I have developed
what I consider to be some very elegent (and efficient) C++ library code
that I have brought with me across 4 different employers now.
And Yes! I still do write C code for library routines where efficiency is of
paramount importance.
I save all my old e-mails. I had at least 3 from over the years where
someone at QSSL had admitted that no one there did take C++ seriously.
Admittedly these e-mails are from people and not official QSSL statements so
I won’t name names. But as Rennie said, QSSL needs to start taking C++
seriously.
The final standard has a new feature that I love and want to use, real time
type checking. There are some gnu compilers where this works and some where
it doesn’t. But there is another feature that I have been using for years,
exceptions. Many/most of my library code depends on this. I have noit yet
found a version of compiler where BOTH exceptions AND real-time type
checking work. So I’m not yet using real-time type checking.
BUT I WANNA ! ! !
This gets back to the “Get a Better Compiler” issue.
Bill Caroselli
Hi…
Just for reference, I use C++ for all my development except for those
exceptions where I am forced to use C style programming. Also, every
body I work with at school and work use C++ for the most part.
Bests…
Miguel.
Rennie Allen wrote:
I really don’t think my statement is any more controversial than it
would have been to say “C is rapidly replacing assembly as the
development language of choice” in 1992 (3 years after ANSI C). Do
people still use assembly today ? absolutely; is it the “development
language of choice” ? absolutely not. Will people still be using C in
2010 ? absolutely, will C be the “development language of choice” at
this time ? absolutely not. I am not suggesting that QSSL drop C, only
that they take C++ very seriously. Personally, I didn’t even so much as
glance at C++ until it was standardized, now I am doing about 80% of my
development in it (from my perspective that is “rapid” - i.e.
practically nothing for 15 years, then “wham” from 0% to 80% in about 1
year). This is not because I suddenly decided that I like C++, but
because it is now clear that a practical standard is in sight, and the
utility level of C++ is about to blow past C so fast it’ll make it look
like an O…-----Original Message-----
From: Rick Lake [mailto:> rwlake@spamfree.domain.invalid> ]
Posted At: Wednesday, September 05, 2001 11:43 PM
Posted To: os
Conversation: gcc2.95, sizes and optimizations
Subject: Re: gcc2.95, sizes and optimizationsRennie Allen <> RAllen@csical.com> > wrote:
Most important to me (at this time) is the full Dinkum lib, and a
highly
ISO compliant compiler (mind you the embedded systems I currently work
on tend to be 1Ghz processors with at least 256MB RAM and 20GB hard
drives >
come…
I really think QSSL has to start taking C++ seriously now, it is a
standard and it is rapidly replacing C as the development language of
choice (even in embedded systems).careful, you might start a war…
regards,
rick
Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/
http://www.saic.com
your views on C++ “becoming the development language of choice”. (For
instance in the ADA camp)
Just for perspective, I love Ada95, I would be ecstatic if it was to
become the dominant object oriented programming language rather than
C++. It just isn’t to be. I am not conducting advocacy here, only
reality.
I do want to be spoiled. Watcom was fantastic. Especially the debugger.
OK. Touche’!
Watcom was SOooooo NICE !
But Watcom is dead or ain’t really going anywhere for now. (sic)
openWatcom is strangling with licensed parts that can’t go public and making
the task even harder (sic). =\
I’m really getting sick of g++ and gdb.
BTW, QNX 6.1 is REALLY BAD!!!
Nothing that worked before doesn’t work at all !
It was VERY unprofessional from QSSL to retired 6.0c from distribution,
when such package is working well; more than that,
when 6.1 has major compiler/development “bugs”.
Core OS great. But the Linux obsession is a nightmare. Especially
administration; why can’t it be simple, as in QNX4 ?Boy, I’m glad someone besides me finally put that one into words. I hate
Linux almost as much as i hate Microsoft. And yes, Neutrino has done
some
things VERY, VERY right! But QNX4 is much easier to use.An opinion I share, but I often asked myself: is my opinion bias by all
those years working with QNX4. For someone starting from scratch is QNX4
really that easier?
Correct me folks, if you don’t agree ?!
but this is what I think:
Objectively:
QNX6.0c has a better looking, POSIX compatible, support well templates
QNX4.25 is faster, better, smaller, more reliable, as a great editor, as a
great compiler.
The GUI (screen drivers) were excellent on any computer including old 486
and Pentium,
with a very low quantity of RAM.
Some QNX4 API were easier, some QNX6 API are harder but more complete or
compliant…
Some QNX6 API stuff are also easier than QNX4 due to POSIX standard.
QNX6.0c is slower, create huge executable, is VERY slow in GUI mode for
old Pentium computers,
is slower to compiles, impossible to install directly on embedded
systems, has bad tendency to hang up
at boot time and during transfer to a target (flashing a target).
QNX4.25 had some tendancy to hang up Watcom C++ if used extensively by a
lot of people.
It had thread-safe problem and related problems.
Expectation from QNX6:
==================
ALL THE ADVANTAGE OF QNX4:
PLUS POSIX Standard
PLUS New C++ features, that don’t affect C or C++ code not using it.
PLUS better looking GUI
PLUS more functionalities
I can provide examples and cases for any of these statements, if anybody
wants to read them !?
I mainly code in Embedded Low-tech Structured C/C++
{ No exception, No STL, No namespace, private data of class are stored in
struct (to use memset, memcpy, memcmp),
40% of all functions are inlined and less than 3 lines due to that. }
General Example:
/***************************************************************************
*************************/
typedef struct _myObject_t
{
myLogic_t logic; // Other structs for efficiency and organization
myStatus_t status;
// … other private members …
} myObject_t;
class myObject
{
private:
myObject_t data;
public:
class myObject
{
private:
myObject_t data;
public:
inline myObject()
{
memset( &data, 0, sizeof( myObject_t ) );
}
inline clear()
{
memset( &data, 0, sizeof( myObject_t ) );
}
inline myObject( myObject_t src )
{
memcpy( &data, &src, sizeof( myObject_t ) );
}
inline myObject( const myObject& src )
{
memcpy( &data, &src.data, sizeof( myObject_t ) );
}
inline const myObject& operator=( const myObject& src )
{
memcpy( &data, &src.data, sizeof( myObject_t ) );
return *this;
}
inline const myObject& operator=( myObject_t src )
{
memcpy( &data, &src, sizeof( myObject_t ) );
return *this;
}
inline ~myObject() { }
// … other code…
};
};
/***************************************************************************
*************************/
Sincerely yours,
Fred.
Fred,
BTW, QNX 6.1 is REALLY BAD!!!
Nothing that worked before doesn’t work at all !It was VERY unprofessional from QSSL to retired 6.0c from distribution,
when such package is working well; more than that,
when 6.1 has major compiler/development “bugs”.
What bugs? I have not come across anything yet. I have not been using
QNX long, but I like the development environment, and it works well for me.
Stacey
Watcom was SOooooo NICE !
But Watcom is dead or ain’t really going anywhere for now. (sic)
Not true. We have just release a pre-Beta release of 11.0c (*). When 11.0c
is fully released we will turn out attention of OpenWatcom 1.0.
openWatcom is strangling with licensed parts that can’t go public and
making
the task even harder (sic). =
Well that is still before us in terms of task but we are moving forward
right now . For a long time we weren’t doing anything while lawyers were
talking, but that is over now
Hope this clarifies matters
Stephen Howe [TeamSybase], also a member of the OpenWatcom team.
(*) WARNING!! WARNING!!
11.0c is a just a bug fix to 11.0b, 11.0a, 11.0, nothing more. It is
intended for current 11.0 users.
11.0c is NOT OpenWatcom 1.0.
For those without a prior release of Watcom C/C++ or Fortran, the only
target that will work if you download it are 16-bit DOS targets. The others
can be made to work (with some effort) but they require files that Sybase
does not fully own.
Hello Stephen
What OSs are being targeted?
Is QNX RTP amoung them?
Bill Caroselli
“Stephen Howe” <SPAMsjhoweGUARD@dial.pipex.com> wrote in message
news:9njg4l$1rc$1@inn.qnx.com…
Not true. We have just release a pre-Beta release of 11.0c (*). When 11.0c
is fully released we will turn out attention of OpenWatcom 1.0.Stephen Howe [TeamSybase], also a member of the OpenWatcom team.
Hello Stephen
What OSs are being targeted?
DOS, 16-bit Windows, OS/2, Win32 & Netware executables
Is QNX RTP amoung them?
No
Stephen Howe [TeamSybase]
London UK
BTW, QNX 6.1 is REALLY BAD!!!
Nothing that worked before doesn’t work at all !
I have had completely the opposite experience. QNX 6.0c was terrible,
and 6.1 is wonderfull.
Positive:
- QNX6.0c has a better looking, POSIX compatible, support well
templates
Yep.
- QNX4.25 is faster, better, smaller, more reliable, as a great
editor, as a
great compiler.
Great editor ? (to each his own I guess)
The GUI (screen drivers) were excellent on any computer including
old 486
and Pentium,
with a very low quantity of RAM.
The counter point for this, is that QNX6 supports multiple processors.
- Some QNX4 API were easier, some QNX6 API are harder but more
complete or
compliant…
Some QNX6 API stuff are also easier than QNX4 due to POSIX standard.Negative:
- QNX6.0c is slower, create huge executable, is VERY slow in GUI mode
for
old Pentium computers,
It’s all relative I guess, have you compared equivalent executable sizes
with Windows ? QNX6 is definately slower than QNX4, but not
significantly.
is slower to compiles, impossible to install directly on embedded
systems, has bad tendency to hang up
at boot time and during transfer to a target (flashing a target).
I happen to think QNX6 is superior for embedded systems; have you
managed to install QNX4 on an iPaq ? QNX6 runs on an iPaq.
- QNX4.25 had some tendancy to hang up Watcom C++ if used extensively
by a
lot of people.
It had thread-safe problem and related problems.
QNX4 had no thread safe problems, what it did have was a thread model
completely unlike anything else, and many people misunderstood it’s
limited applicability.
Expectation from QNX6:
ALL THE ADVANTAGE OF QNX4:
- In term of speed (execution, compiling, GUI)
- In term of space (footprint, executable size)
These are unreasonable expectations.
- In term of easy to install, run, learn, deploy, etc.
QNX6 is already easier to install, run, learn. Deploying will almost
certainly be more difficult due to the multi-processor capability,
however I believe QNX6 makes it about as easy as it gets.
PLUS POSIX Standard
Done.
PLUS New C++ features, that don’t affect C or C++ code not using it.
Coming soon, I hope.
PLUS better looking GUI
Done.
PLUS more functionalities
Done. QNX6 has so much more functionality than QNX4 it isn’t funny.
