Board index » cppbuilder » Re: Commitment to C++?

Re: Commitment to C++?


2008-03-29 02:24:05 AM
cppbuilder7
Roddy Pratt wrote:
Quote

Well, I also want a language with destructors for stack-allocated
objects
Yes, but you still can't do that with VCL objects in C++ Builder.
Quote
so I don't have code that is 30% news,deletes, trys,finallys...
...and one that can use third-party C libraries without writing header
translations.

Agreed, but if you are doing code that is principally GUI presentation,
Delphi and the VCL work together very well, and they don't require
translating Delphi idioms into C++.
Also, the raw speed of the Delphi compiler is still very impressive.
Dennis Cote
 
 

Re:Re: Commitment to C++?

"Roddy Pratt" < XXXX@XXXXX.COM >writes:
Quote
Also agreed - however a lot of C/C++ libraries avoid bleeding edge
techniques requiring near-perfect standards compliance because that
drastically limits the available customers. I agree that will change in
time.
I'm not so sure that this statement is true. Perhaps a lot of
libraries don't make use of some advanced C++ features, but the
"drastically limits the available customers" conclusion may be
exaggerating. Sure, embedded systems use old C++ compilers, but
they're not BCB customers (or potential customers) either.
On Windows, look at the competition and what level of language support
they actually have. I think the sad reality is that bleeding edge
techniques used by libraries would not drastically limit the available
customers.
--
Chris (TeamB);
 

Re:Re: Commitment to C++?

Dennis Cote wrote:
Quote
Yes, but you still can't do that with VCL objects in C++ Builder.
Ah - but you can have a autoptr style of template that wraps them in a
stack-based form.
Quote
Agreed, but if you are doing code that is principally GUI
presentation, Delphi and the VCL work together very well
Yes - unfortunately Delphi and C++ don't work so well together. C++ can
call Delphi functions easily, but the other way round has always seemed
painful.
Quote
and they don't require translating Delphi idioms into C++.
I guess I just think of them as C++Builder idioms ;-)
I've never programmed in C++ outside BCB, so my viewpoint may be a
little blinkered: But, I know what works for me.
- Roddy
 

{smallsort}

Re:Re: Commitment to C++?

Chris Uzdavinis (TeamB) wrote:
Quote
I'm not so sure that this statement is true.
Nor am I, but it feels a good guess: If you were setting out to develop
a library to be distributed in source form, you'd look closely at the
language features supported (or not) by the primary development tools
in your target market, at the point when you start development. And I
think you probably wouldn't want to rewrite it to take advantage of new
features later.
Some of the most useful libraries (to me, anyway) are still written in
C: Freetype and libsndfile, for example. C++ facades would be nice, but
I wouldn't want them rewritten from cold.
- Roddy
 

Re:Re: Commitment to C++?

Andre Kaufmann wrote:
Quote
Randall Parker wrote:
>So far my main beef is with the linker. I expected they'd finally have
>it fixed by now. Well no.

They can't fix it, if they can't reproduce it.
Actually, they fixed it. Really. I think they already had a fix.
Quote
But it should be fairly
simple to investigate an access violation, which occurs on a clients PC.
But the linker doesn't write any debug information on an access
violation, but catches them all and simply stops linking.
The linker really needs to fail in more verbose ways.
Quote

>[...]

Andre
 

Re:Re: Commitment to C++?

Leo Siefert wrote:
Quote
Andre Kaufmann wrote:

>They can't fix it, if they can't reproduce it.

Well, we now have two reproducible cases. One I added to a report a
little over a week ago and another that Jason Cipriani just worked up
yesterday and should be to CodeGear soon. I expect that this will be
enough for them to be able to fix at least some of the linker issues.
The build I was given from Thursday afternoon (at least that is the
timestamp) fixes my problem.
CodeGear is on top of it. Go CodeGear!
I never would have imagined getting a fix so quickly from the old
regime a few years ago.
Quote

- Leo
 

Re:Re: Commitment to C++?

Chris Uzdavinis (TeamB) wrote:
Quote
Sure, embedded systems use old C++ compilers, but
they're not BCB customers (or potential customers) either.
Embedded is going Linux in a big way.
I'm on a Linux project which has a big Win32 sim of the Linux environment
that we use for debugging. That is _not_ the only embedded Linux
project I'm aware of for which that is the case.
Since Linux has gcc we can use advanced C++ features (and we do). We need
our Win32 sim environment to get built with a fully featured C++ compiler.
Quote
On Windows, look at the competition and what level of language support
they actually have. I think the sad reality is that bleeding edge
techniques used by libraries would not drastically limit the available
customers.
MS VS C++ support seems pretty good.
 

Re:Re: Commitment to C++?

"Roddy Pratt" < XXXX@XXXXX.COM >wrote in message
Quote
Chris Uzdavinis (TeamB) wrote:

>I'm not so sure that this statement is true.

Nor am I, but it feels a good guess: If you were setting out to develop
a library to be distributed in source form, you'd look closely at the
language features supported (or not) by the primary development tools
in your target market, at the point when you start development. And I
think you probably wouldn't want to rewrite it to take advantage of new
features later.
Well, there is a large difference between "not rewriting existing libraries
to take advantage of new features that didn't exist when the library was
created" and "writing new libraries that specifically avoid new features".
Quote
Some of the most useful libraries (to me, anyway) are still written in
C: Freetype and libsndfile, for example. C++ facades would be nice, but
I wouldn't want them rewritten from cold.
I would love to see them rewritten. Actually, the fact that those are still
written in C, I think, stems from the fact that they were *originally*
written in C, and there is not a compelling enough reason to rewrite them.
Both Freetype and libsndfile, to use your examples, have been around for a
very long time. I'm not a big fan of sticking to C in new libraries,
especially when I see libraries that start to take extra effort to
reimplement features that are a native part of C++, such as inheritence and
private data (prime example: GTK+ *shudder*
library.gnome.org/devel/gobject/stable/gobject-The-Base-Object-Type.html -
- of course, again, GTK+ has been around for some time, so it made sense to
write it in C when C++ was still in a major state of turmoil).
So I do not think C++ libraries avoid bleeding edge features for any
reason -- new C++ language features are part of the standard and won't go
away. I think that existing C++ libraries are not rewritten to take
advantage of them, however, and rightly so. They are different things, and
in any case, no matter *what*, that is not a justification at all for
compiler laziness wrt standard compliance. Period. It is a compiler's
responsibility to adhere to the standard, while it is the option of a
library's author whether or not to take advantage of new features. One is
not a justification for the other.
I feel the need to quote Dennis Cote for emphasis here:
"The current compliance issues have little if anything to do with Borland's
extensions, they are areas where the compiler doesn't correctly compile code
using standard features."
In the end, if a compiler is standard compliant and some source code does
not compile with it, it is the source code that is broken. If code is
correct C++ and the compiler does not accept it, the compiler is broken. If
code is not correct C++, and the compiler accepts it, both are still broken.
In the case of old libraries that are no longer maintained and no longer
compile on correct compilers, the only real solution is to come up with your
own workarounds and patches, as technically the broken source code is not
C++. Third-party libraries are not a reason to hold back development on a
compiler.
Of course, on the other hand, if Borland's own APIs take advantage of
loopholes in Borland's own compiler, while everything is broken (and
*should* be fixed), it may not be realistically possible for that to happen,
even though it should. In that case, it's a really unfortunate situation,
and would put Borland (or whoever) in a really bad position relative to the
competition.
Jason
 

Re:Re: Commitment to C++?

Randall Parker wrote:
Quote
Andre Kaufmann wrote:
[...]
They can't fix it, if they can't reproduce it.

Actually, they fixed it. Really. I think they already had a fix.
May be. I'll give it a try as soon as RAD Studio 2008 is available,
since I have to migrate a BCB6 project that is on hold for 3 years now.
Quote
[...]
Andre
 

Re:Re: Commitment to C++?

In article <47ed18f3$ XXXX@XXXXX.COM >, David Perkins wrote:
Quote
>Why do you leap to include third party components? They are not needed
>to use the VCL effectively.

It depends what you're developing. I use them so that I don't have to
write my own spell-checker, advanced data grid, report
generator/designer, comms, 3-tier components, CTI, encryption,
compression - you get the picture.
It makes sense to use third-party libraries when developing large
applications, but those libraries don't *have* to provide a VCL component
interface to be useful in BCB programs. From your list, for example,
something like a data grid is very much a visual component and it makes
sense to use one that fits into the framework you're using, but OTOH I
don't see any need for encryption or compression libraries to have a VCL
interface at all.
Increased standardization will bring more of these non-visual libraries
within reach of BCB developers.
Cheers,
Daniel.
 

Re:Re: Commitment to C++?

In article <47eccd92$ XXXX@XXXXX.COM >, Roddy Pratt wrote:
Quote
>The advantage of standardization in programming languages is that it
>enables the production of portable code that works on a wide range of
>platforms with predictable results.

That's true but not helpful.
It's helpful in that it explains that by having a more standards-compliant
C++ in BCB you can look forward to having even more third-party code
available to you in your applications. Some of that extra code will be
native C++ libraries that you can just compile and/or link in, some will
be wrapped in an easy-to-swallow VCL wrapper.
Either way, you can look forward to using the familiar VCL to build GUIs
that front-end ever-more complex application logic, because more
third-party code will be able to be compiled with the CodeGear compiler
and linked into your applications.
The bottom line is that portability benefits us all.
Quote
To my mind the compiler isn't the reason why people use C++Builder, and
never should be. To rephrase Clinton, "It's the VCL, stupid", and thus
the third-party component infrastructure.
You're right that the compiler isn't the reason that people use BCB. It
may have been once, it may be again, but right now it is not the best
compiler in its market sector. I don't think it's solely the VCL, either,
though -- if it was, why wouldn't everyone just use Delphi?
Quote
Delphi/C++Builder have let me develop applications for almost 12 years
without the terrifying framework churn that MS tools would have
required.
I must say that I have not experienced "terrifying framework churn". The
MS tools are different, yes, and I agree that .NET is a bloated
irrelevance but the tools do basically the same job in a slightly
different way. VCL makes GUI design (in particular) a little quicker ...
but how many percent of the time taken to complete a software project come
down to GUI design? 5%? 3%? It's almost insignificant.
I don't mean to be critical of the VCL, here, just to point out that for
significant applications the VCL can make very little difference to the
overall development effort required.
Quote
We know that C++Builder without a VCL framework has no future
whatsoever (C++BuilderX, anyone?) ...
We don't *know* that at all. We know that a half-hearted attempt was made
some time ago, that it wasn't an instant runaway success, and that Borland
lost interest in it thereafter. That's not the same as saying that the
idea has no future! I thought CBX had great potential -- I was
particularly attracted to the possibilities of a RAD environment for
cross-platform work -- but it failed to realize any of it before dieing of
neglect ... which was rather sad.
Cheers,
Daniel.
 

Re:Re: Commitment to C++?

agreed.
I'm working on an embedded linux app (uclinux based on an Arm chip) and I do
all development on Win32 using BCB2007.
It's an excellent way of producing reliable code - I use CodeGuard to find
leaks/buffer over-runs - but using the STL has made my life much easier.
I have even written a basic GUI that runs on Linux and BCB identically.
I have been very happy with this approach and it has got the application
working much faster and easier than I had thought.
It is definitely important that CodeGear track the C++ standards so that
jobs like this can continue.
(Oh and we're using GCC under linux....)
Cheers, Pete
"Randall Parker" <"STOPfutureEVILpundit[at]EVILfuturePOXpunditSPAM[dot]com">
wrote in message news:47ed9dec$ XXXX@XXXXX.COM ...
Quote
Chris Uzdavinis (TeamB) wrote:
>Sure, embedded systems use old C++ compilers, but
>they're not BCB customers (or potential customers) either.

Embedded is going Linux in a big way.

I'm on a Linux project which has a big Win32 sim of the Linux environment
that we use for debugging. That is _not_ the only embedded Linux
project I'm aware of for which that is the case.

Since Linux has gcc we can use advanced C++ features (and we do). We need
our Win32 sim environment to get built with a fully featured C++ compiler.

>On Windows, look at the competition and what level of language support
>they actually have. I think the sad reality is that bleeding edge
>techniques used by libraries would not drastically limit the available
>customers.

MS VS C++ support seems pretty good.
 

Re:Re: Commitment to C++?

David Perkins < XXXX@XXXXX.COM >wrote:
Quote
>Personally I'm really glad that Alisdair is dedicating so much of his
>time to contributing to the forthcoming C++ standard rather than to
>blogging. To get an idea check where his name appears here:

I'm not too fussed about C++ standards to be honest, I'm more interested
in BCB having a rich supply of third-party components to use. [...]
Isn't that a contradiction in itself?
Quote
I would also question whether the C++ product manager should be devoting
a large part of their working time on the standards committee, rather
than getting out there and evangelising about BCB and spreading the word.
Um, Alsidair has been an active committee member long
before CG hired him. That they hired him, IMHO should
be a seen as a very good sign. (FWIW, AFAIK the infamous
and notoriously bad VC6 was release around the time MS
lost their vote in the standards committee because they
hadn't shown up for too long. And they were beaten for
that version for a very long time. In fact, if you hang
out in their newsgroups and read all those embarassing
questions from users who -- after ten years -- finally
try to upgrade to some not as ancient version, you will
realize that it still curses them.)
Schobi
--
XXXX@XXXXX.COM is never read
I'm HSchober at gmx dot de
"The trouble with being a god is that you've got
no one to pray to." Terry Pratchett
 

Re:Re: Commitment to C++?

Roddy Pratt < XXXX@XXXXX.COM >wrote:
Quote
Dennis Cote wrote:

>At one time it was considered to be a state of
>the art compiler with industry leading standard compliance.

I know - but that's no longer the case.

>The compiler was a reason to buy and use Borland's C++ products.

I'd love that to be true again, but I think it's unlikely to be the
best use of CG's limited resources to get it to that point. Others (eg
Intel) have invested significantly in their C++ compiler optimization
technology. And because of the non-standard extensions, CG are unlikely
to even be able to buy in a modern front from the likes of www.edg.com
who did the C++BuilderX one, IIRC.
I think it was in one of these newsgroups here that
someone pointed out that EDG has only three guys to
come up with their incredible front end, Comeau had
about as many to craft that great compiler from it,
and Dinkumware has about as many, too.
So it really isn't only the /amount/ of resources
which matters.
Quote
[...]
>I can integrate the VCL
>for GUI code with many of the very good C and C++ libraries that are
>readily available for backend functionality.

Agreed - that's a big benefit for me too.

>The ability to use these C/C++ libraries can be impaired by poor
>standards compliance...

Also agreed - however a lot of C/C++ libraries avoid bleeding edge
techniques requiring near-perfect standards compliance because that
drastically limits the available customers. I agree that will change in
time.
Most of them work fine with VC. So I don't see how
the amount of potential customers can be limited.
(Or what did you want to say with "limits the
customers"? <g>)
Quote
- Roddy
Schobi
--
XXXX@XXXXX.COM is never read
I'm HSchober at gmx dot de
"The trouble with being a god is that you've got
no one to pray to." Terry Pratchett
 

Re:Re: Commitment to C++?

Randall Parker wrote:
Quote
The build I was given from Thursday afternoon (at least that is the
timestamp) fixes my problem.
That's great news. I hope they can get it through qa and released to
the public quickly.
- Leo
 

Re:Re: Commitment to C++?

"Roddy Pratt" < XXXX@XXXXX.COM >writes:
Quote
Chris Uzdavinis (TeamB) wrote:

>I'm not so sure that this statement is true.

Nor am I, but it feels a good guess: If you were setting out to develop
a library to be distributed in source form, you'd look closely at the
language features supported (or not) by the primary development tools
in your target market, at the point when you start development. And I
think you probably wouldn't want to rewrite it to take advantage of new
features later.

Some of the most useful libraries (to me, anyway) are still written in
C: Freetype and libsndfile, for example. C++ facades would be nice, but
I wouldn't want them rewritten from cold.
People writing commercial libraries tend to target where the most
developers are, which would be Microsoft's compiler. If it works on
other platforms, that would be a bonus, but not all that important.
The other player's compiler would NOT affect the design. If they
can't compile the code, then their users don't get to use the library,
unless the problems are trivial and the amount of work to support it
is minimal. If it takes any kind of serious effort, it absolutely
will not be done.
In short, I believe BCB users lose out if BCB's compliance doesn't
improve, and I'm glad Alistair is associated with BCB.
--
Chris (TeamB);