BCB5 the worst product I have ever used
Sholto Douglas
this version, I have spent all my time wrestling with the illogicalities of
the IDE. I have not spent one minute programming. I have been through the
dreary iteration of deleting projects, re-generating them, and finding the
same problems over and over again. I have reinstalled it twice.
It can't find libraries in paths that are clearly mentioned in the .BPR
project file, or it can't open files or libraries that are nowhere to be
seen in the .BPR or .DFM files, or it can't.... I won't bore you by
continuing.
Normally I work with VC++, and I won't perjure myself by saying MFC is a
great environment, but at least the product does what it says and has not
given me a fraction of the ulcer factor I have suffered at the hands of BCB.
Why has Borland, whose C++ development environment used to smoke
Microsoft's, taken such a giant leap backwards?
I am working in my spare time on a product written in BCB, and am so far
into it now (I started with BCB1) that I can't really back out, much as I
would like to. But I tell anyone else who will listen to avoid it like
dysentery.
Borland should shoot their IDE team. Better still, let me do it.
--
Sholto Douglas
His Nerdship Pty Ltd
Tel: +61 2 9955 8296 (home)
Mobile: 0412 292 169
Email: sho...@alpha.net.au
Matz The Wolf
> Normally I work with VC++, and I won't perjure myself by saying MFC is a
> great environment, but at least the product does what it says and has not
> given me a fraction of the ulcer factor I have suffered at the hands of
BCB.
> Why has Borland, whose C++ development environment used to smoke
> Microsoft's, taken such a giant leap backwards?
Well that depends a lot on what you call improvement. The RAD features of
BCBx
just whipe vc++ up in smokes.
Just my .02$
Matz The Wolf.
Russell Hind
news:8d7669$51...@bornews.borland.com...
> How on earth can Borland put this onto the market? Since "upgrading" to
> this version, I have spent all my time wrestling with the illogicalities
of
> the IDE. I have not spent one minute programming. I have been through
the
> dreary iteration of deleting projects, re-generating them, and finding the
> same problems over and over again. I have reinstalled it twice.
> It can't find libraries in paths that are clearly mentioned in the .BPR
> project file, or it can't open files or libraries that are nowhere to be
> seen in the .BPR or .DFM files, or it can't.... I won't bore you by
> continuing.
>
Most of the IDE problems stem from the fact that the IDE is written for
Delphi which doesn't have these features and as a far simpler language (it
simply has a .pas file, and no .h files etc). Borland seem intent on
leaving the IDE like this and concentrate on Delphi. As BCB becomes a more
widely used product, and more people complain about its Delphi-like ways,
they may actually stop the Delphi team working on it and bring it back to
its former glory days of BC5.02.
As for your actual problems, I have now converted our project that started
in BCB3 to BCB5 without problems. I find it the best IDE yet (I have used
1, 3, 4 and now 5) but still hindered by that fact that it comes from the
Delphi IDE.
> Normally I work with VC++, and I won't perjure myself by saying MFC is a
> great environment, but at least the product does what it says and has not
> given me a fraction of the ulcer factor I have suffered at the hands of
BCB.
> Why has Borland, whose C++ development environment used to smoke
> Microsoft's, taken such a giant leap backwards?
>
It's because they forgot the BC++ IDE and took the delphi one and gave it a
C++ compiler. Stupid mistake. They are now slowly adding features to the
BCB IDE (4 years later) that were present in BC++5. Lets only hope that
either in patches, or in BCB6 they are just about there so it can be classed
as a decent C++ development environment.
> I am working in my spare time on a product written in BCB, and am so far
> into it now (I started with BCB1) that I can't really back out, much as I
> would like to. But I tell anyone else who will listen to avoid it like
> dysentery.
>
I wouldn't have a clue. I agree with you that the IDE is nothing compared
to VC++ (apart from the form designer bit). As I said in a thread on the
IDE group, why didn't they add dcc32 and the form designer and component
palette to the BC++ IDE rather than add bcc32 to the Delphi IDE. Silly
mistake and will take them a long time to bring BCB IDE up to scratch (once
they realise it is actually bad). As they decided to take the Delphi IDE
and use it for C++Builder, they should have at least kept developing Borland
C++ but they obviously decided that RAD was the way to go and no one would
be interested in developing non-gui applications in there projects anymore.
At least they seem to be learning with the integration of CodeGuard into the
IDE.
Russell
Andrue Cope
I can sympathise with you and as a many years confirmed Borland user I am
worried about Builder's future - I just don't see it as a generic C++
development environment unless you resort to the command line compiler and who
the heck wants to do that?
Builder does require that you work the way it wants - but apart from the hassle
you don't seem to benefit from working that way. I suppose Borland will tell us
that there's no other way to implement the level of design/coding integration
that makes Builder such a RAD environment. Personally I don't accept that
but..c'est la vie.
BCB5 is better in some respects than BCB4 but just to add petrol to the
smoldering fire of this thread I'll point out that working with more than about
fifty source files requires increasing levels of patience. We have a 167 file
library which BC5 was quite happy with. We moved it to BCB5 and now there's a
several second pause before compilation starts and half a minute while the CPU
is thrashed whenever we do anything which Builder thinks affects the entire
project. This on a PII-400 with 256MB of RAM.
I am still of the opinion that Builder should only be used for RAD. If it
wasn't for the convenience of having both in the same project group we would
move the library to VC.
BCB6 really, really needs to sort this out because IMHO it is serious problem.
Andrue Cope
[Bicester, UK]
Andrue Cope
I agree with your comments. I'm sure it doesn't have to be this way <s>.
Andrue Cope
[Bicester, UK]
Andreas Koch
Sholto Douglas schrieb:
> It can't find libraries in paths that are clearly mentioned in the .BPR
> project file, or it can't open files or libraries that are nowhere to be
> seen in the .BPR or .DFM files, or it can't.... I won't bore you by
> continuing.
Had similar effect when porting from BCB3 to 5.
I guess porting is the problem, else it works fine and i *LOVE* the IDE.
Oh yes, and open that BRP with a text editor and check it for
garbeled paths. The few additional libraries it wanted where (in my
case)
easily removable from the BRP with find/replace...
Andreas
Andreas Koch
Andrue Cope schrieb:
>
> Sholto,
>
> I can sympathise with you and as a many years confirmed Borland user I am
> worried about Builder's future - I just don't see it as a generic C++
> development environment unless you resort to the command line compiler and who
> the heck wants to do that?
BCB is no C++ compiler. Why should it be? There are more than enough
C-Compilers
out there. BCB is a RAD-Tool which uses the c++ language. Just see it
that
way. It simply is not build to compiler standard c++ code.
Is MS word a basic compiler/interpreter just because it can use VBA ???
Andreas
Edward Diener
> Andrue Cope schrieb:
> >
> > Sholto,
> >
> > I can sympathise with you and as a many years confirmed Borland user I am
> > worried about Builder's future - I just don't see it as a generic C++
> > development environment unless you resort to the command line compiler and who
> > the heck wants to do that?
>
> BCB is no C++ compiler. Why should it be? There are more than enough
> C-Compilers
> out there. BCB is a RAD-Tool which uses the c++ language. Just see it
> that
> way. It simply is not build to compiler standard c++ code.
What an incredibly idiotic statement considering that BCB is one of the most
standard C++ compliant compilers around and much closer to the C++ language standard
than VC++. Why say something like this and what purpose does it serve ? For the life
of me I can not understand someone like you who sees BCB as only a RAD tool. If you
don't want to use BCB to write programs that take advantage of C++, then don't do
it, but don't say something as foolish as your remark above.
Robert F. Tulloch
You MUST be doing something wrong. I had a project in BCB1, moved to
BCB4 then to BCB5 and have had at worst a few minor problems whcih were
easily worked out. Perhaps you should look inward a little more
critically.
Sholto Douglas
important as the RAD component in my decision to write the project in BCB.
There is no such thing as pure RAD, well not in serious projects anyway.
There is always a mass of code/intelligence behind it, and I think I spend
probably 5 hours on this for every 1 hour on the RAD work - thanks largely
to the execellent RAD capabilities of BCB.
But such capabilities count for little when you can't get the project to
build in the first place!
--
regards/mfG,
Sholto Douglas
His Nerdship Pty Ltd
Tel: +61 2 9955 8296 (home)
Mobile: 0412 292 169
Email: sho...@alpha.net.au
Andreas Koch <Koch...@T-Online.de> wrote in message
news:8d7hvg$tt3$2...@news07.btx.dtag.de...
>
>
> Andreas Koch schrieb:
Sholto Douglas
is so user-cuddly, it should AUTOMATICALLY generate projects that work. I
am doing everything as prescribed to create new projects, and sometimes they
work, sometimes they don't. The worst thing is the lack of logic. Doing
the same thing twice never seems to yield the same result.
The error messages are worthless. I have another post on this group about a
fatal linker error I have been getting, that it cannot find GRAPHICS.OBJ.
Well I gather this is inside VCL50.LIB - this file is certainly in the
LIBRARIES and SPARELIBS lines in my .BPR file (<LIBRARIES value="Vclx50.lib
Vcl50.lib"/>). The fact that no one could explain why I am getting this
error supports my argument that the whole project management of BCB is a
mess, and probably one that even the Borland developers themselves don't
understand.
I would have agreed with you up to BCB4 - I had problems migrating to each
upgrade, but I seemed to have them under control within a few days. But
BCB5, heck I bought this over a month ago and I still haven't got it working
properly.
--
regards,
Sholto Douglas
His Nerdship Pty Ltd
Tel: +61 2 9955 8296 (home)
Mobile: 0412 292 169
Email: sho...@alpha.net.au
Robert F. Tulloch <tul...@ibm.net> wrote in message
news:38F80448...@ibm.net...
Sholto Douglas
I agree with you about the RAD. Having worked with MFC for several years, I
chose BCB1 as the tool for a product that I wanted to write in my spare
time. I hoped it would take off in the market, so I could use it in my
regular work. That hasn't happened. Corporate Australia has not exactly
left a trail of trampled bodies in the rush to embrace BCB. So I have been
stuck with MFC in my day jobs.
Where I disagree with you, though, is that a good RAD is sufficient in
itself. If the IDE cannot reliably generate projects that work, the RAD
becomes sort of irrelevant, doesn't it?
--
regards,
Sholto Douglas
His Nerdship Pty Ltd
Tel: +61 2 9955 8296 (home)
Mobile: 0412 292 169
Email: sho...@alpha.net.au
Matz The Wolf <matz_t...@hotmail.com> wrote in message
news:38f724df@dnews...
Sholto Douglas
some more so than others.
My main point is that a product like BCB cannot just rest on one pillar, in
this case the mantra that the RAD is wonderful. Sure I prefer to work with
VCL than MFC, but if the most fundamental part of the product, the IDE and
its project management, is flaky, then it drags the whole product down with
it.
Looking through the release notes accompanying the service packs, they seem
to fix obscure syntax errors in the outer reaches of C++, which hardly
anyone sees, but leave gaping holes in the IDE, which EVERYONE sees.
I was very impressed with BCB1 - it did less, but did it better. Every
subsequent version seemed to do more, but worse.
As I said, I am trying to develop a shareware product in my spare time. I
am less than ecstatic when, after returning home from a demanding day job
(VC++) to a demanding baby, I finally get to switch on the PC at about 9pm
only to be confronted with a series of meaningless error messages to the
effect that a certain library or OBJ file cannot be found, even when perusal
of the BPR file tells me it is there. Messages that even TeamB guys usually
can't decipher. I have never had this many problems with any other such
product, so I cannot be uniquely stupid.
I just wish Borland would nail this down before adding new whiz-bangs.
Andreas Koch
Edward Diener schrieb:
> > Andrue Cope schrieb:
> > I can sympathise with you and as a many years confirmed Borland
user I am
> > > worried about Builder's future - I just don't see it as a generic C++
> > > development environment unless you resort to the command line compiler and who
> > > the heck wants to do that?
> >
> > BCB is no C++ compiler. Why should it be? There are more than enough
> > C-Compilers
> > out there. BCB is a RAD-Tool which uses the c++ language. Just see it
> > that
> > way. It simply is not build to compiler standard c++ code.
>
> What an incredibly idiotic statement considering that BCB is one of the most
> standard C++ compliant compilers around and much closer to the C++ language standard
> than VC++.
Afaik, BCB heavily depends on its self-build headers and declarations,
while VC will
compile "standard" C++ code.
> Why say something like this and what purpose does it serve ? For the life
> of me I can not understand someone like you who sees BCB as only a RAD tool. If you
> don't want to use BCB to write programs that take advantage of C++, then don't do
> it, but don't say something as foolish as your remark above.
You misunderstood me. For me, a RAD tools is a tool to click together a
nice UI,
and THEN use it to build the code.
I did not say that that one should not use C++ inside BCB.
>From Andrue's post i just had the impression that he complains that BCB
is
not perfectly usable to compile "standard" C++ code.
And as far as i know (and all the tests i have read), compiling things
like
a library you got from the net will be much easier with VC, Codewarrior,
GNU C++, etc. BCB is (in my eyes) designed to build BCB-C++ apps, and
not
for generic, portable C++ development.
But i have to say that i am not yet a C++ expert, perhaps the insighst
will
come at a later time....
Andreas
Andreas Koch
Sholto Douglas schrieb:
>
> If I just needed a RAD tool I would use VB.
If VB has a RAD component, i never found it.
Where do i drag my buttons on the form? THATS RAD for me.
> The C++ componenent was as
> important as the RAD component in my decision to write the project in BCB.
You can write your project with BCB. Just don't expect using it to
compile non-BCB projects.
> There is no such thing as pure RAD, well not in serious projects anyway.
> There is always a mass of code/intelligence behind it, and I think I spend
> probably 5 hours on this for every 1 hour on the RAD work - thanks largely
> to the execellent RAD capabilities of BCB.
Hm, maybe i missed some RAD-declaration.
For me, RAD is: clicking together the surface, having basic stuff
declared,
and then code yourself.
> But such capabilities count for little when you can't get the project to
> build in the first place!
Projects startet in BCB tend to compile without problems.
At least for me ;)
Andreas
Bojan Resnik
>Afaik, BCB heavily depends on its self-build headers and declarations,
>while VC will
>compile "standard" C++ code.
So will BCB. I try to make my programs as portable as possible, not only
among different platforms, but also among different compilers. Therefore, I
stick to using ANSI C++ and compile my code in ANSI mode. BCB 4 has compiled
all of the projects I had previously written using GNU C.
Rudy Velthuis
>> If I just needed a RAD tool I would use VB.
>If VB has a RAD component, i never found it.
>Where do i drag my buttons on the form? THATS RAD for me.
Huh? I thought VB was one of the first products for Windows that did
this. Did you mean VC?
>> The C++ componenent was as
>> important as the RAD component in my decision to write the project in BCB.
>You can write your project with BCB. Just don't expect using it to
>compile non-BCB projects.
You can even compile MFC and ATL projects. You can't use MSVC libs or
objects, but neither can MSVC use Borland files. And you can write
perfect ANSI programs in BCB, which is quite impossible in MSVC.
>Hm, maybe i missed some RAD-declaration.
>For me, RAD is: clicking together the surface, having basic stuff
>declared, and then code yourself.
And he means the "code yourself" part, which is the part eating most of
the time anyway.
--
Rudy Velthuis
Edward Diener
> Edward Diener schrieb:
>
> > > Andrue Cope schrieb:
> > > I can sympathise with you and as a many years confirmed Borland
> user I am
> > > > worried about Builder's future - I just don't see it as a generic C++
> > > > development environment unless you resort to the command line compiler and who
> > > > the heck wants to do that?
> > >
> > > BCB is no C++ compiler. Why should it be? There are more than enough
> > > C-Compilers
> > > out there. BCB is a RAD-Tool which uses the c++ language. Just see it
> > > that
> > > way. It simply is not build to compiler standard c++ code.
> >
> > What an incredibly idiotic statement considering that BCB is one of the most
> > standard C++ compliant compilers around and much closer to the C++ language standard
> > than VC++.
> Afaik, BCB heavily depends on its self-build headers and declarations,
> while VC will
> compile "standard" C++ code.
This is nonsense again. There is nothing in BCB that keeps it from compiling standard C++
code. Why do you believe this sort of thing ? There is no dependency in the BCB C++
compiler on any "self-build headers and declarations". I think your viewpoint here is the
product of some sort of propaganda or something which you are buying into without actually
trying features of BCB yourself. You have not presented any specifics that supports this
sort of belief.
> > Why say something like this and what purpose does it serve ? For the life
> > of me I can not understand someone like you who sees BCB as only a RAD tool. If you
> > don't want to use BCB to write programs that take advantage of C++, then don't do
> > it, but don't say something as foolish as your remark above.
>
> You misunderstood me. For me, a RAD tools is a tool to click together a
> nice UI,
> and THEN use it to build the code.
>
> I did not say that that one should not use C++ inside BCB.
Let me repeat it again. You can build console Windows applications, DLLs, and static
libraries that have nothing whatsoever to do with RAD or the Windows GUI with BCB, using
the full power of C++. Try it and you might find out how easy it is to this.
>
> >From Andrue's post i just had the impression that he complains that BCB
> is
> not perfectly usable to compile "standard" C++ code.
> And as far as i know (and all the tests i have read), compiling things
> like
> a library you got from the net will be much easier with VC, Codewarrior,
> GNU C++, etc. BCB is (in my eyes) designed to build BCB-C++ apps, and
> not
> for generic, portable C++ development.
> But i have to say that i am not yet a C++ expert, perhaps the insighst
> will
> come at a later time....
Let me assure you Andreas that BCB can compile standard C++ code. No, it is not 100 %
standard C++ compliant ( there is hardly a C++ compiler on any platform that is yet ), but
it is far beyond the merely adequate stage, and much more standards compliant than VC++.
As far as 3rd party libraries go, many people put out 3rd party libraries for Windows only
for VC++ and the difficulties of using these with BCB has nothing to do with BCB and
everything to do with the both inadequacies of VC++ and the differences of name mangling
and parameter passing between any 2 compilers. Must Borland dumb down their compiler just
to adequately deal with VC++ 3rd party libraries ? Should John Updike write as badly as
John Grisham just so that he can sell more books to the average moron ?
You don't have to be a C++ expert to realize that most of what you are suggesting,
influenced by other posts also, is simply untrue and just unfortunate propaganda about
BCB.
Andreas Koch
> You don't have to be a C++ expert to realize that most of what you are suggesting,
> influenced by other posts also, is simply untrue and just unfortunate propaganda about
> BCB.
Thanks for making this clear.
Most of this ideas come from a C++-Compiler Test in the well known
german computer magazine C't.
They got some C++ code from the web and tried to compile it with
different compilers.
To compile it with BCB (V3 or what was current at this time) they
stated they needed to build the standard BCB structure
(TApplication, etc.) to get it compile.
On the other side, these guys needed hours to find the project
options ;)
Andreas
Andreas Koch
Rudy Velthuis schrieb:
>
> Andreas Koch wrote...
>
> >> If I just needed a RAD tool I would use VB.
>
> >If VB has a RAD component, i never found it.
> >Where do i drag my buttons on the form? THATS RAD for me.
>
> Huh? I thought VB was one of the first products for Windows that did
> this. Did you mean VC?
Argh, sorry... read VB , wrote VB, thought VC :)
Andreas
Robert Low
Like most complex tools, there is a learning curve -- not out of
proportion with the power of the tool, by any means. On the other
hand, just because you can fly a Piper Cub (private aircraft, if you
aren't familiar with it.) doesn't mean you can fly a Harrier Jet. Not
without a lot of familiarization, anyway. From what you said, their
tests tried to by-pass that part of the curve ...
As long as the code is close to standard, BCB can compile it. The way
to interpret this kind of test is: If MSVC can compile it, chances are
-very- good that standards-compliant compilers can't. Unless it's
-really- simple ...
Cheers
Bob
Edward Diener
> > You don't have to be a C++ expert to realize that most of what you are suggesting,
> > influenced by other posts also, is simply untrue and just unfortunate propaganda about
> > BCB.
>
> Thanks for making this clear.
> Most of this ideas come from a C++-Compiler Test in the well known
> german computer magazine C't.
>
> They got some C++ code from the web and tried to compile it with
> different compilers.
>
> To compile it with BCB (V3 or what was current at this time) they
> stated they needed to build the standard BCB structure
> (TApplication, etc.) to get it compile.
> On the other side, these guys needed hours to find the project
> options ;)
For a console application one doesn't need to use the VCL at all. For a Windows application,
which is what it sounds like these people were trying to test, you also don't need the VCL
if you choose Console Wizard, Window Type - GUI, Execution Type - EXE, and leave Include the
Visual Component Library unchecked. This gives you the shell for a straight Windows API
application without the VCL framework. It's obvious that these guys didn't know what they
were doing.
Sholto Douglas
Thanks for that contribution - very valuable. Yes they should have stuck
with the BC++ interface. As it is, they took the wrong interface (Delphi)
and far worse, did it badly! I wouldn't mind if it at least worked.
Do you remember the Style Sheets in BC++? You could just select a new sheet
and the project would be re-built from, say, Debug to Release mode. We now
have the Full Debug and Release buttons, but to really change from one to
another, one has to go into the Project Options and make most of the
required changes manually. For example, I do not want CodeGuard stuff in a
release version. But clicking the Release button does not remove the
CodeGuard dependency. You have to go to the CodeGuard page and de-select
it, and even then the linker still tries to pick it up. I had to go into
the BPR file to set LinkCGLIB=0. Just one example...
To get round this I tried creating two separate projects within the same
group, one Debug and one Release within the same project group. This is
where I had the problem - the Release project worked, but the Debug one
never made it past the linker fence.
As a postscript to these problems, someone suggested I re-install BCB5 with
a full install. Previously I had done a custom install, as I am not using
the BDE and some other features.
I did this this morning, and it seems to have worked. I can now actually
get back to programming and my blood pressure can slowly return to normal.
--
regards,
Sholto Douglas
His Nerdship Pty Ltd
Tel: +61 2 9955 8296 (home)
Mobile: 0412 292 169
Email: sho...@alpha.net.au
Russell Hind <r...@techprt.co.uk> wrote in message news:38f729df@dnews...
Andrue Cope
> From Andrue's post i just had the impression that he complains that BCB
> is
> not perfectly usable to compile "standard" C++ code.
>
No, sorry that wasn't quite my complaint. My complaint is that Builder forces
you to work a certain way and that despite that inflexibility it is still very
slow. As a c++ compiler it is very good - it's the Project Manager which lets
it down. The rest of IDE is okay - though some areas such as Code Sight need to
be faster.
Andrue Cope
[Bicester, UK]
Andrue Cope
> My main point is that a product like BCB cannot just rest on one pillar, in
> this case the mantra that the RAD is wonderful.
>
I think I agree with you there. Builder can do other things but my experience
is that it's a bit of a struggle.
Andrue Cope
[Bicester, UK]
Dirk Schwammkrug
magazine did a comparing 'test' in the fall of '99, where BCB4 was
compared to some other C++ development environments. The conclusions
where kind of misleading, but they stated:
1) To compile some 3rd party lib with the BCB IDE(!) you have
to adjust the project file. They found that a little bit
confusing, but no real harm.
2) The RAD properties of BCB are execellent compared to others,
equally rated with PowerC++/Watcom (never seen that myself)
3) To compile some 3rd party libs with VC++6, they had to adjust
some C++ class declarations(!) that BCB did't complain about.
So much for standard C++ support.
So the essence was not "use BCB only when not coding low-level apps",
but "if you don't need RAD, you can use VC++ also" (of course they did
say some more, but related to this discussion, that's the point).
I think the problem with most of these 'tests' comes from the fact that
if you don't want to (or have to) work with an environment on a regular
basis, motivation for running the learning curve is low, and for BCB
this means not to gather the basics. Having said this I want to finally
state that the article mentioned above was quite good and these guys
normally know what they do.
Cheers,
Dirk
Andreas Koch wrote:
>
> > You don't have to be a C++ expert to realize that most of what you are suggesting,
> > influenced by other posts also, is simply untrue and just unfortunate propaganda about
> > BCB.
>
> Thanks for making this clear.
> Most of this ideas come from a C++-Compiler Test in the well known
> german computer magazine C't.
>
> They got some C++ code from the web and tried to compile it with
> different compilers.
>
> To compile it with BCB (V3 or what was current at this time) they
> stated they needed to build the standard BCB structure
> (TApplication, etc.) to get it compile.
> On the other side, these guys needed hours to find the project
> options ;)
>
> Andreas
--
_________________________________________________
Dirk Schwammkrug
Computer Scientist R & D
Chemspeed Ltd, CH-Augst, http:\\www.chemspeed.com
Phone: (+41)61-8169-640 Fax: [..]-509
Alex Bakaev [TeamB]
Dirk Schwammkrug wrote:
[snip]
> 3) To compile some 3rd party libs with VC++6, they had to adjust
> some C++ class declarations(!) that BCB did't complain about.
> So much for standard C++ support.
>
I'm not sure what the last sentence means. If it's a shot at BCB, then,
most likely, it's wrong.
Alex
JSCIEME
it, I get a dialog that has a "Source Type" group box (C, C++), and a group
that has "Use VCL", "Multi-Threaded", and "Console Application". No mention of
GUI, nor Execution Type. There is also included a "Specify Project Source"
checkbox, and an edit field with a "..." switch. Are we on the same page?
E.D.:
JSCIEME
JSCIEME
That was the =exact same problem= I had migrating (migraine-ing?) from BCB4,
now that you mention it--it all comes back. But as I say, in 10 minutes I had
moved all my source code into the new world, added them to a virgin project and
have not had a whimper from that aspect since.
Gene Gajewski
"Andrue Cope" <not.a...@email.address.sorry> wrote in message
news:VA.0000056...@email.address.sorry...
> Sholto,
>
> > My main point is that a product like BCB cannot just rest on one pillar,
in
> > this case the mantra that the RAD is wonderful.
> >
>
> I think I agree with you there. Builder can do other things but my
experience
> is that it's a bit of a struggle.
Well, judging by the length of this thread - I think Inprise should have
heard by now. C++ programmers are accustomed to much more sophisted
build tools than your average Pascal programmers. Regardless of the
architecture of the IDE - I think that if Inprise concentrates on the
hard-core C/C++ crowd (been here since TC 1.5), the Pascal people will be
more than happy. We've got higher expectations. Excepting Linux/Gnu folks of
course - the more arcane, the better... :)
Steve Carpenter
Steve Carpenter
Michael Lockey
Gene Gajewski wrote:
>
> ... We've got higher expectations. Excepting Linux/Gnu folks of
> course - the more arcane, the better... :)
Kylix is coming...
--
Michael Lockey
director, Hartlepool Systems International
Edward Diener
Application and uncheck Use VCL once you start the Console Wizard and you have a
straight Windows API application without the VCL framework. As I said, it's
obvious that these guys didn't know what they were doing.
Leo Siefert
- Leo
Matz The Wolf
> Where I disagree with you, though, is that a good RAD is sufficient in
> itself. If the IDE cannot reliably generate projects that work, the RAD
> becomes sort of irrelevant, doesn't it?
Well. I dont remember saying that bcb whas perfect. I just said that its
quite usable.
I hate bcb's ide to. Theres absolutly nothing in that ide that i feel proud
to have.
VC++ and even vb have better more stable ide's.
But bcb is a usable product. The ide is still stable. I mean I've used bcb
for almost 3 years now and
I did deliver a lot of apps with it. And every time even if I had some weird
ide behavior I did manage
to get the job done faster then in vc++.
And the IDE CAN reliably generate projects that work. Do you think that
everyone here are crazy guys who type all day code in bcb that they wil
never finish ? ;-)
Matz The Wolf.
Steve Carpenter
Edward Diener <eddi...@abraxis.com> wrote in message
news:38FBE355...@abraxis.com...
pdo...@flash.net
upgrading my current project from BCB3 to 5. The .BPR file referenced
older libraries. Fixed it pretty easily and have had no problems
since. And using CodeGuard found a bug instantly for me. So, I'm a
happy BCB 5 user.
There are things that I don't like about the IDE myself. And I
suspect that if Borland sold as many copes of BCB as MS sells of VC,
they would have enough money to invest in it. Overall, it is, at
least for my purposes, the best C++ product. Could be better. Wish
it were better. But still the best overall.
Sholto Douglas
news:38fe0e71@dnews...
>
> And the IDE CAN reliably generate projects that work. Do you think that
> everyone here are crazy guys who type all day code in bcb that they wil
> never finish ? ;-)
>
> Matz The Wolf.
>
>
Sure it CAN produce projects that work, but it should ALWAYS do this. The
fact that one sometimes has to go to extreme lengths achieve this (I had to
uninstall/reinstall BCB5 three times) suggests that Borland put this on the
market without putting it through the required testing.
Most of the postings in this thread suggest that I am not alone in the
problems I have experienced.
A friend in the US described it as like the profile of a wave - you start
from a low point when a new version comes along, but as you get used to it
and the projects mysteriously start working, you really get to love it.
This nirvana state grows till the next version hits the market, at which
point we start the cycle again....
Matz The Wolf
> fact that one sometimes has to go to extreme lengths achieve this (I had
to
> uninstall/reinstall BCB5 three times) suggests that Borland put this on
the
> market without putting it through the required testing.
> Most of the postings in this thread suggest that I am not alone in the
> problems I have experienced.
Ok. I'll give that one to you. But really do you know of any company that
does'nt do this nowadays ?
> A friend in the US described it as like the profile of a wave - you start
> from a low point when a new version comes along, but as you get used to it
> and the projects mysteriously start working, you really get to love it.
> This nirvana state grows till the next version hits the market, at which
> point we start the cycle again....
As with any other dev product out there.
Its not borland that hasd to change. Its the entire market.
--
Matz The Wolf.
<pas de signature>
a merde s'en est une....
oublier ca j'ai pas de signature.....
ARGGGG
Remy Lebeau
> Ok. I'll give that one to you. But really do you know of any company that
> does'nt do this nowadays ?
How about companies that DO the required testing, but don't act upon the
results. Allaire is a perfect example. They use Delphi to produce
Homesite, what USED TO BE the best HTML editor for the Windows platform.
They have open-access forums where hndreds of testers participate in
extensive testing, and the Allaire staff is also active in these forums,
listening to people problems/suggestions/etc. YET, Homesite is now the
buggiest program anyone has ever seen, they truely screwed up with their
latest release since the program is bloated, slow, and many bugs that have
been around for several versions still go unfixed including SEVERE resource
mismanagement, memory leaks and the like.
Gambit
Matz The Wolf
Remy Lebeau <gamb...@gte.net> wrote in message
news:8en2g7$13...@bornews.borland.com...
I guess you proved my point !
Robert F. Tulloch
I must interject here. You are really full of it. I went from BCB1 to
4 to 5. Everything I did always worked well. A few minor problems with
IDE (access violations on closing) due most likely to some third party
components or ones I wrote or ones I got to work which were for some
early version of Delphi. I consider these problems mine and since I
don't want to deal with it right now, I live with it.
I've looked at your posting and the rantings and all I can say is that
you are screwing something up, not Borland. I used to think the same
thing until it was pointed out over and over that the problems were of
my own making or my misunderstanding something, without exception. It's
real easy to screw something up it you don't understand it. As easy as
it is to use, it does take some in depth understanding.
Lighten up.
Best regards
Sholto Douglas
woe similar to mine suggest that I am not alone in my experiences. You are
right - myself and the others probably did do something wrong, but WHAT?
After all, how CAN one screw up the creation of a project? The IDE does it
all for you (or rather it should).
In my case these were projects that worked fine under BCB4.
You had no problems migrating to BCB5. I am very happy for you. But I
think the average tone of the replies suggests that you were lucky.
--
regards,
Sholto Douglas
His Nerdship Pty Ltd
Tel: +61 2 9955 8296 (home)
Mobile: 0412 292 169
Email: sho...@alpha.net.au
Robert F. Tulloch <tul...@ibm.net> wrote in message
news:3910CA9C...@ibm.net...
Jerry Bloomfield (TeamB)
wrote:
>In my case these were projects that worked fine under BCB4.
Did you read the entire documentation on "What's new" and "Upgrading
from..."? If not it is possible that you overlooked an obvious "gotcha"
that Borland went to the effort of documenting to help others avoid. There
are other issues which could possible indicate why a BCB v4 project might
not work properly under BCB v5. Things like: Third Party components,
Changes in the compiler to support more of the ISO/ANSI C++ Standard,
changes in the internal project file formatting, ...
>You had no problems migrating to BCB5. I am very happy for you. But I
>think the average tone of the replies suggests that you were lucky.
He might have been, but then, I would have to have been lucky too, as I
have not had any problem converting projects to BCB v5 either... I would
wager a guess that the "luck" you refer to is related to the specific
features and capabilities of the tools which everyone is using. If there
is a feature which hampers the way I want to use the tool, then that is
very significant to me, but if it is in an area of the tool which I seldom
(if ever) use, then it is relatively insignificant to me. I suspect this
is closer to the case in this situation.
Jerry Bloomfield (TeamB)
--
http://www.teamb.com Jers...@wwa.com
Please do *NOT* send private e-mail without prior permission (my anti-spam
filters will probably just delete it anyway <g>)
Jan Knepper
Don't worry, be Kneppie!
Jan
Matz The Wolf wrote:
> > Normally I work with VC++, and I won't perjure myself by saying MFC is a
> > great environment, but at least the product does what it says and has not
> > given me a fraction of the ulcer factor I have suffered at the hands of
> BCB.
> > Why has Borland, whose C++ development environment used to smoke
> > Microsoft's, taken such a giant leap backwards?
>
> Well that depends a lot on what you call improvement. The RAD features of
> BCBx
> just whipe vc++ up in smokes.
>
> Just my .02$
>
> Matz The Wolf.
--
===============================================================
Jan Knepper
Smartsoft, LLC
88 Petersburg Road
Petersburg, NJ 08270
U.S.A.
Phone: 609-628-4260
FAX : 609-628-1267
http://www.smartsoft.cc/
---------------------------------------------------------------
http://www.pianoprincess.com/
http://www.mp3.com/pianoprincess
http://www.riffage.com/Bands/0,2939,2859,00.html
http://pianoprincess.iuma.com/
http://www.changemusic.com/piano_princess
===============================================================
Jan Knepper
> >
> > Where I disagree with you, though, is that a good RAD is sufficient in
> > itself. If the IDE cannot reliably generate projects that work, the RAD
> > becomes sort of irrelevant, doesn't it?
>
> Well. I dont remember saying that bcb whas perfect. I just said that its
> quite usable.
Not if the IDE changes an include path I just entered as: "\app\win" and an
other as "\app" to "app\win" and "app"
THIS MAKES A PRODUCT COMPLETELY UNUSABLE!!!
> I hate bcb's ide to. Theres absolutly nothing in that ide that i feel proud
> to have.
> VC++ and even vb have better more stable ide's.
Borland C++ 5.02's IDE was better!
> But bcb is a usable product. The ide is still stable. I mean I've used bcb
> for almost 3 years now and
> I did deliver a lot of apps with it. And every time even if I had some weird
> ide behavior I did manage
> to get the job done faster then in vc++.
You CAN NOT call a IDE stable when it all by itself changes include paths, lib
paths etc, etc, etc!
Those are the BASICS of compilation. No one, but the programmer should DEFINE
those!
> And the IDE CAN reliably generate projects that work. Do you think that
> everyone here are crazy guys who type all day code in bcb that they wil
> never finish ? ;-)
I highly doubt that any one here works on project of any serious size completely
in BCB. Sorry...
Don't worry, be Kneppie!
Jan
--
Jan Knepper
> I must interject here. You are really full of it. I went from BCB1 to
> 4 to 5. Everything I did always worked well. A few minor problems with
> IDE (access violations on closing) due most likely to some third party
> components or ones I wrote or ones I got to work which were for some
> early version of Delphi. I consider these problems mine and since I
> don't want to deal with it right now, I live with it.
I really wonder how big your largest project is.
> I've looked at your posting and the rantings and all I can say is that
> you are screwing something up, not Borland. I used to think the same
> thing until it was pointed out over and over that the problems were of
> my own making or my misunderstanding something, without exception. It's
> real easy to screw something up it you don't understand it. As easy as
> it is to use, it does take some in depth understanding.
Nop!
Just create a new project, let the the IDE do it al and try to change the
include paths in a decent way.
When you recall them directly as I just did... YES I REALLY MEAN CLOSING THE
"OPTIONS" DIALOG AND OPENING IT AGAIN!!! You probably will see you include path
changed. Try something like "\app\win;\app;", even with the "Ordered list of
include paths" is changes right away to "app\win" and "app". Something like this
should NEVER happen.
Jan Knepper
> The fact that the majority of replies to this posting have added tales of
> woe similar to mine suggest that I am not alone in my experiences. You are
> right - myself and the others probably did do something wrong, but WHAT?
> After all, how CAN one screw up the creation of a project? The IDE does it
> all for you (or rather it should).
> In my case these were projects that worked fine under BCB4.
You did not do anything wrong!
One of the things that certainly annoys me most is the PATH stupidity.
There is nothing wrong you can do there. The system just changes the input after
it has been committed.
I mean what is still all about... Handling a couple of string in C or C++!!!!
If Borland is not able to implement something simple like that I highly doubt
how correctly the generated code is the compiler generates.
I guess it is doing the same thing there, just changing lines around...
> > Lighten up.
What would you do when you bought a car that had a stearing wheel working in
reverse...
I don't think you would lighten up!
Jan Knepper
> is a feature which hampers the way I want to use the tool, then that is
> very significant to me, but if it is in an area of the tool which I seldom
> (if ever) use, then it is relatively insignificant to me. I suspect this
> is closer to the case in this situation.
INCLUDE path's is not something the tool very seldom uses...
It is MAJOR and one of the basics in compilation.
Jan Knepper
> Most of the IDE problems stem from the fact that the IDE is written for
> Delphi which doesn't have these features and as a far simpler language (it
> simply has a .pas file, and no .h files etc). Borland seem intent on
> leaving the IDE like this and concentrate on Delphi. As BCB becomes a more
> widely used product, and more people complain about its Delphi-like ways,
> they may actually stop the Delphi team working on it and bring it back to
> its former glory days of BC5.02.
That would be cool! But then only if a IDE generated .EXE would be the exact
same as .EXE generated via a MAKEFILE generated from the IDE.
> As for your actual problems, I have now converted our project that started
> in BCB3 to BCB5 without problems. I find it the best IDE yet (I have used
> 1, 3, 4 and now 5) but still hindered by that fact that it comes from the
> Delphi IDE.
Sure, but Symantec had a great IDDE 5 years ago! With out any problem near as
serious as the Borland IDE have ever had!
> It's because they forgot the BC++ IDE and took the delphi one and gave it a
> C++ compiler. Stupid mistake. They are now slowly adding features to the
> BCB IDE (4 years later) that were present in BC++5. Lets only hope that
> either in patches, or in BCB6 they are just about there so it can be classed
> as a decent C++ development environment.
I sure hope so.
Jan Knepper
> BCB5 is better in some respects than BCB4 but just to add petrol to the
> smoldering fire of this thread I'll point out that working with more than about
> fifty source files requires increasing levels of patience. We have a 167 file
> library which BC5 was quite happy with. We moved it to BCB5 and now there's a
> several second pause before compilation starts and half a minute while the CPU
> is thrashed whenever we do anything which Builder thinks affects the entire
> project. This on a PII-400 with 256MB of RAM.
Ho! Ho! Ho! Ho!
This is so cool!
Here more kerosine on the fire!
Running a Dual PIII 733 with 256 MB ram...
The project manager window is a joke, especially after a compilation when all the
dependency stick underneath the source files.
Try to spead search a file by typing it's name in the project manager... Takes
forever!!!!
> I am still of the opinion that Builder should only be used for RAD. If it
> wasn't for the convenience of having both in the same project group we would
> move the library to VC.
>
> BCB6 really, really needs to sort this out because IMHO it is serious problem.
Agreed!
Jan Knepper
> Andrue Cope schrieb:
> >
> > Sholto,
> >
> > I can sympathise with you and as a many years confirmed Borland user I am
> > worried about Builder's future - I just don't see it as a generic C++
> > development environment unless you resort to the command line compiler and who
> > the heck wants to do that?
>
> BCB is no C++ compiler. Why should it be? There are more than enough
> C-Compilers
> out there. BCB is a RAD-Tool which uses the c++ language. Just see it
> that
> way. It simply is not build to compiler standard c++ code.
Sorry, the name is "Borland C++ Builder" which clearly states that it uses C++ to
build something right?
So, BCB might be RAD-Tool, that uses a C++ compiler as MAJOR component.
I think it is about time that this MAJOR component is being supported right.
> Is MS word a basic compiler/interpreter just because it can use VBA ???
No, but Visual Basic *is* (Sorry, you should not take things out of context!)
That is an RAD-Tool using a Basic Compiler/Interpreter... Does a MUCH better job
than BCB for C++.
Jan Knepper
> standard C++ compliant ( there is hardly a C++ compiler on any platform that is yet ), but
> it is far beyond the merely adequate stage, and much more standards compliant than VC++.
AMEN!
> As far as 3rd party libraries go, many people put out 3rd party libraries for Windows only
> for VC++ and the difficulties of using these with BCB has nothing to do with BCB and
> everything to do with the both inadequacies of VC++ and the differences of name mangling
> and parameter passing between any 2 compilers.
Yes!
Eventhough I use BCB to develop with MFC and MFC 3rd Party Libraries...
You won't believe what the guys at Dundas http://www.dundas.com/ think of me for finding all
those problems in their MFC libraries! Just because I compiled with a different compiler!
> Must Borland dumb down their compiler just to adequately deal with VC++ 3rd party libraries
> ? Should John Updike write as badly as John Grisham just so that he can sell more books to
> the average moron ?
No!
Dont' worry, be Kneppie!
Robert F. Tulloch
> > > Lighten up.
>
> What would you do when you bought a car that had a stearing wheel working in
> reverse...
> I don't think you would lighten up!
I bought the car and when I turned the wheel right, it went right.
Listen, I don't mean to hassle you or make this sound trivial but there
has to be some basic thing you have done incorrectly. There are sooooo
many posts here. Did you post an exact description of what happens and
the make file? I had to do a lot of make file clean up in one project
due to some components (mine-mostly and third party-Async Pro) to get
things to work right. I wasn't difficult but it took a little while to
understand what was going wrong. I had written the component in delphi,
rolled it into BCB1 then to BCB4 then to BCB5. But really, that was it.
I did have to change some stuff due to oldcreateorder (quick and simple)
but I can't remember if that was BCB1->BCB4 or BCB4->BCB5??
I did figure all this out after finding a bunch of screwy stuff in
the make file.
Best regards
Robert F. Tulloch
> I highly doubt that any one here works on project of any serious size completely
> in BCB. Sorry...
And why do you doubt that? Do you assume we are all tiny project
amateurs because we are using BCB? If that is the reason I would offer
that your problems may be due to a very narrow way of looking at the
world.
best regards
Jan Knepper
> > What would you do when you bought a car that had a stearing wheel working in
> > reverse...
> > I don't think you would lighten up!
>
> I bought the car and when I turned the wheel right, it went right.
I don't think you know... Sometimes your car doesn't exactly go right...
> Listen, I don't mean to hassle you or make this sound trivial but there
> has to be some basic thing you have done incorrectly.
Nop! Nothing. Don't talk to me like I don't know how the IDE works.
It's plain and simple.
- Click with the right mouse button on the .EXE in the project manager.
- Select "Options..."
- Select "Directories/Conditionals"
- Click on the button Next to the combobox for Include Path.
- Add an include path like "\app\win"
- Add an include path like "\app"
- Click "OK" to close the dialog.
- Click "OK" to close the "Project Options" dialog.
- Click with the right mouse button on the same .EXE in the project manager.
- Select "Options..."
- Select "Directories/Conditionals"
- Click on the button Next to the combobox for Include Path.
Check for the two include path's you just added.
they most likely appear like
"app\win" and "app"
This is what I mean, BASIC stuff that is not working!
> There are sooooo
> many posts here. Did you post an exact description of what happens and
> the make file? I had to do a lot of make file clean up in one project
> due to some components (mine-mostly and third party-Async Pro) to get
> things to work right. I wasn't difficult but it took a little while to
> understand what was going wrong. I had written the component in delphi,
> rolled it into BCB1 then to BCB4 then to BCB5. But really, that was it.
> I did have to change some stuff due to oldcreateorder (quick and simple)
> but I can't remember if that was BCB1->BCB4 or BCB4->BCB5??
>
> I did figure all this out after finding a bunch of screwy stuff in
> the make file.
Has nothing to do with it!
A good Tool should not "cause" something that would "cause" screwy stuff in a make
file.
Read what you are writing yourself!
Don't worry, be Kneppie!
Jan Knepper
> > I highly doubt that any one here works on project of any serious size completely
> > in BCB. Sorry...
>
> And why do you doubt that? Do you assume we are all tiny project
> amateurs because we are using BCB?
Simple... What would you use for a tiny project???
Windows API, just a standard include...
3-10 .c/.cpp files + .h/.hpp files in the same directory?
No way (for one) you are going to run into the path stupidity I have been fighting
since BCB 1
Try a bigger project.
- 500+ .cpp files.
- .cpp files spread over different directories because they are part of different
systems.
- .h/.hpp files in different directories than the .cpp files, a base/src
base/include construction.
- couple of 3rd party libraries in different directories and different drives.
See how well BCB behaves with include paths,lib paths, project management etc.
> If that is the reason I would offer that your problems may be due to a very narrow
> way of looking at the
> world.
Narrow way of looking at the world!
Boy you easy insult people don't you?
My vision on this world is so narrow that eventhough I have always liked Borland C++.
Have been using it since TC 1.0 (do you have that record?) I know the IDE has serious
problems and I do state them.
The fact that you may be don't experience them does not mean that there are no
problem. There are several users experiencing serious problems with the IDE and what
you do is telling them they probably do something wrong. Well, forget it, the IDE is
doing things wrong. And sometimes behaving in a very unreliable and unpredictable way.
Just try the little example I gave you in the other message and see what it does for
you and realize that when it does it as I wrote what kind of consequences it has.
Robert F. Tulloch
Well I guess I can't match 500 .cpp files but I can't imagine a
project that large.
This one has 55, lib in diff. dir. etc etc. Work fine.
<?xml version='1.0' encoding='us-ascii' ?>
<!-- C++Builder XML Project -->
<PROJECT>
<MACROS>
<VERSION value="BCB.05.03"/>
<PROJECT value="LTDMSA.exe"/>
<OBJFILES value="RichEdit\ReConst.obj LTDMSA.obj TenantData.obj
Adver.obj AdverSU.obj
AppDateForm.obj Assoc.obj AssocId.obj Budget.obj BudgetSU.obj
CalcProgress.obj CreateNewMessage.obj Depreciation.obj
eMailSelect.obj
FLib.obj FMaint.obj Info.obj InvoiceMessage.obj LTAdminDM.obj
LTAdverDM.obj LTAssocDM.obj LTBudgetDM.obj LTBudgetGraph.obj
LTeMailDM.obj
LTInfoDM.obj LTMain.obj LTMainSetUp.obj LTMiscDM.obj LTNlDM.obj
LTRasDM.obj LTReportsDM.obj LTStatusMessages.obj NewMemDlg.obj
NonDocShellFunctions.obj OrgSU.obj PrintFormBase.obj
ReportQueryTest.obj
ReportSelectDate.obj SelectAdType.obj SelectInvoiceDate.obj
Admin.obj
AddressBk\ldifform.obj AddressBk\AdrBk.obj RichEdit\Rich.obj
IBAdminDm.obj
IBAdmin.obj RDialer.obj LTMainDM.obj FindPropertyOwner.obj
ThreadDM.obj
IBLogon.obj IBTableView.obj IBTableOpen.obj SelectTRGRev.obj
RichEdit\TRGCoverEdit.obj"/>
<RESFILES value="LTDMSA.res"/>
<IDLFILES value=""/>
<DEFFILE value=""/>
<RESDEPEN value="$(RESFILES) TenantData.dfm Adver.dfm AdverSU.dfm
AppDateForm.dfm Assoc.dfm
AssocId.dfm Budget.dfm BudgetSU.dfm CalcProgress.dfm
CreateNewMessage.dfm
Depreciation.dfm eMailSelect.dfm FMaint.dfm Info.dfm
InvoiceMessage.dfm
LTAdminDM.dfm LTAdverDM.dfm LTAssocDM.dfm LTBudgetDM.dfm
LTBudgetGraph.dfm
LTeMailDM.dfm LTInfoDM.dfm LTMain.dfm LTMainSetUp.dfm LTMiscDM.dfm
LTNlDM.dfm LTRasDM.dfm LTReportsDM.dfm LTStatusMessages.dfm
NewMemDlg.dfm
OrgSU.dfm PrintFormBase.dfm ReportQueryTest.dfm
ReportSelectDate.dfm
SelectAdType.dfm SelectInvoiceDate.dfm Admin.dfm
AddressBk\ldifform.dfm
AddressBk\AdrBk.dfm RichEdit\Rich.dfm IBAdminDm.dfm IBAdmin.dfm
RDialer.dfm LTMainDM.dfm FindPropertyOwner.dfm ThreadDM.dfm
IBLogon.dfm
IBTableView.dfm IBTableOpen.dfm SelectTRGRev.dfm
RichEdit\TRGCoverEdit.dfm"/>
<LIBFILES value=""/>
<LIBRARIES value="VCLIB50.lib ibsmp50.lib dclocx50.lib teeui50.lib
vcldbx50.lib vcljpg50.lib
nmfast50.lib Email3.lib bcbsmp50.lib DCLUSR50.lib vclx50.lib
vclbde50.lib
vcldb50.lib qrpt50.lib tee50.lib teedb50.lib vcl50.lib"/>
<SPARELIBS value="vcl50.lib teedb50.lib tee50.lib qrpt50.lib
vcldb50.lib vclbde50.lib
vclx50.lib DCLUSR50.lib bcbsmp50.lib Email3.lib nmfast50.lib
vcljpg50.lib
vcldbx50.lib teeui50.lib dclocx50.lib ibsmp50.lib VCLIB50.lib"/>
<PACKAGES value="vcl50.bpi vclx50.bpi vcljpg50.bpi vcldb50.bpi
vclbde50.bpi qrpt50.bpi
bcbsmp50.bpi DCLUSR50.bpi Email3.bpi"/>
<PATHCPP value=".;AddressBk;RichEdit"/>
<PATHPAS value=".;RichEdit"/>
<PATHRC value=".;"/>
<PATHASM value=".;"/>
<DEBUGLIBPATH value="$(BCB)\lib\debug"/>
<RELEASELIBPATH value="$(BCB)\lib\release"/>
<LINKER value="ilink32"/>
<USERDEFINES value="_DEBUG"/>
<SYSDEFINES value="NO_STRICT"/>
<MAINSOURCE value="LTDMSA.cpp"/>
<INCLUDEPATH
value="$(BCB)\Projects\TaeRE30;Images;RichEdit;"G:\Program
Files\Borland\CBuilder5\Bin\";"g:\program
files\Borland\CBuilder5\Imports\dfsstatusbar\";$(BCB)\include;$(BCB)\include\vcl;"G:\Program
Files\Borland\CBuilder5\Imports\DBTrans\";"G:\Program
Files\Borland\CBuilder5\Imports\TEMail\";"G:\Program
Files\AsyncPro\";"G:\Program Files\Seagate Software\Crystal
Reports\vcl\BCB4\7vclB451\";AddressBk"/>
<LIBPATH
value="$(BCB)\Projects\TaeRE30;Images;RichEdit;"g:\program
files\Borland\CBuilder5\Imports\dfsstatusbar\";$(BCB)\Projects\Lib;$(BCB)\lib\obj;$(BCB)\lib;"G:\Program
Files\Borland\CBuilder5\Imports\DBTrans\";"G:\Program
Files\AsyncPro\";"G:\Program Files\Seagate Software\Crystal
Reports\vcl\BCB4\7vclB451\";TEMail;AddressBk;"G:\Program
Files\Borland\CBuilder5\Bin\""/>
<WARNINGS value="-w-par -w-8027 -w-8026"/>
<WARNOPTSTR value=""/>
</MACROS>
<OPTIONS>
<CFLAG1 value="-Od -H=I:\LTDMSA\DMS_APCHeaders.csm -Hc -Vx -Ve -xp
-X- -r- -a8 -4 -b- -k
-y -v -vi- -c -tW -tWM"/>
<PFLAGS value="-$YD -$W -$O- -v -JPHNE -M"/>
<RFLAGS value=""/>
<AFLAGS value="/mx /w2 /zi /z"/>
<LFLAGS value="-D"" -aa -Tpe -x -Gn -v"/>
</OPTIONS>
<LINKER>
<ALLOBJ value="c0w32.obj sysinit.obj $(OBJFILES)"/>
<ALLRES value="$(RESFILES)"/>
<ALLLIB value="$(LIBFILES) $(LIBRARIES) import32.lib cp32mt.lib"/>
</LINKER>
<IDEOPTIONS>
[Version Info]
IncludeVerInfo=1
AutoIncBuild=0
MajorVer=0
MinorVer=1
Release=0
Build=0
Debug=1
PreRelease=0
Special=0
Private=0
DLL=0
Locale=1033
CodePage=1252
[Version Info Keys]
CompanyName=CHF Ltd.
FileDescription=Landlord Association Member Manager
FileVersion=0.1.0.0
InternalName=LTDBM_A
LegalCopyright=
LegalTrademarks=
OriginalFilename=LTDBM_A
ProductName=LTDatabaseManagement
ProductVersion=1.0.0.0
Comments=
Jan Knepper
> Well I guess I can't match 500 .cpp files but I can't imagine a
> project that large.
> This one has 55, lib in diff. dir. etc etc. Work fine.
55 is about a quarter of the project I am talking about that has the problems.
This is .cpp files only. I am not counting resources, forms or anything like that.
I have looked through .bpg and .bpr files a zillion times and have the sincere impression that it get's in trouble
once it reaches a certain amount.
I have looked again through mine and it does not look that different compared to yours except that it is quite a bit
larger in the <OBJFILES= /> section.
Still linkage gives trouble for just one file appearantly not being included when linked from the IDE. It is being
included when linked from an exported MAKEFILE though.
Next to that, the path problem still persists.
Did you ever try the example I gave?
Andy Stroebel
I used VC++ 6 before I started to use the C++Builder - so I have to say,
that C++Builder cannot be the worst product!
But compared with Borland's Delphi 5 f.e. I can understand the arguments.
Now I will buy Watcomm C++ and I hope, that this is better than the
C++Builder - there are to many bugs in it...
Cu,
Andy
Robert F. Tulloch
Point me to the example: Date of posting or something.
Jan Knepper
Have used it for years.
Not much to gain there except pain.
Besides that... The product has been discontinued...
Don't worry, be Kneppie!
Jan
Andy Stroebel wrote:
--
Jan Knepper
You certainly are a friendly sort. Come on.Thank you... I realize I am not...
I am too UPSET about this behaviour of the IDE that has been in there for years eventhough I reported it a couple of times to Borland. Next to that the other HOURS I spend yesterday and today (and quite a few days in the past) compiling a program I just turn ballistic as soon as I think about this IDE.
I did READ. I don't know what your IDE looks like but using an existing project which has Includes listed, you CAN'T type anything in the box and add it because it will overwrite the highlighted item which appear in the box. You DID NOT say to start a new project with nothing in it.No it won't! That's what I mean, either you have a different IDE or you in deed don't read...
As soon as you have the dialog: "Directories" open:
You can type something in the EditBox right underneath the ListBox.
As soon as you type anything the "Add" and "Replace" button will be enabled and you can do either...
"Add" what you just typed to the list or "Replace" the current selection in the list with what you just typed.
Now try to "Add"
\app\win
and
\app
And follow the procedure as given before.
If that is what you mean and then type in what you suggested, whatDoesn't really matter because the IDE is doing weird things with it anyways and since the IDE does not check the existence of an entered path what would you care?
is the point of doing that since \app\win and \app are nothing.
If that is what you are suggesting, sure I will try it. Why don't you try it with a real path pulled up from the browse and tell me that doesn't work.\app\win and \app are real paths on my system.
Good luck!
Jan
> READ!!!
>
> You did NOT follow the steps as I wrote them!
>
> You browsed and selected I:\LTDMSA\DeBug.
> Where did I write to do that?Where did you suggest otherwise. That is how the add works!!!!!!!
> Nop! Nothing. Don't talk to me like I don't know how the IDE works.
>
> The paths don't have to be there since BCB5 does not check that anyways.
>
> Jan
>
I am not trying to give you a hard time. I am trying to understand
your problem. As I said in an earlier post, lighten up a little.Best regards
Jan Knepper
> I deleted and recreated new project.
>
> Test
> Test\app
> Test\app\win
>
> Put *.cpp's in each dir then opened the Project | Options |
> Directories/Conditions | Include Path
>
> and lo and behold-take a look at the attached *.bmp. See!!!!!! Works perfectly.
Sorry, You gotta be joking!
\app and
\app\win
are two directories on my system than contain shared sources and headers.
These sources and headers are selectively used by over 30 products for which the
directories are in
\JW\ORS\SRC\TXT
\JW\ORS\SRC\WIN
\SHOP0\SRC\OFFICE\TXT
\SHOP0\SRC\OFFICE\WIN
\SHOP1\SRC\CASH\TXT
\SHOP2\SRC\CASH\WIN
etc.
"Project" are placed in
BCB4, BCB5 or BCB directories underneath the mentioned directories as:
\JW\ORS\SRC\WIN\BCB5\ORS.bpg
and
\SHOP0\SRC\OFFICE\WIN\BCB5\Office.bpg
Next to \app and \app\win there are quite a few other directories like that I won't
bother you with.
Needless to say... When I am in a directory
\JW\ORS\SRC\WIN\BCB5
Where I work on a project and need to include files from "\app\win" and "\app" I can
not have the IDE change my include paths to "app\win" and "app" as if that is the
same.
Needless to say, moving the mentioned directories would be out of the questions since
they are used by over 30 projects...
Using a drive letter before the first \ is also a problem since different people are
working on the project with different drive mappings. Some work on P:, some work on Q:
others work on C:. The directory structure is ALWAYS the same though.
To make a long story short.
We *NEED* an include path like \app\win, there just no simple way around it. (At
least, not as far as I can see) As it turns out the IDE appearantly is not able to
handle that which makes it rather unusable for us. Consequently this means that
Borland C++ Builder bought only once will remain bought only once and end up on a
shelve since it is unusable because of this may be in your opinion minor problem. (or
no problem).
Don't get me wrong. I appreciate that you are trying to help, but I feel a strong
denial of a problem the IDE really does have. It might now be that serious to you, but
reading the number of posts on the newsgroup, it certainly has had the attention of
quite a few users. It is not a matter of doing something wrong as you stated in
reply's on the newsgroup. It is a matter of something the IDE should not do by itself.
I mean:
#include <sys/stat.h> is different than #include </sys/stat.h>
The IDE should treat path's the same way and not "change" them around as if the user
does not know what (s)he is doing.
Enjoy!
Jan
Erik Zeek
I added an \app, \app\win, and \temp directory to my includes and library
paths. The paths were unchanged even after closing and reopening the
options dialog, closing and reopening the project, or rebuilding the
project. (This is a little disturbing since the first two directories don't
exists. I'ld like a warning.)
This was a very small project, but I would find it odd if it was affected by
the size of the project.
Just my $.02 worth.
Erik
P.S. Jan, have you tried adding the drive to your path specifications, i.e.
C:\app and C:\app\win.
Jan Knepper
> After all the posts I was curious, so I tested my IDE (BCB 5.0 Pro).
>
> I added an \app, \app\win, and \temp directory to my includes and library
> paths. The paths were unchanged even after closing and reopening the
> options dialog, closing and reopening the project, or rebuilding the
> project. (This is a little disturbing since the first two directories don't
> exists. I'ld like a warning.)
Yeah, that is one thing... The warning that isn't there when you would expect
it.
How exactly did you add \app and \app\win?
I just typed it in the box and clicked "Add". Once I close and reopen the
Options dialog it has been changed to "app" and "app\win"
Robert F. Tulloch mailto:tul...@ibm.net tried it too, in an offline
conversation and was able to replicate the problem.
Now we are in a dicussion whether or not \app\win should be taken from the root
of the current drive or not.
I think the definition of that is rather clear.
\app\win *is* from the root of te current "drive" as where "app\win" is from the
current (working) directory.
> This was a very small project, but I would find it odd if it was affected by
> the size of the project.
So would I, but I have seens strange things happening around 200 .cpp files.
> P.S. Jan, have you tried adding the drive to your path specifications, i.e.
> C:\app and C:\app\win.
Yes, but that does not work since the projects are used by several users that do
not all work on the same drive...
Don't worry, be Kneppie!
Erik Zeek
"Jan Knepper" <j...@smartsoft.cc> wrote in message
news:391DFB8E...@smartsoft.cc...
> How exactly did you add \app and \app\win?
> I just typed it in the box and clicked "Add". Once I close and reopen the
> Options dialog it has been changed to "app" and "app\win"
> Robert F. Tulloch mailto:tul...@ibm.net tried it too, in an offline
> conversation and was able to replicate the problem.
>
That's exactly what I did, and no change.
I'll double check... <Restarting Builder> They're still there (\Temp, \app,
and \app\win).
I'm running under Win98 SE. What platform(s) are you using?
Another suggestion: Have you tried using subst to give a drive designation
to the directory. All your team members could then have the files installed
in different physical locations.
Erik
Jerry Bloomfield (TeamB)
>INCLUDE path's is not something the tool very seldom uses...
>It is MAJOR and one of the basics in compilation.
What problems are you experiencing with the Include path?
I do not have any problems with it finding include files properly... I
have added several additional directories to my include path and the
compiler seems to be able to locate include files in each of them just
fine...
Jan Knepper
> "Jan Knepper" <j...@smartsoft.cc> wrote in message
> news:391DFB8E...@smartsoft.cc...
> > How exactly did you add \app and \app\win?
> > I just typed it in the box and clicked "Add". Once I close and reopen the
> > Options dialog it has been changed to "app" and "app\win"
> > Robert F. Tulloch mailto:tul...@ibm.net tried it too, in an offline
> > conversation and was able to replicate the problem.
> >
>
> That's exactly what I did, and no change.
>
> I'll double check... <Restarting Builder> They're still there (\Temp, \app,
> and \app\win).
>
> I'm running under Win98 SE. What platform(s) are you using?
Windows 2000 Professional.
The different is though that you say you added \Temp, \app and \app\win to both,
the include path and the library path. That is an other thing I don't like a bit
in BCB. I just need it in the include path, not in the library path...
It could be that it does nothing with it if they are entered in both. I have
never tried that since I think that in nonsence. There are no .LIB nor .OBJ
files in those directories, so why have the linker search for them in a place
where they aren't?
> Another suggestion: Have you tried using subst to give a drive designation
> to the directory. All your team members could then have the files installed
> in different physical locations.
Are you kidding me?
I have adviced people many times to do so. However, my "team members" live all
over the world, have their own equipment and more than often have drives already
mapped to (different) network drives or subst to other local drives.
BCB IDE just *never* should change an entered path. Automatic paths is an other
thing that is unacceptable.
Jan Knepper
days...
Do a search for j...@smartsoft.cc through the newsgroup and you will find some
great and arrogant comments.
Don't worry, be Kneppie!
Jan
"Jerry Bloomfield (TeamB)" wrote:
--
Martin Fensome
include or lib directories, it changed it to a path relative to the BCB
install folder.
If I included the full drive letter to the path, it kept the path as I
entered it.
Martin
> \app and
> \app\win
Jan Knepper
WHY????
WHY????
WHY????
does BCB5 change an include path entered like that?
Don't worry, be Kneppie!
Jan
Martin Fensome wrote:
--
Martin Fensome
so it does what you want.
I've never been fond of relative paths, but I suppose people brighter than
me have found ways to make use of them.
I haven't, so I never use them.
Martin
Jan Knepper <j...@smartsoft.cc> wrote in message
news:391F445E...@smartsoft.cc...
Jan Knepper
> OK it shouldn't - but who cares - as long as you know how to enter the path
> so it does what you want.
If it should not we all should care.
I mean you don't want the compiler to make i++; into i--; right?
Of course you could do i += 1; instead, but than (talking IDE wise) there is
always a risc it changes that to i -=1;
So, I do care that the IDE is doing things is should. For reliability behaviour
of the IDE should be predictable and right now it is not!
The worst thing is... It can not even be turned off!
That, next to the fact that it automaticly "adds" paths as it is compiling makes
it all together a very dangerous product.
> I've never been fond of relative paths, but I suppose people brighter than me
> have found ways to make use of them.
Relative paths are great, especially if you have to move stuff around. As long
as you move the complete directory structure everything is still being found
because of the use of a relative path.
> I haven't, so I never use them.
Well, good for you...
There are quite a few people that do use them and get a lot of trouble with them
just because BCB thinks it knows things better...
Don't worry, be Kneppie!
Jan
Andrue Cope
> I've never been fond of relative paths, but I suppose people brighter than
> me have found ways to make use of them.
>
They're great if there's any possibility of users moving application data files
into a different directory. The mistake Borland have made is that their paths
are relative to the current working directory which is a moving target.
What they should do (and what we do in our application suite) is make them
relative to a known "base file". In Builder's case it would make sense to
generate paths which are relative to the BPR file.
FWIW you may find that UNC paths are not modified. This certainly works for the
output directory which is the real PITA in BCB4. Format of a UNC path is:
\\<machine name>\<drive name>\<path from root>
Andrue Cope
[Bicester, UK]
Jan Knepper
> Martin,
>
> > I've never been fond of relative paths, but I suppose people brighter than
> > me have found ways to make use of them.
> >
>
> They're great if there's any possibility of users moving application data files
> into a different directory. The mistake Borland have made is that their paths
> are relative to the current working directory which is a moving target.
Yup! Agreed!
> What they should do (and what we do in our application suite) is make them
> relative to a known "base file". In Builder's case it would make sense to
> generate paths which are relative to the BPR file.
Certainly!
That's also how it used to be in the Borland C++ IDE's as far as I know.
> FWIW you may find that UNC paths are not modified. This certainly works for the
> output directory which is the real PITA in BCB4. Format of a UNC path is:
>
> \\<machine name>\<drive name>\<path from root>
Yes, but that is more or less the same as an absolute path with drive letter.
More so, when a project is being moved between machines as we do rather often the
trouble is major!
An other cute thing is what somebody called "the automatic paths" that the IDE adds
to the include path and lib path... I have been in trouble with those quite a few
times and there is just no reason why the IDE should add automatic paths.
Erik Zeek
I checked the path the next day and it had changed to ..\\app and
..\\app\win. I had done some testing of controls with the project, so I'm
not sure exactly when it changed.
Erik
Jan Knepper
this make it very difficult to use a product like BCB to the full extend. I mean
you never know what it changes next all by itself without any permission or
question.
Don't worry, be Kneppie!
Jan
Erik Zeek wrote:
--
Alex Bakaev
posted in HTML, which are both against the newsgroups rules on Borland
news servers.
Alex [TeamB]
Jan Knepper wrote:
[snip]
Alex Bakaev
Jan Knepper wrote:
>
[snip]> Yeah, that is one thing... The warning that isn't there when you
would expect
> it.
Why would you expect a warning? Is there any compiler that does give it
to you?
.a
Alex Bakaev
Andy Stroebel wrote:
>
[snip]
Alex Bakaev
Jan Knepper wrote:
[snip]
>
> BCB IDE just *never* should change an entered path. Automatic paths is an other
> thing that is unacceptable.
>
What version are you using? I think BCB5 changed in this area ( BCB4 did
change paths )
.a
Jan Knepper
YES! Actually there is an IDE that gives it to me. Still my favorite one too!
Compiles faster than Borland C++ and produces smaller and faster code at the
same time. Backside... It is not up-to-date with the latest C++ standards...
Don't worry, be Kneppie!
Jan
--
Jan Knepper
> Jan Knepper wrote:
> [snip]
> >
> > BCB IDE just *never* should change an entered path. Automatic paths is an other
> > thing that is unacceptable.
> >
>
> What version are you using? I think BCB5 changed in this area ( BCB4 did
> change paths )
> .a
Borland C++ Builder Professional 5.0 Build 12.34
And no, BCB5 also changes paths and automaticly adds paths...
Or am I missing a "setup" option?
Alex Bakaev
Jan Knepper wrote:
[snip]
Jan Knepper
Symantec C++ V7.5...
Unfortunately has been discontinued by Symantec about 2 years ago... Even if
version 7.5 ever would be released was questionable...
Still a great product though.
Last version was of January 1997... Which of course means... Not much Active-X
stuff yet and not compatible with MFC 6.0, but 4.21 (5.0) works great with it.
Only the last Borland C++ compiler (5.5) comes close to the code generation...
If you want a copy, just for the heck of it, send me you mailing address...
Don't worry, be Kneppie!
Jan
Alex Bakaev wrote:
--
Edward Diener
> Martin Fensome wrote:
>
> > I've never been fond of relative paths, but I suppose people brighter than me
> > have found ways to make use of them.
>
> Relative paths are great, especially if you have to move stuff around. As long
> as you move the complete directory structure everything is still being found
> because of the use of a relative path.
I agree.
It really is a weakness in BCB that one doesn't have a way for telling the IDE to
set relative paths or absolute paths in all cases. It seems as if the IDE sometimes
sets relative paths and sometimes sets absolute paths, depending on the path that
the user enters for something, but there seems to be no clear cut way of figuring
out how to force the IDE to respect the path that you enter, or to change your path
to a relative or an absolute one each time. BCB5 does seem much better in this
regard than previous versions but I believe it still occasionally changes the path
that a user may enter using some undocumented algorithm for deciding whether or not
to use a relative or absolute path. For BCB5 someone suggested that entering a path
with a drive letter enforces an absolute path but otherwise a relative path is
always created. I can't verify whether or not this is true in all cases.
Alex Bakaev
people could use it. It's nick name is GPFs R Us. As far as code
generation - what a joke! Just to make sure you know what I'm talking
about, BCC55 code generation hasn't really changed in a few years. So
your claim seems to be somewhat under suspicion. Its only claim to fame
is the optlink that could compress the executable.
.a
Jan Knepper wrote:
[snip]
Jan Knepper
7.5 IDDE hardly ever GPF's (at least not half as often as BCB5).
7.5 Does not fiddle with include or lib paths (as BCB5 still does). Even gives a
warning if you provide a path that does not exist! BCB5 still being a major joke
in this area.
When adding files (.cpp's, or others) to a project, the 7.5 IDDE at least does
not show any files already being in the project. BCB5 here still a joke.
Sorting the files in the project manager in 7.5 works great. Files can be sorted
on name, extension, path (directory) date, time. BCB5 again being a joke. Files
on sort on name only, a rather clear indication that it was never build with
large projects in mind.
Searching for a file in the program manager of 7.5 is easy, just type the name
and it jumps right to the position. Even if dependency information is being
displayed. BCB5 again begin a joke and "locking" up my computer (Dual PIII 733
for 10 seconds or more). I have to disable generation of dependency information
to make this work. Needless to say, getting a headerfile right away is a problem
because they are not being displayed in the program manager!
Fixation of the position of the several windows is no problem in 7.5. In BCB5
the Messages window never keeps position and being rather annoying.
7.5 compiles the exact same code fully optimized more than twice as fast as any
Borland C++ compiler. (5.5 being the first exception).
As of today an executable generated by 7.5 is still 10-15% smaller than an
executable generated from the exact same code by BCB5. I won't even talk about
the code size of BCB4 and earlier version.
Weird enough, the several programs I test "performance of generated code" with,
still run faster when compiled with 7.5... Borland C++ 5.5 made an improvement
though.
Needless to add... An .EXE generated from the BCB5 IDE mostlikely is going to be
different than an .EXE generated via a MAKEFILE exported from the BCB5 IDE. This
itself is scary. You know, how can this be? Supposedly the same compiler and
linker generating different code? This being scary goes even as far as the fact
that one of the .EXE's might run fine and the other might GPF at a point even
before the first line of code! Have run into this situation quite a few times.
SC 7.5 however creates the exact same output from the IDDE and from the MAKEFILE
created by the IDDE.
I don't know if you *ever* measured the time a compilation took, but there is a
great improvement from BCB4 to BCB5. Besides that the code being generated
(.EXE) is al to sudden a lot smaller than it used to be. Next to that... I have
quite a few files BCB4 won't even compile where BCB5 does seem to do a better
job.
So, Mr "you know what you are talking about", I know (!) because I have tried!
Just two days ago what I am talking about. Besides that, I actually do have
"recent" experience of working with both ID(D)E's. SC's 7.5 and BCB's 5.0. So
recent that they both are running right now! Sorry, you lose!
From what you tell me I wonder if you ever really worked with Symantec 7.5 or
even 7.21... I think the version you remember is 6.x...
Of course, now you are going to make a list with reasons why BCB should be a
clear winner. Don't forget that you would have to compare SC 7.5 IDDE and
compiler in time with BCB1 or 3 (I don't think there ever was a 2). Or even
better Borland C++ V5.02 which I think was even released after SC 7.5. Comparing
SC 7.5 with BCB 5.0 on all the additional things concering Active-X etc, etc,
etc. Would be comparing apples and pears. BCB 5.0 has been released 3 years
after SC 7.5 and is still having a lot of trouble in area's where a product like
BCB 5.0 should be rock solid. I can honestly tell you SC 7.5 *is* rock solid in
all these area's. Sorry, Borland loses!
The only problem I am facing is the fact that SC has been discontinued a long
time ago. As far as I can see, BCC is the *only* decent replacement for it (just
talking command line compiler and linker). The IDE is a joke. I mean what does
it help if I can import an Active-X control, but the IDE will change paths the
way described? Or... I have to export a makefile, close the project and link on
the command line?
I also have tried M$ VC--. Which of course is a complete joke. What makes that
product a little better is using the Intel C/C++ compiler. With some code
tweaking I could get things compiled at least, where the M$ compiler only knew
how to say "INTERNAL COMPILER ERROR".
CodeWarrior, an other joke...
Watcom C++, discontinued.
KAI C++... Seems to compile things Intel C/C++ does not compile because of their
"compatibility" with M$ VC--. However they are on their first approach making a
Win32 compiler. I have not even tried to compile MFC with it.
I am still concidering whether or not I should try IBM VisualAge C++. Looked at
their website, but no word about any MFC support...
For now I am strongly considering writing a very simple and lite IDE that just
will do project management, compilation and linking, but VERY reliable. BCB's
IDE is just too unreliable. Has been for years dispite all the flack about it in
the forums and the bug reports submitted. Borland gives me the very strong
impression that they don't care... I really wonder whether or not
Borland/Inprise uses the IDE "inside" or not. If they would these problems
mentioned a zillion times would have been fixed a long time ago...
Don't worry, be Kneppie!
Jan
--
===============================================================
Jan Knepper
Smartsoft, LLC
88 Petersburg Road
Petersburg, NJ 08270
U.S.A.
Phone: 609-628-4260
FAX : 609-628-1267
http://www.smartsoft.cc/
===============================================================
Anduin Withers
to be
> different than an .EXE generated via a MAKEFILE exported from the BCB5
IDE. This
> itself is scary. You know, how can this be? Supposedly the same compiler
and
> linker generating different code? This being scary goes even as far as the
fact
> that one of the .EXE's might run fine and the other might GPF at a point
even
> before the first line of code! Have run into this situation quite a few
times.
I haven't seen anyone prove this. There are differences in the .objs but
they are not in the code/data they are in the extra information which tells
us the location of dependants. The compiler and linker used in the IDE are
virtually identical to their command line cousins. They differ only in
non-important ways (like interface code for the DLLs).
--
Anduin Withers
Borland
Jan Knepper
Steps:
* Started the IDE.
* Reloaded the project.
* Compiled the .exe from the program manager window.
* Exported the makefile.
* Closed the IDE
* Went to the command prompt.
* Moved all the "state" files: .OBJ's etc.
* Started make on the makefile.
* Compiled the .exe again.
...
Compared the .EXE's with FC... You won't believe the differences!!!
Of course part of the difference could be because of .OBJ and .LIB being
included in the link phase in a different order, but why would that happen
between IDE generation and MAKEFILE generation if the MAKEFILE was exported from
the IDE?
Next I compared the .OBJ's... <grin> What a joke...
Also, since I had a ton of trouble with a file Registry.cpp in the project that
was being compiled, but not being included in the link phase of the IDE while it
was being included in the link phase from an IDE generated MAKEFILE I guess it
is beyond proven that the IDE, including compiler and linker do different things
than the command line counter parts.
Also, why would there be extra info in the .OBJ when the IDE and makefile are
supposed to use the same compiler switches? In my project I do not generate
dependency information...
This would mean that a project partially generated with the IDE and partially
compiled on the command line could/would be trouble some...
I guess you better check into what it really being passed to the compiler from
the IDE.
I've got a 11,348,513 bytes precompiled header file. The size is 14336 bytes
different between IDE generation and MAKE generation. Contents *never* can be
the same. So what is happening between IDE and makefile?
Not the same output is being generated which has to result in different .EXE's
being generated.
That was simple to prove... Sorry...
Don't worry, be Kneppie!
Jan
> I haven't seen anyone prove this. There are differences in the .objs but
> they are not in the code/data they are in the extra information which tells
> us the location of dependants. The compiler and linker used in the IDE are
> virtually identical to their command line cousins. They differ only in
> non-important ways (like interface code for the DLLs).
>
> --
> Anduin Withers
> Borland
--
Anduin Withers
Ok let's:
There is a difference in the timestamp of course, there is also a slight
difference in the .idata section, and some time stamps are different in the
.rsrc section. There are exactly zero code or data differences.
As for the differences in the objs... do a tdump -h on the .objs, this will
give you a hex listing. Now run fc /b on the two .objs and pipe the output
to a file. Open both hex dumps and the differences. Seek to each one and
note that the difference is in the path to a file not in any generated code.
So yes as I said in my original post there are some differences, they are
path or time stamp related and they are definitely not in code or data
sections.
--
Anduin Withers
Borland
Anduin Withers
.OBJ's
> or .CSM's generated via the IDE or via a MAKEFILE exported from the IDE
except
> time stamps.
The changes are minor and caused by a difference of how the compiler is
invoked and what the current directory is. You can achieve the same .obj
files you just have to modify the .mak file to be less general and hardcode
paths. There is no practical reason anyone would want to do this.
My only point in helping you dig into this was to resolve your claim that
the builds were different, when in fact, they are not (at least not in any
meaningful, or more importantly, harmful, way).
> However, what about *any* of the other things reported in the earlier
> message(s). It's fun to get side tracked by something, but there are some
rather
> serious problems with the IDE being addressed here and all we do is
discuss
> something that is not really a problem.
The path problem... it is a problem (I was able to easily reproduce it). The
meaning is drastically changed in that it removes the first backslash. It
was worse in BCB 4 but the problem certainly isn't entirely resolved in BCB
5.
As for the suggestion to warn about directories which don't exist, I
disagree and generally hate this sort of hand-holding as it is rarely done
right and really isn't that useful if everything else is functioning.
As for other IDE issues... I'm sorry I can't really be that much help other
than to submit bugs which have already been submitted by you it appears.
--
Anduin Withers
Borland
Jan Knepper
with my time.
I however do question the fact that there would be any difference between .OBJ's
or .CSM's generated via the IDE or via a MAKEFILE exported from the IDE except
time stamps.
However, what about *any* of the other things reported in the earlier
message(s). It's fun to get side tracked by something, but there are some rather
serious problems with the IDE being addressed here and all we do is discuss
something that is not really a problem.
Now let's get some answers and commitments on the several things reported!
Don't worry, be Kneppie!
Jan
Anduin Withers wrote:
--
===============================================================
Jan Knepper
Smartsoft, LLC
88 Petersburg Road
Petersburg, NJ 08270
U.S.A.
Phone: 609-628-4260
FAX : 609-628-1267
Andrue Cope
What irritates me is the link time of Builder. As long as you precompile
headers the speed difference between Builder and pre-Builder compilers is quite
small but the link times - yuk. The 16-bit version of our main library is
linked by BC4.5 in under three seconds. Builder takes fifteen seconds for the
32-bit version. Until recently the code was almost identical.
Andrue Cope
[Bicester, UK]
Jan Knepper
> > I however do question the fact that there would be any difference between
> .OBJ's
> > or .CSM's generated via the IDE or via a MAKEFILE exported from the IDE
> except
> > time stamps.
>
> The changes are minor and caused by a difference of how the compiler is
> invoked and what the current directory is. You can achieve the same .obj
> files you just have to modify the .mak file to be less general and hardcode
> paths. There is no practical reason anyone would want to do this.
>
> My only point in helping you dig into this was to resolve your claim that
> the builds were different, when in fact, they are not (at least not in any
> meaningful, or more importantly, harmful, way).
Agreed.
> > However, what about *any* of the other things reported in the earlier
> > message(s). It's fun to get side tracked by something, but there are some
> rather
> > serious problems with the IDE being addressed here and all we do is
> discuss
> > something that is not really a problem.
>
> The path problem... it is a problem (I was able to easily reproduce it). The
> meaning is drastically changed in that it removes the first backslash. It was
> worse in BCB 4 but the problem certainly isn't entirely resolved in BCB 5.
Thanks!
Hope fully we will soon see a path to resolve this. Even a "checkbox" in the
Options Dialog to switch the "intelligence" or whatever it is off would be
enough.
I mean "take the path the way it is provided by the user" is the way it should
work IMHO. The IDE should not touch or change it. Just treat is as "readonly"
and use it that way. If there is a part missing, too bad! That is what error
messages are for! That's user's responsability.
> As for the suggestion to warn about directories which don't exist, I disagree
> and generally hate this sort of hand-holding as it is rarely done right and
> really isn't that useful if everything else is functioning.
Don't really need it. This in fact is minor in my opinion while the path
problem:
1. Changing of paths provided by the user.
2. Automatic adding of directories where sources remain as include path.
3. Adding the include path to the lib/source path.
4. Adding the source/lib path to the include path.
is MAJOR!
> As for other IDE issues... I'm sorry I can't really be that much help other
> than to submit bugs which have already been submitted by you it appears.
Well, if Borland is really out to resolve such things, make sure somebody that
would be able to check into this gets in touch with me. I am more than willing
to spend time to help find and resolve problem. I just *hate* to get the feeling
of being ignored or being send from pillar to post as I have felt the last
period of time.
Being a software developer myself it is sometimes very easy to build some kind
of TRACE logging into a compiler/IDE component and do a temporary replacement of
that component with the component that dumps a TRACE log. But hey, you know that
yourself as well. All I want to say is I still have a couple of other I think
rather serious IDE issue's that need attention and I do think it would be great
if they would be resolved sometime soon.
Don't worry, be Kneppie!
Jan
--
===============================================================
Jan Knepper
Smartsoft, LLC
88 Petersburg Road
Petersburg, NJ 08270
U.S.A.
Phone: 609-628-4260
FAX : 609-628-1267
Jan Knepper
Hmmm, I seem to remember that 5.02 compiled faster than any of the "Builders".
Especially Builder 4 was a real drag. Builder 5 seems to be back on track though.
What you might want to look into (if you didn't already) for the 32-bits links is
the libraries the linker pulls in per default. The Win16 API is rather limited and
because of that the libraries are small and easy to handle. With the 32 bits API
that is a different story. Besides that the API is much larger, the number of
libraries involved it growing and growing. With a bit of bad luck the linker loads
about 60% of them which of course takes time.
brianhei...@northwesternmutual.com
upgraded to BCB5 from BCB3 and now compiling large projects is
painfully slow. I suspect it has to do with the include path. We
store our source and header files in several different subdirectories
on a network, so the include path is somewhat long. As an experiment,
I moved all source and header files to a single directory on my
harddrive. I put this directory and the $(BCB) directories at the top
of the include path. The build time was still slow. If I removed all
the other directories (except the $(BCB) directories), the speed
increased drastically--between 50 and 75 percent. This is odd since
all my code was in the first directory. As I added directories to the
path the speed decreased, even though the new directories contained
none of my code.
In article <392109F9...@smartsoft.cc>,
Sent via Deja.com http://www.deja.com/
Before you buy.