Board index » cppbuilder » Re: What do you most want from BCB v9?

Re: What do you most want from BCB v9?


2004-05-14 09:41:21 PM
cppbuilder13
"Benjamin Pratt" < XXXX@XXXXX.COM >wrote in message
Quote
In my experience,
Intellisense only properly parses the code and gives me my list about %25
of
the time. On the other hand, CodeInsight works about 90%. If the code has
been background compilied, then I don't have to wait at all. Also, I've
found CodeInsight works with template code well, while Intellisense is
completely worthless with templates.


Hmmmm.... I am currently using VC6 but I am also using Whole Tomato Visual
Assist, so maybe I don't have the missing members problem that you see...
 
 

Re:Re: What do you most want from BCB v9?

Quote
Ok, I understand. I purposefully ...'ed my sentance that said that because
a
Delphi compiler for Linux would also allow the same, wouldn't it? It just
might not be pure C++.
Yes it would do the trick for Linux!
But and others platforms?
Quote
To be fair though, I think VCL should have been started in C++.
Agree 100 %
Quote
Now that it
is Pascal, thats OK.
I don't think so. If VCL was written in C++ there would have no need to a
search for a C++ multiplatform framework (like wxWindows)!
But Borland can "correct" that situation. If for historic reasons VCL was
written in Pascal, now the current reality shows that this decision imposes
big limitations (speaking about C++ product line).
Borland can "correct" this by recoding it in C++ that is a trully
multiplatform language.
Or make Pascal multiplatform and an ANSI/ISO standard adopted by the whole
Industry!
Saulo
 

Re:Re: What do you most want from BCB v9?

Valence Crearer wrote:
Quote

To be fair though, I think VCL should have been started in C++. Now that it
is Pascal, thats OK.

Everyone seems to keep suggesting that the VCL should be in C++ and I
would love to see it in C++.
But no-one has explained how the published section of a class that
provides extended RTTI (above and beyond what C++ supplies) could be
implemented in standard C++? Properties, methods and events can be done
using things such as boost::bind/function/signal etc, but the published
section, AFAICT, can't, so all this talk of a C++ VCL is not useful
until someone can suggest a solution to duplicate the functionality of
published:
Russell
 

{smallsort}

Re:Re: What do you most want from BCB v9?

Russell Hind wrote:
Quote
Valence Crearer wrote:
>
>To be fair though, I think VCL should have been started in C++. Now that it
>is Pascal, thats OK.
>

Everyone seems to keep suggesting that the VCL should be in C++ and I
would love to see it in C++.

But no-one has explained how the published section of a class that
provides extended RTTI (above and beyond what C++ supplies) could be
implemented in standard C++? Properties, methods and events can be done
using things such as boost::bind/function/signal etc, but the published
section, AFAICT, can't, so all this talk of a C++ VCL is not useful
until someone can suggest a solution to duplicate the functionality of
published:

Russell
Agreed. With one modification. One could use non-standard C++ :-}
 

Re:Re: What do you most want from BCB v9?

Quote
Agreed. With one modification. One could use non-standard C++ :-}
And the new Borland C++ multiplatform compiler could have an "extension" to
deal with this non-conformity in all supported platforms.
Saulo
 

Re:Re: What do you most want from BCB v9?

Don't forget PNG's.
 

Re:Re: What do you most want from BCB v9?

Yup. Same C library methodology going back to the 60's.
"Saulo I. Regis" wrote:
Quote
>Agreed. With one modification. One could use non-standard C++ :-}

And the new Borland C++ multiplatform compiler could have an "extension" to
deal with this non-conformity in all supported platforms.

Saulo
 

Re:Re: What do you most want from BCB v9?

"Saulo I. Regis" wrote:
Quote
>Delphi compiler for Linux would also allow the same, wouldn't it? It just
>might not be pure C++.

Yes it would do the trick for Linux!

But and others platforms?

Whats the market share? If Delphi's compiler is written in C++, whats the
problem? Recompile it first, then start recompiling OP. (You have a point on the
libraries, but it is doable.)
Quote
>Now that it
>is Pascal, thats OK.

I don't think so. If VCL was written in C++ there would have no need to a
search for a C++ multiplatform framework (like wxWindows)!

I'm have no strong opinion here, but I think the problem that must be overcome
for RAD to work multiplatform is contingent on resources (TButton, TEdit, etc.)
and making them work in a native way. The framework issue may not be trivial,
but I'm sure that you are right, Borland could compensate.
Quote
Or make Pascal multiplatform and an ANSI/ISO standard adopted by the whole
Industry!
Yeah, thats funny :-} But OP would be workable, even if not standard. Asside:
BCC could be workable across platforms using __property and __closure and the
like, even though that use is not standard. I do get sensitive when some
standards religious fanatics, (not you), suggest that to be multiplatform, it
must be limited to standards. I disagree vehemently, but do agree that it should
support the standards.
 

Re:Re: What do you most want from BCB v9?

Quote
Don't forget PNG's.
I'm not joking :) Extended TIFF can store black-white
A4/Letter format pages in les than 10-20 KB. In comparison,
JPG makes files 200-600 KB in the same category.
Such format is very nice to be present in the native way.
I'm sick of 3rd party components for this and that.
Everybody here looks at 'new' BCB from the height, and
that's OK. But there are so many 'simple' things that are
also important.
Best regards,
Vladimir Stefanovic
 

Re:Re: What do you most want from BCB v9?

Valence Crearer wrote:
Quote

Agreed. With one modification. One could use non-standard C++ :-}

My reasons for wanting the VCL written in C++ are two-fold
a) So we get full use of C++ features such as multiple inheritance,
without OP hangups (such as vtable implementations and virtual function
call differences)
b) So that we aren't tied to the Borland compiler. If a better, more
standards conforming compiler/better optimising compiler comes out, I
would like to be able to use that instead.
If Borland have to add extensions, then they only solve a). I'm not so
interested in a C++ VCL unless they solve both a and b.
And don't forget that we would loose access to all the pascal based
components if they did this at all, something people weren't happy about
when they thought we were going to have to move to wxWindows.
So I think the best bet for now is to stick with the OP VCL as is
Cheers
Russell
 

Re:Re: What do you most want from BCB v9?

Well, it's nice to have such simple things, but more important is to
have a compiler, and linker. We can find 3th party components to handle
TIFF and PNG or whatever, but if we don't have a development tool, we
are toasted.
Vladimir Stefanovic wrote:
Quote
>Don't forget PNG's.


I'm not joking :) Extended TIFF can store black-white
A4/Letter format pages in les than 10-20 KB. In comparison,
JPG makes files 200-600 KB in the same category.

Such format is very nice to be present in the native way.

I'm sick of 3rd party components for this and that.

Everybody here looks at 'new' BCB from the height, and
that's OK. But there are so many 'simple' things that are
also important.

Best regards,
Vladimir Stefanovic



 

Re:Re: What do you most want from BCB v9?

Quote
And don't forget that we would loose access to all the pascal based
components if they did this at all, something people weren't happy about
when they thought we were going to have to move to wxWindows.
Exactly. I think I have only 1 or 2 home-grown components made in C++, all
the others (and I use a lot) are OP. And I don't complain about this even a
little. Maybe because they work so well and they serve my purposes so
well... that I don't care if they were written in C++, OP or ASM. At the
end, what matters is what I can do for my customers, in a timely manner. And
for that, I depend from the Database and up in VCL. Maybe it's a bad
software developing decision, depending on so much 3rd party stuff? Well...
it could be, but maybe it's what makes my products stand apart from my
competitors', and I'm no willing to change this.
I don't think is that bad to have the VCL written in OP. Why was it written
with OP to begin with? Well... I certanly don't know. Maybe if they have
done this as they did OWL the world would be totally different. But, being
the things like they are, I see this as having the best from both worlds.
C++ and it's powerfull capabilities, and VCL/OP and it's powerfull
capabilities. The only problems, yes, serious, but I think possible to fix,
are the compatibility issues: virtual tables screwed up, header creation
problems, etc. I would really like to see them fixed, so more 3rd party
developers kept providing us, BCB users, with great tools. A lot of them
seem to have no interest in going thru the nightmare of making a component
BCB compatible, and I feel like we are missing a lot of great stuff.
--
Rodrigo Gómez
rgomez.msa.com.mx/gallery/
"Russell Hind" < XXXX@XXXXX.COM >escribi?en el mensaje
Quote
Valence Crearer wrote:
>
>Agreed. With one modification. One could use non-standard C++ :-}
>

My reasons for wanting the VCL written in C++ are two-fold

a) So we get full use of C++ features such as multiple inheritance,
without OP hangups (such as vtable implementations and virtual function
call differences)
b) So that we aren't tied to the Borland compiler. If a better, more
standards conforming compiler/better optimising compiler comes out, I
would like to be able to use that instead.

If Borland have to add extensions, then they only solve a). I'm not so
interested in a C++ VCL unless they solve both a and b.

And don't forget that we would loose access to all the pascal based
components if they did this at all, something people weren't happy about
when they thought we were going to have to move to wxWindows.

So I think the best bet for now is to stick with the OP VCL as is

Cheers

Russell
 

Re:Re: What do you most want from BCB v9?

I love the concept of C++ VCL too.
Russell Hind wrote:
Quote
Valence Crearer wrote:
>
>Agreed. With one modification. One could use non-standard C++ :-}
>

My reasons for wanting the VCL written in C++ are two-fold

a) So we get full use of C++ features such as multiple inheritance,
without OP hangups (such as vtable implementations and virtual function
call differences)
b) So that we aren't tied to the Borland compiler. If a better, more
standards conforming compiler/better optimising compiler comes out, I
would like to be able to use that instead.

Great, kudos to the standards. If Borland doesn't make either the best, or
one of the best, compilers in the world, then I'll not buy Borland anyway.
(I would would be willing to DLL some stuff with the Intel compiler if
borland doesn't catch up on that end.) I'm not going to ask my boss, though,
to pay Borland, Intel, M$ and whom ever else I choose without a very
significant reason.
Quote
If Borland have to add extensions, then they only solve a). I'm not so
interested in a C++ VCL unless they solve both a and b.
Understood and agreed. My job requires speed and flexibility of solutions.
Thats all. Independence from a vendor, when these manufacturers are out
sourcing much more significant things, is not an issue for us. So OP VCL
will do for now, since I necessarily must disagree with b) for my
environment. Complying with standards, for the sake of flexibility has its
advantages, but those are far outweighed by the the types of things you and
Rodrigo bring up, for us. Again, I know it depends on the developers
environment as to their choice; I know that their are many for whom C++
standards provide much more ROI than they do for us.
Quote
And don't forget that we would loose access to all the pascal based
components if they did this at all, something people weren't happy about
when they thought we were going to have to move to wxWindows.

So I think the best bet for now is to stick with the OP VCL as is
Amen.
 

Re:Re: What do you most want from BCB v9?

Quote
Well, it's nice to have such simple things, but more
important is to have a compiler, and linker.
Yes, of course. I agree 100%. But it should not be
forgotten that BCB is RAD tool, and many of us
are supposed to make the software as fast as it is
possible - I mean the software that is not indended
to be the market hit, but to fit some special needs
just in time.
Here is one concrete example:
I had coulple of days to scan 3000 printed documents of
bus time-tables and to make a simple program for
fast browsing/previewing/printing and such. Of course
scanned docs should be crypted.
First, I badly needed TIFFs which makes 10K per
scanned black-white page in comparison to
200-400 that JPG makes. It's easy to calculate that
I had problems when storing JPGs to CD.
Second, I used QReport just for previewing/printing
text before. On my great surprise QReport has a
serious BUG when printing T(DB)Images ?!
Quote
We can find 3th party components to handle
TIFF and PNG or whatever, [...]
Yes, that's true, but it has to pass some precious
time.
Quote
[...] but if we don't
have a development tool, we are toasted.
Thanks God that BCB9 is on horizon!
Best regards,
Vladimir Stefanovic
 

Re:Re: What do you most want from BCB v9?

Amen!
Vladimir Stefanovic wrote:
Quote
Thanks God that BCB9 is on horizon!