Board index » cppbuilder » Re: Crossroad BCB5 BCB6 CBX MS.NET GCC

Re: Crossroad BCB5 BCB6 CBX MS.NET GCC


2003-10-24 05:13:16 PM
cppbuilder76
On Fri, 24 Oct 2003 10:44:26 +0200, Marco < XXXX@XXXXX.COM >wrote:
Quote
Borland is not the only one. Look at Microsoft. There are many Visual
Basic programmers out there. Microsoft enforced them to VB.NET, that
means practically to rewrite the code.
Not really. If you want to port your app to VB.Net, you have to rewrite from
scratch. If I had to do that, I'd probably use C#, since VB.Net seems to be
NET's stepchild.
Of course, you can always keep your 'legacy' code in plain VB and maybe hide
it behind a COM interface.
As a VB user, I was very pissed off with the death of the language, but after
calming down, I now realize it's not such a tragedy.
Same thing for BCB (it looks like I have a great skill for chosing tools with
a great future ;-). The BCB situation is actually much better: whatever
Borland does, your code is written in a standard language with several
implementations, and only your GUI is propietary.
Relax, the situation isn't that bad. :-)
 
 

Re:Re: Crossroad BCB5 BCB6 CBX MS.NET GCC

On Thu, 23 Oct 2003 21:42:28 -0400, Ronald Praver < XXXX@XXXXX.COM >wrote:
Quote
Sooooo. After all that rambling I wish to pose a question to one and all.
If you were in my position and had this problem and have read the forums
with rummers of NO BCB7 and no more support of VCL's etc.
and you were faced with the prospects of breaking the app into smaller
pieces to regain linking and debug capability, with the possibility of
no more
future compilers that support this platform, or use this effort to drop
OWL VCL's in lue of another platform say .NET or whatever, what would you
do so?
I would certainly break the app into smaller components (DLLs, COM, whatever).
It will fix your problem for sure and will make your life easier (reasonable
compile times).
How do you now that VC doesn't have the same symbol table limitation?
Break down your app into components and worry about the future of the VCL when
Borland says something official.
Don't forget that every Delphi user has the source code for the VCL. If
Borland drops it, I'm sure the Delphi community will suport it. Those
pascal-sick folks are very active. ;-)
 

Re:Re: Crossroad BCB5 BCB6 CBX MS.NET GCC

Are you working in CB 5 or CB6? I ran into the same linker problem with CB 5
and CB 6 fixed it.
However, I switched ALL of my NEW development to VS .NET a couple of weeks
ago because:
1) I am tired of Borland management sending out poor John (Kaster) to make
promises/stands to pacify those of us concerned about OUR future with CB.
2) Borland management doesn't have a clue how to work with developers. The
reason Windows is so popular is because Microsoft has ALWAYS treated
programmers with some respect (the Microsoft MDN is a good example).
3) Borland has failed the C++ community in the past with OWL. Many of us
can't afford to get "Borlanded" yet again.
4) Borland can't provide a simple road map to let us know where they are
going. In all of their press releases announcing CBX, they state they want
to support C++ programmers because we are "predicted" to be the largest
group of programmers through 2005. What happens AFTER that? They tell us we
have been "X"ed like the Jamie Kennedy show?
5) And my final reason: imagine sticking with an unsupported product like CB
6 and getting a show stopping bug like the infamous linker problem! Then
what?
Regards,
Shane
 

{smallsort}

Re:Re: Crossroad BCB5 BCB6 CBX MS.NET GCC

Ronald Praver < XXXX@XXXXX.COM >wrote:
Quote
[...]
If you were in my position and had this problem and have read the forums
with rummers of NO BCB7 and no more support of VCL's etc.
and you were faced with the prospects of breaking the app into smaller
pieces to regain linking and debug capability, with the possibility of
no more
future compilers that support this platform, or use this effort to drop
OWL VCL's in lue of another platform say .NET or whatever, what would you
do so?
I have said this here in this ng a numerous
times during the last few weeks, but here it
goes again: Make yourself independend of any
single one vendor.
The way to accomplish this is:
o Separate you code into core code, that
could be implemented using standard C++
(plus something like boost etc. which is
not likely to vanish) and the parts that
are vendor dependend.
The latter would be anything that directly
or indirectly uses some OS API as well as
3rd-party software. (A GUI lib inderictly
uses an OS GUI API.)
o For all the vendor dependend parts, write
interfaces, which abstract the operations
performed by those parts, so that these
interfaces do not depend on any vendor's
API or Lib.
For the GUI that means, hide it behind an
interface so that users (your core code)
don't see, note, or care how this will be
implemented.
I know that, for an app that isn't written with
these ideas in mind, this is a major undertaking.
However, once you need to port to a different
platform/compiler/GUI lib, you have to do much
of this work anyway. The difference is that,
instead of porting from vendor A's GUI lib to
vendor B's GUI lib you port to your own GUI lib
abstraction. The additional cost is for designing
this abstraction and implementing the thin layer
between its interface and the lib you use to
implement it. (For a start, this could still be
vendor A's lib.)
The benefit of this is, that you can, behind
the interfaces, switch from vendor A to B with
recompiling the interface's implementation and
re-linking the rest of the app. It is thus much
easier to port your app to a different platform,
compiler, GUI lib, or whatever you want to
change.
To be honest, I'd have to add that, unless you
have experience with designing such interfaces,
you will find after a while, that you didn't
consider important details. This is especially
true when you have to port to a platform/compiler/
lib which you didn't know/consider beforehand.
And that might call for refactoring or even
re-design. However, this is as with all software:
We learn by doing things, and what we produce
improves over time.
Also, it is certainly true that this only makes
sense when you either have a piece of code that
is rather big, hard to port, and is expected to
have a longer liftime, or if you have a lot of
code so that coding it against a common framework
would help.
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers org
"And why should I know better by now/When I'm old enough not to?"
Beth Orton
 

Re:Re: Crossroad BCB5 BCB6 CBX MS.NET GCC

On Thu, 23 Oct 2003 Ronald Praver wrote:
Quote
Recently we started to run into a linker error LME 1657. .... We seem to
have reached the BorZone.
Sounds very familiar. It becomes LME 1659 with Patch 4, and LME 1661 with
the version shipped with CBX.
Quote
We opened a incident with Borland and got the fastest response I had
ever gotten
from a support employee. No, joke this guy was pleasant and helpful. BTW
his name is Chen. Borland you need more of this guy.
I'll agree there, having dealt with Chen several times.
Quote
Anyway I
digress. Within 12 hrs or so I got a response that this is a known
problem and has not been fixed in BCB5 or BCB6. Therefore I will assume
it will not be fixed.
Maybe you should ask again ;-)
Hugo
 

Re:Re: Crossroad BCB5 BCB6 CBX MS.NET GCC

Quote
As for your problem: Does anyone know whether any non-Borland linker can
link Borland executables? Or does the need to link OP and Borland C++
create stuff in objs that only Borland's linker can handle?
The linker performs some of the magic involved with #pragma package
smart_init, Initialize, Finalize, etc. It does so by looking for
specific comment records that the compiler places in the OBJ.
It may perform other magic too that I don't know about.
h^2
 

Re:Re: Crossroad BCB5 BCB6 CBX MS.NET GCC

This is easy. Go with Microsoft tools. I use them at work everyday and
their development tools really good.
Be fore-warned though. If you use .net, the users of your apps will
require the .net runtime. If that isn't the issue then you'll find C#
to be very Delphi/Java like. Their framework is *VERY* similar to VCL.
You'll find the conversion pretty straight forward and you won't be
getting jerked around by Borland any longer.
The downside is you'll be moving over to the darkside and become a
minion of the evil empire.
Ronald Praver wrote:
Quote
Sooooo. After all that rambling I wish to pose a question to one and all.
If you were in my position and had this problem and have read the forums
with rummers of NO BCB7 and no more support of VCL's etc.
and you were faced with the prospects of breaking the app into smaller
pieces to regain linking and debug capability, with the possibility of
no more
future compilers that support this platform, or use this effort to drop
OWL VCL's in lue of another platform say .NET or whatever, what would you
do so?

 

Re:Re: Crossroad BCB5 BCB6 CBX MS.NET GCC

"Hendrik Schober" < XXXX@XXXXX.COM >wrote in message
Quote

I have said this here in this ng a numerous
times during the last few weeks, but here it
goes again: Make yourself independend of any
single one vendor.
The way to accomplish this is:
o Separate you code into core code, that
could be implemented using standard C++
(plus something like boost etc. which is
not likely to vanish) and the parts that
are vendor dependend.
The latter would be anything that directly
or indirectly uses some OS API as well as
3rd-party software. (A GUI lib inderictly
uses an OS GUI API.)
Hi Hendrik,
Perhaps this question is more appropriate for another group, but you have
brought up something I am very interested.
I would like to follow your approach for a thermodynamic application I am
writing. I am rather new to C++, so excuse my lack of knowledge on this. I
want the core code to spit out some info to the user during some of the
calculations, so I am currently sending output to std::cout. But, when I go
and implement a GUI, I want this output sent out to a log window, such as a
TRichEdit.
Using your approach, how can I easily re-direct std::cout to a TRichEdit?????
I saw a question like this a couple of weeks ago, and the response was 'NO
CAN-DO'. If that is true, how do I re-drect output IF I HAVE FORMAT FLAGS
in my std::cout code?? It seems here it would be easier to do my original
coding linked to a GUI components like VCL. It seems your approach may be
easier said than done.
Doug
 

Re:Re: Crossroad BCB5 BCB6 CBX MS.NET GCC

No Fernando, there are tools which will help you migrate your old VB6 code
to VB.Net. I would say that it'll be able to process between 75-80 percent
of your code, but that's better than re-writing 100% of it.
Quote
>Borland is not the only one. Look at Microsoft. There are many Visual
>Basic programmers out there. Microsoft enforced them to VB.NET, that
>means practically to rewrite the code.

Not really. If you want to port your app to VB.Net, you have to rewrite
from
scratch. If I had to do that, I'd probably use C#, since VB.Net seems to
be
NET's stepchild.

Actually it's C++ that seems to be the .Net stepchild.
Quote
Of course, you can always keep your 'legacy' code in plain VB and maybe
hide
it behind a COM interface.

Yup....call into unmanaged land <grin>
 

Re:Re: Crossroad BCB5 BCB6 CBX MS.NET GCC

Doug,
Do you HAVE to output stdout ? You couldn't modify your code to output to a
different stream ?
If you did, what you could do is to create a named pipe or some other
communication construct that can be streamed.
You can create the named pipe, strictly as a PIPE_ACCESS_OUTBOUND type of
pipe, for instance.
And pass the returned Handle to your "core" code ( substituting a WriteFile
in places where you'd do
your writing to stdout )
Then you can create a worker thread from the main application code that
will, in it's Execute(), call ConnectNamedPipe(), get the pipe's handle",
and call ReadFile() to get your buffer information ( you'll
have to fashion your own sort of loop and controlling mechanism there ).
Once you've gotten a buffer of
information from the pipe, you call Synchronize( X), where X is a function
defined within your thread object that will update your TRichEdit buffer by
appending the newly retrieved data. Of course you'll need to probably pass a
pointer to the TRichEdit within the constructor of this TThread derived
object.
Of course this makes it a bit less than "Cleaner" cross platform coding, but
unless you're doing your streaming
directly to stdout EVERYWHERE ( and I know, console guys have a habit of
doing this ) instead of wrapping them, this shouldn't be too much of a
hassle. If you are doing this, then you could probably do yourself a favor
and
wrap all that within a function call, and then in that function, handle the
differentiation between the standard C++
iostream stuff and using a Windows construct like a named pipe.
Good luck
Quote
Perhaps this question is more appropriate for another group, but you have
brought up something I am very interested.

I would like to follow your approach for a thermodynamic application I am
writing. I am rather new to C++, so excuse my lack of knowledge on this. I
want the core code to spit out some info to the user during some of the
calculations, so I am currently sending output to std::cout. But, when I
go
and implement a GUI, I want this output sent out to a log window, such as
a
TRichEdit.

Using your approach, how can I easily re-direct std::cout to a
TRichEdit?????
I saw a question like this a couple of weeks ago, and the response was 'NO
CAN-DO'. If that is true, how do I re-drect output IF I HAVE FORMAT
FLAGS
in my std::cout code?? It seems here it would be easier to do my original
coding linked to a GUI components like VCL. It seems your approach may be
easier said than done.

Doug


 

Re:Re: Crossroad BCB5 BCB6 CBX MS.NET GCC

Mr. Josuttis's (hope I spelled that right) book, The Standard Template
Library has a basic implementation of an I/O stream wrapping a file handle.
Since the handle of a pipe works the same, I do not think it would be two
hard to wrap that in an I/O stream using the same (mostly) code as the book.
That way, your interface to the pipe would be fairly standard, just the
implementation underneath would be platform specific.
HTH,
Ken
"Doug Tinkham" < XXXX@XXXXX.COM >wrote in message
Quote

Can I use a pipe implementation that is not platform specific??

 

Re:Re: Crossroad BCB5 BCB6 CBX MS.NET GCC

"Doug Tinkham" < XXXX@XXXXX.COM >wrote in message
Quote
Using your approach, how can I easily re-direct std::cout to a
TRichEdit?????
By not using std::cout to begin with. Write the core code to implement
callbacks/events, which the GUI code can then hook into to receive
notfications when appropriate and update the GUI accordingly.
Gambit
 

Re:Re: Crossroad BCB5 BCB6 CBX MS.NET GCC

"Marcelo R. Lopez, Jr." < XXXX@XXXXX.COM >wrote in message
Quote
Doug,

Do you HAVE to output stdout ?
Thanks Marcelo.
No. But, I guess I'm one of those console guys you mentioned (it's so easy).
Quote

You can create the named pipe, strictly as a PIPE_ACCESS_OUTBOUND type of
pipe, for instance.
And pass the returned Handle to your "core" code ( substituting a WriteFile
in places where you'd do
your writing to stdout )
I have not explicitly dealt with pipes before. Looked on BCB6 help. _pipe
appears not to be very portable. But I'll give it a look. This, and the
Synchronize(X) you mention looks good if I was sticking with BCB6.
Can I use a pipe implementation that is not platform specific??
Doug
 

Re:Re: Crossroad BCB5 BCB6 CBX MS.NET GCC

Doug Tinkham < XXXX@XXXXX.COM >wrote:
Quote
[...] I
want the core code to spit out some info to the user during some of the
calculations, so I am currently sending output to std::cout. But, when I go
and implement a GUI, I want this output sent out to a log window, such as a
TRichEdit.

Using your approach, how can I easily re-direct std::cout to a TRichEdit?????
[...]
The key point in this, as I see it, is that
there is some information that you gather
deep within your core code. There, no UI
is known/accessible. (Well, it shouldn't
be, anyway, if you follow my approach.) In
my world, there's only a few parts in the
higher up levels that know about any UI at
all. (And even those don't know how the UI
is implemented.) These parts would have to
decide what to do with that information.
So you need to call back up into higher
code from your core algorithm. I know three
ways to do that: Pass a function pointer,
pass an object as a function parameter at
run-time (which implements an abstract
function -- run-time polymorphy), or pass
an object as a template parameter at compile-
time (known as compile-time polymorphy). For
various reasons I don't use any function
pointers, so that leaves #2 and #3.
The point is, that you don't want to do any
formatting in the low-level routines. They
don't know where the info is going to end
up, so they can't prepare it. What they do
is passing the info on. Up there the info
is prepared and formatted and sent to
wherever it should go.
Does that help?
Quote
Doug
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers org
"And why should I know better by now/When I'm old enough not to?"
Beth Orton
 

Re:Re: Crossroad BCB5 BCB6 CBX MS.NET GCC

"Ken Stapleton" < XXXX@XXXXX.COM >wrote in message
Quote
Mr. Josuttis's (hope I spelled that right) book, The Standard Template
Library has a basic implementation of an I/O stream wrapping a file handle.
Thanks Ken, Ted, Marcelo, Remy.
I have been concentrating on the numerical aspect of my program so far. Your
suggestions should be very helpful in the next stage I'm starting now.
Doug