Board index » cppbuilder » Insights on CBX 1.5

Insights on CBX 1.5


2004-07-09 08:43:40 AM
cppbuilder62
from Babet in the cbx group.
Quote
I share your concern. I'm neither a bean counter nor a survey/statistics
analyzer but my simple lay-programmer's view is that rather than target a
C++ product at a broad market Borland is going at a few select ones. I can
tell you that with the release of 1.5 we (the C++ core group - i.e. R&D, QA,
Docs, Support) expressed concern as to how a product that's focused on
"Series 60 Development" would be perceived at large. We knew how the product
stacked against other Series 60 environment. Our concern was no the target
audience but the others.
 
 

Re:Insights on CBX 1.5

">>Our concern was no the target audience but the others.
That is a little depressing.
 

Re:Insights on CBX 1.5

I R T wrote:
Quote
from Babet in the cbx group.

"From an R&D point of view we have much more today that when
CBuilderX v1.0 shipped: Menu Designers, Data Module support, Code Managers
capable of much more than Delphi or CBuilder, etc."
Hmm. Progress is being made. Slow though.
 

{smallsort}

Re:Insights on CBX 1.5

Michael Harris wrote:
Quote
">>Our concern was no the target audience but the others.

That is a little depressing.
Taken out of context it is, but it isn't really. What Bruneau means is
that they weren't concerned about the target audience because they knew
they were doing a good job for those folks. What was a cause for
concern was, "What about the other people who aren't specifically
targetted by C++BuilderX 1.5?" What should be done about those users?
I think that's probably exactly what people want to hear -- that they
know there's more out there than just Series 60 development and although
CBX 1.5 may not directly address the needs of those users, they haven't
forgotten about those people.
Bruneau went on to explain that even when focusing on a narrow market
segment like Series 60 developers, part of his responsibility is to make
sure that whatever new features are added will translate to a broader
market as well. For example, CodeInsight was added in CBX 1.5 but was
implemented in a way that will allow it to work more generally.
--
Gillmer J. Derge [TeamB]
 

Re:Insights on CBX 1.5

Valence Crearer wrote:
Quote

"From an R&D point of view we have much more today that when
CBuilderX v1.0 shipped: Menu Designers, Data Module support, Code Managers
capable of much more than Delphi or CBuilder, etc."

Hmm. Progress is being made. Slow though.

Yes, but this doesn't indicate whether there is any particular C++ (or
VCL) library on the back-end of these so desktop app developers could
make use of this.
The wx works was mentioned to have been put on hold.
So while CBX can be used by a larger audience than just series 60
developers, it doesn't really inspire you to put the effort in if you
aren't the dedicated target (e.g. problems that don't affect series 60
developers won't get addressed, same as problems that don't affect
delphi didn't get addressed very much for BCB).
Mind you, no problems are being addressed for BCB/CBX 1.0 users anyway
at the moment.
I put quite a bit of effort in to getting our VCL projects building
under CBX and also investigating and starting a couple of projects in wx
using CBX (because it 'appeared' to be the successor to bcb).
I've since cancelled that and am now putting much more effort in to
getting code to build in both BCB and VC++ using VCL and WinForms
respectively which I now thing would have been worth doing back in
October when CBX was announced.
Cheers
Russell
 

Re:Insights on CBX 1.5

Russell Hind wrote:
Quote
Valence Crearer wrote:
>
>"From an R&D point of view we have much more today that when
>CBuilderX v1.0 shipped: Menu Designers, Data Module support, Code Managers
>capable of much more than Delphi or CBuilder, etc."
>
>Hmm. Progress is being made. Slow though.
>

Yes, but this doesn't indicate whether there is any particular C++ (or
VCL) library on the back-end of these so desktop app developers could
make use of this.

The wx works was mentioned to have been put on hold.

Yes, disturbing, but not damning.
Quote
Mind you, no problems are being addressed for BCB/CBX 1.0 users anyway
at the moment.

I put quite a bit of effort in to getting our VCL projects building
under CBX and also investigating and starting a couple of projects in wx
using CBX (because it 'appeared' to be the successor to bcb).

Since I suspected that things would change, check history if you care, I never
budged toward CBX. Sadly, not even my ardor for Borland made me even mildly
motivated to follow their lead on that one. It "felt" wrong from the start.
Although you've no grounds to sue, I understand your apprehension at following
any other purposed directions until sufficient market experience proves it wise.
<redundant>I also am not moving toward VC++.NET as yet, because it does not yet
fit plant floor manufacturing goals.<\redundant>
Quote
I've since cancelled that and am now putting much more effort in to
getting code to build in both BCB and VC++ using VCL and WinForms
respectively which I now think would have been worth doing back in
October when CBX was announced.
The same projects? or legacy vs. new development?
 

Re:Insights on CBX 1.5

Valence Crearer wrote:
Quote


Since I suspected that things would change, check history if you care, I never
budged toward CBX. Sadly, not even my ardor for Borland made me even mildly
motivated to follow their lead on that one. It "felt" wrong from the start.
Although you've no grounds to sue, I understand your apprehension at following
any other purposed directions until sufficient market experience proves it wise.
<redundant>I also am not moving toward VC++.NET as yet, because it does not yet
fit plant floor manufacturing goals.<\redundant>

I was quite happy with wx as we do lab-based instrumentation (size of
PCs to photo-copier sized instruemnts) so we need to be able to put an
easy front-end on to the backend data acquisiton and processing systems.
For now we can keep each project small enough to produce a single exe
which is why we moved to BCB in the first place, C++ back-ends with RAD
front-ends all in one package.
WinForms doesn't seem as 'nice' as VCL and BCB, but isn't far off, and
RAD is probably 20% of what we do, and VC++ gives a better compiler so
it does have some advantages over BCB. And the speed of managed code
suprised me, although I'm still nervous about the GC kicking in during
data acquisition and currently haven't been able to test this yet.
Quote
>I've since cancelled that and am now putting much more effort in to
>getting code to build in both BCB and VC++ using VCL and WinForms
>respectively which I now think would have been worth doing back in
>October when CBX was announced.


The same projects? or legacy vs. new development?

Currently its a new project, but basically implementing a set of
wrappers that give us a common interface to VCL/WinForms controls so all
the logic (both UI and backend) is standard C++ which builds in both BCB
and VCL so have the same app compiling in both and basically use the VCL
designer/WinForms designer as a layout tool.
I'll no in another 3-4 weeks whether it will be worth bringing our
current VCL applications up to date like this or leave them in VCL.
(We finally have another developer starting in October so that will help
a lot! and it certinaly won't be as lonely!)
Cheers
Russell
 

Re:Insights on CBX 1.5

Quote
WinForms doesn't seem as 'nice' as VCL and BCB, but isn't far off, and
RAD is probably 20% of what we do, and VC++ gives a better compiler so
it does have some advantages over BCB. And the speed of managed code
suprised me, although I'm still nervous about the GC kicking in during
data acquisition and currently haven't been able to test this yet.
From what I have read (I am currently reading Jesse Liberty's book) you can
force garbage collection to be performed when you want by using the 'using'
keyword. This forces the garbage collection to kick in when it exits the
closing brace of using. If you enclose all of your aquisition code in using
statments and not exit any of them while in the time critical part then you
will have no problems with garbage collection.
Alternatively you can create a dll in C++ for the aquisition section.
 

Re:Insights on CBX 1.5

Graham Reeds wrote:
Quote
From what I have read (I am currently reading Jesse Liberty's book)
you can force garbage collection to be performed when you want by
using the 'using' keyword.
(I assume that you're talking about the C# using keyword. It means
something really different in C++.)
No. That just means that the object that you're using gets
"disposed." It still exists in the heap. Let's look at an example.
I create and use a file reader. Either my code throws an exception,
or I'm stupid, and the function using it exits, leaving it dangling.
The next time the gc runs, the objects destructor will run, cleaning
up after itself, hopefully.
The next time the gc runs after that, the object will be destroyed.
On the other hand, if you use "using," when the object goes out of
scope, its destructor will be called, immediately. And it'll be
collected at the next gc.
If you want the gc to run, then you simply call System.GC.Collect().
--
Mike Swaim XXXX@XXXXX.COM at home | Quote: "Boingie"^4 Y,W & D
MD Anderson Dept. of Biostatistics & Applied Mathematics
XXXX@XXXXX.COM or XXXX@XXXXX.COM at work
ICBM: 29.763N -95.363W|Disclaimer: Yeah, like I speak for MD Anderson.
 

Re:Insights on CBX 1.5

Graham Reeds wrote:
Quote

From what I have read (I am currently reading Jesse Liberty's book) you can
force garbage collection to be performed when you want by using the 'using'
keyword. This forces the garbage collection to kick in when it exits the
closing brace of using. If you enclose all of your aquisition code in using
statments and not exit any of them while in the time critical part then you
will have no problems with garbage collection.

'using' is for C#. In .Net 2, they are adding the ability of managed
objects to be created on the stack, so you get stack-based clean-up
semantics (internally they are still created on the heap, but finalised
as soon as they go out of scope so behave like C++ objects). 'using'
allows C# to have deterministic finalization as apparently many people
have complained about it. have a look at
msdn.microsoft.com/msdnmag/issues/04/05/visualc2005/default.aspx
You can force GC with a System::GC::Collect method, but that forces a
GC, doesn't stop it from running at certain times.
Quote
Alternatively you can create a dll in C++ for the aquisition section.

Unfortunately, IIUC, this won't help. For GC to work, it has to suspend
all threads in the process so it can 'heap walk' the allocated objects.
Therefore it suspends your threads, even if they aren't using any
managed objects (AFAICT). I'm not yet sure if there is a way to declare
a thread as 'un-managed' so the GC doesn't suspend it when running.
If this is correct, then event a native C++ dll (which I've already
created in VC++ for our acquisition and processing back-end as we have
some python-loving physicists here), its threads will still get
suspended when GC decides to run. If this is correct, then I guess the
next option is a natively compiled service, something that runs in
another process but that is a bit of a daunting problem for the transfer
data. Also what do you do when native images aren't allowed in the OS?
I'm not sure if/when this will ever happen, but it is a possibility.
What I'm looking for is a way to suspend GC from running during our data
acquisition.
Problems with this are:
o someone is reporting threads occasionally swapping out for 600ms
rather than the typical 25-100ms intervals. But people rightly point
out that Win32 isn't a real-time OS so if they want guarantees, then
don't run in windows. I understand it isn't real-time, but I don't want
part of our own process to be suspending our acquisition. We control
what other processes run on the PC, so can limit external effects and
control priorities etc., but we can't control the GC in our own process?
That seems a bit limiting (I'm probably just being scared of GC as
haven't actually looked at effects of this on our code yet, so all this
is hearsay)
o That means no managed object will get deleted during this time.
Objects may have been finished with, but allocating more will lead to
memory usage increasing until you finish acquiring and can force a GC.
I guess all actions such as updating UI and stuff will force small
object allocation in the .net framework and so this could ultimately
become a problem
Cheers
Russell
 

Re:Insights on CBX 1.5

"Russell Hind" < XXXX@XXXXX.COM >wrote in message news: XXXX@XXXXX.COM ...
Quote
Graham Reeds wrote:

You can force GC with a System::GC::Collect method, but that forces a
GC, doesn't stop it from running at certain times.
Itīs recommended not to call that method.
Quote
Unfortunately, IIUC, this won't help. For GC to work, it has to suspend
all threads in the process so it can 'heap walk' the allocated objects.
AFAIK the workstation GC uses a parallel thread for garbage collection,
so at least on a hyperthreading system your native threads should run
parallel.
On a Windows server this might be different.
<copied quotation>
Workstation GC performs collection in parallel with the CLR threads.
Server GC suspends the CLR threads during collection.
<copied quotation>
Cheers
Andre
 

Re:Insights on CBX 1.5

"Andre Kaufmann" <## XXXX@XXXXX.COM ##>wrote in message news:40eee5d4$ XXXX@XXXXX.COM ...
Quote
AFAIK the workstation GC uses a parallel thread for garbage collection,
so at least on a hyperthreading system your native threads should run
parallel.
Additional note:
Thatīs surely true for a non hyperthreading, too.
But the GC thread consumes more processor cycles (scheduling)
from the native threads on single processor systems.
Andre