Request for comment: Proposed SQLite API changes

classic Classic list List threaded Threaded
69 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Request for comment: Proposed SQLite API changes

D. Richard Hipp
As currently implemented, when an error occurs during
sqlite3_step(), the function returns SQLITE_ERROR.  Then
you have to call either sqlite3_reset() or sqlite3_finalize()
to find the actual error code.  Suppose this where to
change in version 3.3.0 so that the actual error code
was returned by sqlite3_step().  That would mean that
moving from version 3.2.7 to 3.3.0 might involve some
minor code changes. The API would not be 100% backwards
compatible.  But the API would be cleaner.  

What does the community think about such a change?

Another proposal:  Suppose that when creating an
sqlite3_stmt using sqlite3_prepare, the original SQL
text was stored in the sqlite3_stmt.  Then when a
schema change occurred, the statement was automatically
recompiled and rebound.  There would no more SQLITE_SCHEMA
errors.  But sqlite3_stmts would use a little more
memory.  And sqlite3_step might take a little longer
to initialize sometimes if it found it needed to rerun
the parser.  

What about this change?  Is it a worth-while tradeoff?

--
D. Richard Hipp <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: Request for comment: Proposed SQLite API changes

developir@yahoo.com
I vote for the cleaner API changes even though they are
not 100% backwards compatible.  Alternatively you could
have a brand new step function, leaving the old versions with
the same functionality.

With the recent numeric/integer/division change, the working
check clause and this proposed API changed shouldn't the version
number should be bumped to 4.0.0 to indicate incompatibility with
past versions?

--- [hidden email] wrote:

> As currently implemented, when an error occurs during
> sqlite3_step(), the function returns SQLITE_ERROR.  Then
> you have to call either sqlite3_reset() or sqlite3_finalize()
> to find the actual error code.  Suppose this where to
> change in version 3.3.0 so that the actual error code
> was returned by sqlite3_step().  That would mean that
> moving from version 3.2.7 to 3.3.0 might involve some
> minor code changes. The API would not be 100% backwards
> compatible.  But the API would be cleaner.  
>
> What does the community think about such a change?
>
> Another proposal:  Suppose that when creating an
> sqlite3_stmt using sqlite3_prepare, the original SQL
> text was stored in the sqlite3_stmt.  Then when a
> schema change occurred, the statement was automatically
> recompiled and rebound.  There would no more SQLITE_SCHEMA
> errors.  But sqlite3_stmts would use a little more
> memory.  And sqlite3_step might take a little longer
> to initialize sometimes if it found it needed to rerun
> the parser.  
>
> What about this change?  Is it a worth-while tradeoff?
>
> --
> D. Richard Hipp <[hidden email]>
>
>



               
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
Reply | Threaded
Open this post in threaded view
|

RE: Request for comment: Proposed SQLite API changes

Drew, Stephen
In reply to this post by D. Richard Hipp
I'm for both changes...

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: 03 November 2005 13:18
To: [hidden email]
Subject: [sqlite] Request for comment: Proposed SQLite API changes

As currently implemented, when an error occurs during sqlite3_step(),
the function returns SQLITE_ERROR.  Then you have to call either
sqlite3_reset() or sqlite3_finalize() to find the actual error code.
Suppose this where to change in version 3.3.0 so that the actual error
code was returned by sqlite3_step().  That would mean that moving from
version 3.2.7 to 3.3.0 might involve some minor code changes. The API
would not be 100% backwards compatible.  But the API would be cleaner.  

What does the community think about such a change?

Another proposal:  Suppose that when creating an sqlite3_stmt using
sqlite3_prepare, the original SQL text was stored in the sqlite3_stmt.
Then when a schema change occurred, the statement was automatically
recompiled and rebound.  There would no more SQLITE_SCHEMA errors.  But
sqlite3_stmts would use a little more memory.  And sqlite3_step might
take a little longer to initialize sometimes if it found it needed to
rerun the parser.  

What about this change?  Is it a worth-while tradeoff?

--
D. Richard Hipp <[hidden email]>



Reply | Threaded
Open this post in threaded view
|

Re: Request for comment: Proposed SQLite API changes

Dan Kennedy
In reply to this post by D. Richard Hipp

> Another proposal:  Suppose that when creating an
> sqlite3_stmt using sqlite3_prepare, the original SQL
> text was stored in the sqlite3_stmt.  Then when a
> schema change occurred, the statement was automatically
> recompiled and rebound.

This seems pretty handy, but it can be done in a wrapper. It would
eliminate SQLITE_SCHEMA, but the idea that the structure of the
query can change between compilation and execution, or between
execution runs is a bit scary. If it's a "SELECT * FROM" query the
number of columns returned might change. The authorization callback
would have to be reinvoked from within sqlite3_step() too. I think
this is one that requires pretty careful consideration.




       
               
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
Reply | Threaded
Open this post in threaded view
|

Re: Request for comment: Proposed SQLite API changes

D. Richard Hipp
In reply to this post by D. Richard Hipp
Joe Wilson <[hidden email]> wrote:
>
> With the recent numeric/integer/division change, the working
> check clause and this proposed API changed shouldn't the version
> number should be bumped to 4.0.0 to indicate incompatibility with
> past versions?
>

That would compel me to change *all* of the API to use a
"sqlite4_" prefix instead of "sqlite3_".

--
D. Richard Hipp <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: Request for comment: Proposed SQLite API changes

D. Richard Hipp
In reply to this post by D. Richard Hipp
Dan Kennedy <[hidden email]> wrote:
> > Another proposal:  Suppose that when creating an
> > sqlite3_stmt using sqlite3_prepare, the original SQL
> > text was stored in the sqlite3_stmt.  Then when a
> > schema change occurred, the statement was automatically
> > recompiled and rebound.
>
> The authorization callback
> would have to be reinvoked from within sqlite3_step() too.

Yikes!  I didn't think of that.  This is pretty big
negative and will likely scuttle plans to do automatic
re-prepare.
--
D. Richard Hipp <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: Request for comment: Proposed SQLite API changes

Jay Sprenkle
In reply to this post by D. Richard Hipp
On 11/3/05, [hidden email] <[hidden email]> wrote:

> Joe Wilson <[hidden email]> wrote:
> >
> > With the recent numeric/integer/division change, the working
> > check clause and this proposed API changed shouldn't the version
> > number should be bumped to 4.0.0 to indicate incompatibility with
> > past versions?
> >
>
> That would compel me to change *all* of the API to use a
> "sqlite4_" prefix instead of "sqlite3_".

Two thumbs up!
Is the old sqlite3 going to be removed?
Reply | Threaded
Open this post in threaded view
|

RE: Request for comment: Proposed SQLite API changes

Fred Williams
In reply to this post by D. Richard Hipp
Just curious, why is this being done anyway?  I think this is the only
software product I have used that has this "feature."  I fail to see the
usefulness from way up here above the source code, and I don't have time
to look deeper.  But still curious as to why everybody has to rename all
their function calls between major releases.

I'm on Delphi 7.0 and have never been forced to change anything because
of a new release, since Delphi 1.0.  And closer to home, From PC DOS
Oracle to 8.0i Oracle.  Seems like a lot of additional work, and would
like to understand why.

Fred

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Thursday, November 03, 2005 7:56 AM
> To: [hidden email]
> Subject: Re: [sqlite] Request for comment: Proposed SQLite API changes
>
>
> Joe Wilson <[hidden email]> wrote:
> >
> > With the recent numeric/integer/division change, the working
> > check clause and this proposed API changed shouldn't the version
> > number should be bumped to 4.0.0 to indicate incompatibility with
> > past versions?
> >
>
> That would compel me to change *all* of the API to use a
> "sqlite4_" prefix instead of "sqlite3_".
>
> --
> D. Richard Hipp <[hidden email]>
>

Reply | Threaded
Open this post in threaded view
|

Re: Request for comment: Proposed SQLite API changes

Jay Sprenkle
> Just curious, why is this being done anyway?  I think this is the only
> software product I have used that has this "feature."  I fail to see the
> usefulness from way up here above the source code, and I don't have time
> to look deeper.  But still curious as to why everybody has to rename all
> their function calls between major releases.
>
> I'm on Delphi 7.0 and have never been forced to change anything because
> of a new release, since Delphi 1.0.  And closer to home, From PC DOS
> Oracle to 8.0i Oracle.  Seems like a lot of additional work, and would
> like to understand why.

This prevents existing code from being broken in subtle ways.
If you get the new version it won't compile, rather than giving you an
application that seems to work without very in depth testing.
Reply | Threaded
Open this post in threaded view
|

RE: Request for comment: Proposed SQLite API changes

developir@yahoo.com
In reply to this post by Fred Williams
It's a primitive form of namespaces in C.
Renaming the function calls allows Sqlite2 and Sqlite3 to coexist
within the same executable/binary.  

Mind you, if the functionality of a documented function changes
(as opposed to merely extended) I would think it would warrent
a major revision number increase.  Sqlite versions 3.1.0 and 3.2.0
did not change as radically as is planned for this upcoming release.

--- Fred Williams <[hidden email]> wrote:

> Just curious, why is this being done anyway?  I think this is the only
> software product I have used that has this "feature."  I fail to see the
> usefulness from way up here above the source code, and I don't have time
> to look deeper.  But still curious as to why everybody has to rename all
> their function calls between major releases.
>
> I'm on Delphi 7.0 and have never been forced to change anything because
> of a new release, since Delphi 1.0.  And closer to home, From PC DOS
> Oracle to 8.0i Oracle.  Seems like a lot of additional work, and would
> like to understand why.
>
> Fred
>
> > -----Original Message-----
> > From: [hidden email] [mailto:[hidden email]]
> > Sent: Thursday, November 03, 2005 7:56 AM
> > To: [hidden email]
> > Subject: Re: [sqlite] Request for comment: Proposed SQLite API changes
> >
> >
> > Joe Wilson <[hidden email]> wrote:
> > >
> > > With the recent numeric/integer/division change, the working
> > > check clause and this proposed API changed shouldn't the version
> > > number should be bumped to 4.0.0 to indicate incompatibility with
> > > past versions?
> > >
> >
> > That would compel me to change *all* of the API to use a
> > "sqlite4_" prefix instead of "sqlite3_".
> >
> > --
> > D. Richard Hipp <[hidden email]>
> >
>
>



               
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
Reply | Threaded
Open this post in threaded view
|

RE: Request for comment: Proposed SQLite API changes

Fred Williams
In reply to this post by Jay Sprenkle
Ah, that explains why I get all those bugs in each new release of Oracle
:-)

> -----Original Message-----
> From: Jay Sprenkle [mailto:[hidden email]]
> Sent: Thursday, November 03, 2005 8:44 AM
> To: [hidden email]
> Subject: Re: [sqlite] Request for comment: Proposed SQLite API changes
>
>
> > Just curious, why is this being done anyway?  I think this
> is the only
> > software product I have used that has this "feature."  I
> fail to see the
> > usefulness from way up here above the source code, and I
> don't have time
> > to look deeper.  But still curious as to why everybody has
> to rename all
> > their function calls between major releases.
> >
> > I'm on Delphi 7.0 and have never been forced to change
> anything because
> > of a new release, since Delphi 1.0.  And closer to home, From PC DOS
> > Oracle to 8.0i Oracle.  Seems like a lot of additional
> work, and would
> > like to understand why.
>
> This prevents existing code from being broken in subtle ways.
> If you get the new version it won't compile, rather than giving you an
> application that seems to work without very in depth testing.

Reply | Threaded
Open this post in threaded view
|

RE: Request for comment: Proposed SQLite API changes

Fred Williams
In reply to this post by developir@yahoo.com
Thanks.  I guess I never considered using two different releases of any
product within the same executable.  Wonder how many use this feature
and why?

> -----Original Message-----
> From: Joe Wilson [mailto:[hidden email]]
> Sent: Thursday, November 03, 2005 8:54 AM
> To: [hidden email]
> Subject: RE: [sqlite] Request for comment: Proposed SQLite API changes
>
>
> It's a primitive form of namespaces in C.
> Renaming the function calls allows Sqlite2 and Sqlite3 to coexist
> within the same executable/binary.
>
> Mind you, if the functionality of a documented function changes
> (as opposed to merely extended) I would think it would warrent
> a major revision number increase.  Sqlite versions 3.1.0 and 3.2.0
> did not change as radically as is planned for this upcoming release.
>
> --- Fred Williams <[hidden email]> wrote:
>
> > Just curious, why is this being done anyway?  I think this
> is the only
> > software product I have used that has this "feature."  I
> fail to see the
> > usefulness from way up here above the source code, and I
...

Reply | Threaded
Open this post in threaded view
|

Re: Request for comment: Proposed SQLite API changes

John Stanton-3
In reply to this post by D. Richard Hipp
The first proposal seems to me a very good one and contributes to
clarity in programs.  The second one is of dubious value and a poor
tradeoff in my opinion.
JS
[hidden email] wrote:

> As currently implemented, when an error occurs during
> sqlite3_step(), the function returns SQLITE_ERROR.  Then
> you have to call either sqlite3_reset() or sqlite3_finalize()
> to find the actual error code.  Suppose this where to
> change in version 3.3.0 so that the actual error code
> was returned by sqlite3_step().  That would mean that
> moving from version 3.2.7 to 3.3.0 might involve some
> minor code changes. The API would not be 100% backwards
> compatible.  But the API would be cleaner.  
>
> What does the community think about such a change?
>
> Another proposal:  Suppose that when creating an
> sqlite3_stmt using sqlite3_prepare, the original SQL
> text was stored in the sqlite3_stmt.  Then when a
> schema change occurred, the statement was automatically
> recompiled and rebound.  There would no more SQLITE_SCHEMA
> errors.  But sqlite3_stmts would use a little more
> memory.  And sqlite3_step might take a little longer
> to initialize sometimes if it found it needed to rerun
> the parser.  
>
> What about this change?  Is it a worth-while tradeoff?
>
> --
> D. Richard Hipp <[hidden email]>
>

Reply | Threaded
Open this post in threaded view
|

RE: Request for comment: Proposed SQLite API changes

Drew, Stephen
In reply to this post by D. Richard Hipp
"The first proposal seems to me a very good one and contributes to
clarity in programs.  The second one is of dubious value and a poor
tradeoff in my opinion."

Hmm. Perhaps. I currently do this in my wrapper anyway and it's
annoying, so it's not completely devoid of value.

-----Original Message-----
From: John Stanton [mailto:[hidden email]]
Sent: 03 November 2005 15:25
To: [hidden email]
Subject: Re: [sqlite] Request for comment: Proposed SQLite API changes

The first proposal seems to me a very good one and contributes to
clarity in programs.  The second one is of dubious value and a poor
tradeoff in my opinion.
JS
[hidden email] wrote:
> As currently implemented, when an error occurs during sqlite3_step(),
> the function returns SQLITE_ERROR.  Then you have to call either
> sqlite3_reset() or sqlite3_finalize() to find the actual error code.  
> Suppose this where to change in version 3.3.0 so that the actual error

> code was returned by sqlite3_step().  That would mean that moving from

> version 3.2.7 to 3.3.0 might involve some minor code changes. The API
> would not be 100% backwards compatible.  But the API would be cleaner.
>
> What does the community think about such a change?
>
> Another proposal:  Suppose that when creating an sqlite3_stmt using
> sqlite3_prepare, the original SQL text was stored in the sqlite3_stmt.

> Then when a schema change occurred, the statement was automatically
> recompiled and rebound.  There would no more SQLITE_SCHEMA errors.  
> But sqlite3_stmts would use a little more memory.  And sqlite3_step
> might take a little longer to initialize sometimes if it found it
> needed to rerun the parser.
>
> What about this change?  Is it a worth-while tradeoff?
>
> --
> D. Richard Hipp <[hidden email]>
>



Reply | Threaded
Open this post in threaded view
|

Re: Request for comment: Proposed SQLite API changes

Eric Scouten
In reply to this post by D. Richard Hipp
[hidden email] wrote:

> Another proposal:  Suppose that when creating an
> sqlite3_stmt using sqlite3_prepare, the original SQL
> text was stored in the sqlite3_stmt.  Then when a
> schema change occurred, the statement was automatically
> recompiled and rebound.  There would no more SQLITE_SCHEMA
> errors.  But sqlite3_stmts would use a little more
> memory.  And sqlite3_step might take a little longer
> to initialize sometimes if it found it needed to rerun
> the parser.  
>
> What about this change?  Is it a worth-while tradeoff?

I'm a big fan of this change. We do quite a lot of bookkeeping in our
own code to do exactly the same thing at the moment. It would make me
very happy to delete that code.

-Eric

--
Eric Scouten | [hidden email] | Photography: www.ericscouten.com
Reply | Threaded
Open this post in threaded view
|

Re: Request for comment: Proposed SQLite API changes

Dennis Cote
In reply to this post by D. Richard Hipp
[hidden email] wrote:

>As currently implemented, when an error occurs during
>sqlite3_step(), the function returns SQLITE_ERROR.  Then
>you have to call either sqlite3_reset() or sqlite3_finalize()
>to find the actual error code.  Suppose this where to
>change in version 3.3.0 so that the actual error code
>was returned by sqlite3_step().  That would mean that
>moving from version 3.2.7 to 3.3.0 might involve some
>minor code changes. The API would not be 100% backwards
>compatible.  But the API would be cleaner.  
>
>What does the community think about such a change?
>
>Another proposal:  Suppose that when creating an
>sqlite3_stmt using sqlite3_prepare, the original SQL
>text was stored in the sqlite3_stmt.  Then when a
>schema change occurred, the statement was automatically
>recompiled and rebound.  There would no more SQLITE_SCHEMA
>errors.  But sqlite3_stmts would use a little more
>memory.  And sqlite3_step might take a little longer
>to initialize sometimes if it found it needed to rerun
>the parser.  
>
>What about this change?  Is it a worth-while tradeoff?
>
>--
>D. Richard Hipp <[hidden email]>
>
>
>  
>
I think both of these proposed changes are useful enhancements to SQLite.

I also think it would be better to add a new sqlite3_step_v2() API
function that does this. This will eliminate the need to change the base
version number, since existing code can continue to use the existing
step function. New code, or those who want to modify their existing
code, could use the new function.

The new step function should be a wrapper around the existing step
function in much the same way as sqlite3_exec() wraps the entire
prepare, step, finalize process. It would do the enhanced error checks
and return the real error, or automatically re-prepare the SQL if the
error was SQLITE_SCHEMA.

This would give you the best of both worlds, backwards compatibility and
a cleaner API for new code.

Dennis Cote

Reply | Threaded
Open this post in threaded view
|

RE: Request for comment: Proposed SQLite API changes

Cariotoglou Mike
In reply to this post by D. Richard Hipp
ok, the sqlite_Schema thing can (and has) been wrapped. however, the
error code issue is there, I believe that we have agreed in the past
that it was bad design, but it could not be changed because of
compatibility issues. I,for one, am willing to comb my code and re-code
for this, so yes, please do it.

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Thursday, November 03, 2005 4:05 PM
> To: [hidden email]
> Subject: Re: [sqlite] Request for comment: Proposed SQLite API changes
>
> Dan Kennedy <[hidden email]> wrote:
> > > Another proposal:  Suppose that when creating an
> sqlite3_stmt using
> > > sqlite3_prepare, the original SQL text was stored in the
> > > sqlite3_stmt.  Then when a schema change occurred, the
> statement was
> > > automatically recompiled and rebound.
> >
> > The authorization callback
> > would have to be reinvoked from within sqlite3_step() too.
>
> Yikes!  I didn't think of that.  This is pretty big negative
> and will likely scuttle plans to do automatic re-prepare.
> --
> D. Richard Hipp <[hidden email]>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

RE: Request for comment: Proposed SQLite API changes

Cariotoglou Mike
In reply to this post by D. Richard Hipp
since you work in D7, as I do, you already have namespaces (in the form
of units), so this was never an issue, even if you wanted to have two
versions of the same code built-in. as to why, well, consider a database

managent tool that has to open both 2.x and 3.x databases, and the only
tool to structure your code and isolate interface from implementation is
a crappy .H file. these people (c programmers) live in wasteland, I
really admire them for the constructive way they use header files,
include files, defines,  make files, configure files and what not,and
still manage to write code that is write-once, compile everywhere. this
is something not easily achieved, given the tools they have to work
with. otoh, I live in delphi land from day 1, and I *know* what they are
missing...

> -----Original Message-----
> From: Fred Williams [mailto:[hidden email]]
> Sent: Thursday, November 03, 2005 5:10 PM
> To: [hidden email]
> Subject: RE: [sqlite] Request for comment: Proposed SQLite API changes
>
> Thanks.  I guess I never considered using two different
> releases of any product within the same executable.  Wonder
> how many use this feature and why?
>
> > -----Original Message-----
> > From: Joe Wilson [mailto:[hidden email]]
> > Sent: Thursday, November 03, 2005 8:54 AM
> > To: [hidden email]
> > Subject: RE: [sqlite] Request for comment: Proposed SQLite
> API changes
> >
> >
> > It's a primitive form of namespaces in C.
> > Renaming the function calls allows Sqlite2 and Sqlite3 to coexist
> > within the same executable/binary.
> >
> > Mind you, if the functionality of a documented function changes (as
> > opposed to merely extended) I would think it would warrent a major
> > revision number increase.  Sqlite versions 3.1.0 and 3.2.0 did not
> > change as radically as is planned for this upcoming release.
> >
> > --- Fred Williams <[hidden email]> wrote:
> >
> > > Just curious, why is this being done anyway?  I think this
> > is the only
> > > software product I have used that has this "feature."  I
> > fail to see the
> > > usefulness from way up here above the source code, and I
> ...
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

RE: Request for comment: Proposed SQLite API changes

Clay Dowling

Cariotoglou Mike said:

> a crappy .H file. these people (c programmers) live in wasteland, I
> really admire them for the constructive way they use header files,
> include files, defines,  make files, configure files and what not,and
> still manage to write code that is write-once, compile everywhere. this
> is something not easily achieved, given the tools they have to work
> with. otoh, I live in delphi land from day 1, and I *know* what they are
> missing...

As somebody who lives in both worlds, C land isn't such a bad place.  It's
a little like the difference between driving a nice comfortable Ford
Taurus (Delphi) and a BMW Z3 with a stick shift (if you haven't done it,
do: you probably never realized that driving could be so fun).  I like
driving both.  But there are certain situations where one is a lot better
than the other, as I'm sure you're aware.

Clay Dowling
--
Simple Content Management
http://www.ceamus.com

Reply | Threaded
Open this post in threaded view
|

RE: Request for comment: Proposed SQLite API changes

Cariotoglou Mike
In reply to this post by D. Richard Hipp
Clay, I like stick-shifts, I drive motorcycles *and* stick-shifts, and I
was about to buy a Z4, but the wife stopped me (judging, correctly, that
it is a girl-trap).
I even write assembly now and then, when absolutely needed. I cant say
it is fun, though.
the thing is, I never have seen a single task implemented in C (not C++
mind you), that can not be implemented in Delphi, with the SAME or
better performance,
in a way that is 10 times more elegant, much better for maintainance and
clarity, and less effort. afaik, the only down-side is that you don't
get the delphi compiler in anything else than windows (ok, and linux).
other than that, I see absolutely no advantage in the C language, and
certainly no "fun" in it... for me, it is as fun as trying to start a
fire by rubbing two sticks together. it can be done, and people have
been doing it for thousands of years. but that was only because they did
not have matches, not because they liked it.
so, assuming that you had an efficient portable implementation of object
pascal, do you really think *new* developers would opt to use C anyway ?

> -----Original Message-----
> From: Clay Dowling [mailto:[hidden email]]
> Sent: Thursday, November 03, 2005 7:53 PM
> To: [hidden email]
> Subject: RE: [sqlite] Request for comment: Proposed SQLite API changes
>
>
> Cariotoglou Mike said:
>
> > a crappy .H file. these people (c programmers) live in wasteland, I
> > really admire them for the constructive way they use header files,
> > include files, defines,  make files, configure files and
> what not,and
> > still manage to write code that is write-once, compile everywhere.
> > this is something not easily achieved, given the tools they have to
> > work with. otoh, I live in delphi land from day 1, and I
> *know* what
> > they are missing...
>
> As somebody who lives in both worlds, C land isn't such a bad
> place.  It's a little like the difference between driving a
> nice comfortable Ford Taurus (Delphi) and a BMW Z3 with a
> stick shift (if you haven't done it,
> do: you probably never realized that driving could be so
> fun).  I like driving both.  But there are certain situations
> where one is a lot better than the other, as I'm sure you're aware.
>
> Clay Dowling
> --
> Simple Content Management
> http://www.ceamus.com
>
>
>
>

1234