Good News?
Max Headroom
First, the letter is good news. And thanks to Paul and all those who
took the fight to Borland's door. However, as I have thought about it,
there seem to be nagging questions in the background. These questions
suggest that the future of BCB programming (BCBP for this discussion, as
opposed to BCB the product)is not assured. If BCBP in BDS is released,
it is possible that few will use it and the BDB community will continue
to dissolve. How this will play out will be mostly dependent on what
Borland does over the next few months. Will they continue to be
secretive and make vague statements?
Has anyone bothered to tell Borland's marketing department about this
letter? Take a quick look at the Borland web site. Can you find BCB?
It is just a footnote on the CBX page!!! Also the C++ pages of bdn are
still adorned with two open letters from JP LaBlonc. These letters are
filled with the astonishing misconceptions that have brought us to this
point of disaster, as well as company policies that have changed many
times since. It is not a secret that these are just two of the many
subtle ways that Borland has been trying to EOL BCB for the past two
years. If it is not a secret to us, it is not a secret to our customers
either. If Borland wants to save BCBP in BDS, and there are many
reasons why they should want to do this, it can not be accomplished
while they are still sending out the subtle signs that they want to kill
BCB. I believe that for BCBP to survive in BDS, Borland should TODAY
institute a complete turnaround in the marketing of BCB6. Every
customer brought to BCB6 today will be a loyal customer of BDS in the
future. More importantly, it will stop some of the mass exidus in the
existng BCB user base.
What do you think?
Max Headroom
>>These questions suggest that the future of BCB programming (BCBP
>>for this discussion, as opposed to BCB the product)is not assured.
>
Because it takes more than a good product to make a product successful.
It also takes good product management and good marketing. With BCB,
Borland has failed disgracefully in these. I would say this (above)
because I want to remind everyone interested in the success of BCBP that
there is more to this than just an open letter. We can not just walk
away from Dec 14 and assume that Borland will step up to the plate and
fallow through on all fronts. History suggests otherwise. Borland has
to make some changes in how it values this product. Those changes would
be reflected in Borland's long-term behavior. Then, perhaps, there will
be a successful product.
>>If BCBP in BDS is released, it is possible that few will use it and the
>>BDB community will continue to dissolve.
>
> I think it will be quite the opposite - C++ in BDS will revitalize the C++
> VCL marketplace. It has been neglected for a long time, and now is making a
> major comeback.
You think it will be the oppisite. I only hope it will be the oppisite.
I am not going to assume.
Since when is a 5 paragraph announcement a "major comeback?"
>>If Borland wants to save BCBP in BDS, and there are many reasons why
>>they should want to do this, it can not be accomplished while they are
>>still sending out the subtle signs that they want to kill BCB.
>
> BCB as a product is dead. BCBP is living on in BDS. Do not confuse the
> two.
>
No, BCB as a product WILL die. BCBP WILL live on in BDS. (according to
promise)
I don't see any why BCB6 should not die, but until BDS is here, BCB6 is
all we have. Would it not benefit BCBP and BDS if BCB6 made a marketing
last minute sprint to the finish line? Imagine a special: "Buy BCB6 now
on borland.com at full price and receive a 75% discount on BDS within 14
months." Maby 85%!!
Borland has to do more than just release a letter, they need to turn the
ship around.
Remy Lebeau (TeamB)
"Max Headroom" <Max@dont[send[me[nospam.com> wrote in message
news:41c09ea4$1...@newsgroups.borland.com...
> Since when is a 5 paragraph announcement a "major comeback?"
When the product being announced is getting a major overhaul.
Gambit
Digby Millikan
Chris Uzdavinis
> Why is Delphi so successfull, I thought C++ was the most popular
> language?
You're comparing apples to oranges. There is only one vendor for the
Delphi language, but many vendors for C++. Borland can have a bigger
success with a less popular language because they have the whole
Delphi market, but only a small slice of the C++ "pie".
--
Chris (TeamB);
Paul Dolen
"So successful" seems to be an overstatement, it sells enough to seem
to be profitable, but it still lags way behind VS. Why does it
outsell C++ Builder might be a more appropriate question. Well, I
would say for one reason is that Pascal is a closer fit for the VCL,
given that the VCL *is* Pascal. So, for VCL development, Delphi seems
to be the more natural choice.
Of course you can use C++ Builder for apps other than VCL apps. And
it does seem strange to me how virtually everybody is on the MS
bandwagon. I remember the days when everybody used Borland C++. I
don't really understand what happened there.
John Kaster (Borland)
> "So successful" seems to be an overstatement, it sells enough to seem
> to be profitable, but it still lags way behind VS.
Are you talking about market share? Certainly. Technology wise, it has
always been ahead, except for the rare leapfrogging.
--
John Kaster http://blogs.borland.com/johnk
Features and bugs: http://qc.borland.com
Get source: http://cc.borland.com
What's going on? http://calendar.borland.com
Paul Dolen
>Delphi language, but many vendors for C++.
Well, there are some other Object Pascal vendors, though not many. And
there's not all that many serious C++ vendors in the Windows
environment anymore. So I don't think your answer is really accurate.
But I think the other guy's question really was more like, "why does
Delphi outsell C++ Builder?"
Max Headroom
>>Why is Delphi so successfull, I thought C++ was the most popular
>>language?
>
>
> You're comparing apples to oranges. There is only one vendor for the
> Delphi language, but many vendors for C++. Borland can have a bigger
> success with a less popular language because they have the whole
> Delphi market, but only a small slice of the C++ "pie".
>
This goes to a very good reason why Borland might want to add C++ and
other personalities to Delphi. It may be the only way left to get new
Delphi customers. (We run the risk here of getting our a**es flamed by
the Pascalites for speaking such herisy!) I doubt that anyone comming
from a M$ environment such as VC6 would choose to invest in Pascal.
Back in the last century, I was progeramming in ASM and MBasic. I
needed to start in Windows and the choices were Delphi or BCB. Either
way, I would have to learn a new language. I choose BCB over Delphi
strictly on the basis of what appeared to be the future of the two
languages. All of Borland's antics aside, choosing C++ over Pascal
still seems to have been the correct choice.
Actually, the success of Delphi was not the result of a choice of
language. It was because Delphi set a new stancard for RAD. This
standard has not been matched by any other vender or product, except BCB.
Greg Chicares
>
> Of course you can use C++ Builder for apps other than VCL apps. And
> it does seem strange to me how virtually everybody is on the MS
> bandwagon. I remember the days when everybody used Borland C++. I
> don't really understand what happened there.
Once upon a time, 1993 IIRC, there were only two C++
compilers for DOS that generated native code. The
other one, Zortech, was hard to use because it was
so buggy. Glockenspiel didn't generate native code,
and IIRC it was really expensive. For $99 or so,
Borland was the logical choice for DOS. And they
marketed it. Full-page ads in every issue of PC Tech
Journal. Sieve of Eratosthenes compiles ten percent
faster than the competition, and the binary is only
eight kilobytes. No one cares about that anymore.
Now there's less advertising and more competition.
And less focus on the language: just a few years ago
Borland could still claim standard conformance as a
competitive advantage. Whether that claim was valid
at the time could be debated, but today it's just
not valid. It compiles quickly, but it won't compile
all the code I'm writing these days. Comeau will,
and it costs fifty dollars; g++ will, and it's free.
If I send email to Comeau tonight, he'll probably
respond before midnight. When I report problems, he
fixes them quickly. As for g++, I can monitor the
developers' discussions, participate if I like, get
the source, submit patches, and so on. Borland has
team "B", and they give lots of good advice, but
they can't fix what's broken.
This is all I need to know in order to choose a
compiler, because all I want is a compiler. Well,
and a linker. No one's going to become prosperous by
selling me tools. The commercial market for that is
history.
Borland's focus has changed. It's not just a handful
of Turbo languages plus Sidekick and Quattro anymore.
I just looked at their website, and I wouldn't know
they sell compilers just by looking at the main page.
I have to pull down three menus
Solutions
Products
Develop
before I see a C++ compiler. I guess the world has
changed and you can't make money just selling a
compiler unless you're the size of Comeau or EDG,
especially when g++ is gratis. You need to sell
C++ "solutions" or something like that.
And I guess the competition in that market is a
convicted monopoly, so it's not surprising that
Borland has been pushed into a niche for development
tools (I know nothing about other their markets).
AFAICT, they have a loyal cadre of developers in
small shops who want a "RAD" system. That loyalty has
been strained--I saw the strain with Turbo Prolog,
OWL, and things that came after, as well as the whole
Inprise mess--but somehow some loyalty remains, at
least in the biased sample I get by reading the C++
newsgroups on this server.
For non-VCL apps, why would anyone use Borland C++?
I've used it as an extra tool to check portability,
but the more I use templates, the less valuable that
becomes. I still use it to check syntax because it's
faster than other compilers. But I don't use it for
production. Do you, for non-VCL apps? If so, why?
Leroy Casterline
>For non-VCL apps, why would anyone use Borland C++?
I can't think of a reason. What Borland brings to the C++ table is a
development system that, for Win32 GUI work at least, is the best that
money can buy. Nothing else comes close.
The C++ compiler portion of this system is weak. I hope it will be
strengthened over the next few releases until it is once again the best
C++ compiler around. But it it's not, I can live with it as it is today.
What I can't live without is the VCL. I certainly wouldn't be using
Borland C++ if the VCL weren't in the picture.
Ed Mulroy [TeamB]
> use Borland C++? ...
They wouldn't. Borland C++ is from 1997 and does
not support the VCL.
Instead they might use C++ Builder like I do.
> ... Do you, for non-VCL apps? If so, why?
I use C++ Builder because it is a powerful tool that
does what I need.
. Ed
> Greg Chicares wrote in message
> news:41c234ab$1...@newsgroups.borland.com...
Oscar Fuentes
>> ... For non-VCL apps, why would anyone
>> use Borland C++? ...
>
> They wouldn't. Borland C++ is from 1997 and does
> not support the VCL.
>
> Instead they might use C++ Builder like I do.
>
>> ... Do you, for non-VCL apps? If so, why?
>
> I use C++ Builder because it is a powerful tool that
> does what I need.
C++ Builder, as a C++ compiler, is a pathetic product by any sensible
metric. Maybe it was a decent compiler 4 years ago.
--
Oscar
Ed Mulroy [TeamB]
If your goal is to program to the edge of the language
specification envelope then you are doing something different
than I. When I create a program it is to perform a task and
use what seems appropriate for getting the task done without
regard for if it is impressive when examined with an eye for
the use of subtleties or exotic features.
. Ed
> Oscar Fuentes wrote in message
> news:is718s...@wanadoo.es...
Andrue Cope [TeamB]
> When I create a program it is to perform a task and
> use what seems appropriate for getting the task done without
> regard for if it is impressive when examined with an eye for
> the use of subtleties or exotic features.
Ah yes. A fellow pragmatist :)
--
Andrue Cope [TeamB]
[Bicester, Uk]
http://info.borland.com/newsgroups/guide.html
Oscar Fuentes
>> Oscar Fuentes wrote in message
>> C++ Builder, as a C++ compiler, is a pathetic product
>> by any sensible metric. Maybe it was a decent compiler
>> 4 years ago.
>
> That depends upon how you do things and what you want.
> If your goal is to program to the edge of the language
> specification envelope then you are doing something different
> than I.
What I do is pretty usual by *today's* standards of C++ code
production. Furthermore, I don't care about the internals of a library
if it works correctly, but the library is useless if it doesn't
compile with my tool.
> When I create a program it is to perform a task and
> use what seems appropriate for getting the task done
Me too. The problem with Borland's compiler is that there are parts of
the language that it doesn't support, so I can't always use the most
effective method for getting the task done.
And we are restricting the issue to standards compliance. We also
could comment about performance and correctness of generated code,
quality of diagnostics, support for modern CPU features...
> without
> regard for if it is impressive when examined with an eye for
> the use of subtleties or exotic features.
I don't see the intent of this claim, except as a personal attack when
you know your cause is lost.
--
Oscar
Paul Dolen
>always been ahead, except for the rare leapfrogging.
Yes, the discussion was market share.
Duane Hebert
"Ed Mulroy [TeamB]" <dont_e...@bitbuc.ket> wrote in message
news:41c2e82f$1...@newsgroups.borland.com...
> That depends upon how you do things and what you want.
> If your goal is to program to the edge of the language
> specification envelope then you are doing something different
> than I. When I create a program it is to perform a task and
> use what seems appropriate for getting the task done without
> regard for if it is impressive when examined with an eye for
> the use of subtleties or exotic features.
It's not a question of subtleties or exotic features.
I would imagine that I'm even less likely to appreciate
that than you are.
When you have a large team working on different
aspects of a project, one way to make things go smoothly
is to require using standard c++. Also, a large portion of our
stuff has to be portable to another group working mostly in
Linux.
The problem with BCB is that it doesn't support standard
c++ stuff very well. For example,
we have several objects that work as interfaces so instead
of taking instances by raw pointers, we use boost::shared_ptr.
Instead of using TThread in one block of code dealing with
VCL and something else in straight c++ code, we decided to
use boost threads in all places. The GUI stuff is the least
mission critical part of our applications (at least when the marketing
guys aren't around <g>)
Greg Chicares
> Ed Mulroy [TeamB] wrote:
>
>>When I create a program it is to perform a task and
>>use what seems appropriate for getting the task done without
>>regard for if it is impressive when examined with an eye for
>>the use of subtleties or exotic features.
>
> Ah yes. A fellow pragmatist :)
Being a pragmatist, I like to use code that was
designed, reviewed, and tested by experts, instead
of writing it myself. Especially if those experts
are on the C++ standard library committee...but
look at this boost.org regression test page:
http://www.meta-comm.com/engineering/boost-regression/developer/summary.html
Out of 53 tests, the number that aren't "OK" for
the following windows compilers are
2 mwcw 9.3
1 intel
0 mingw gcc-3.3.1
2 msvc 7.1
13 borland 5.6.4
Borland gets not-"OK" for string algorithms, the
date/time class, program options, and numeric
conversions, to cite a few that don't sound fancy.
Duane Hebert
"Greg Chicares" <chic...@mindspring.com> wrote in message news:41c307c5$1...@newsgroups.borland.com...
> http://www.meta-comm.com/engineering/boost-regression/developer/summary.html
>
> Out of 53 tests, the number that aren't "OK" for
> the following windows compilers are
>
> 2 mwcw 9.3
> 1 intel
> 0 mingw gcc-3.3.1
> 2 msvc 7.1
> 13 borland 5.6.4
>
> Borland gets not-"OK" for string algorithms, the
> date/time class, program options, and numeric
> conversions, to cite a few that don't sound fancy.
I can say that date/time and numeric conversions were problematic
with Borland. Threads were also problematic.
To make matters worse, when using CG, there were additional problems with
some of the boost libs. Using boost::format would prevent some of the
std string functions from working correctly.
But then there were problems with things in the std such as
numeric_limits<int>::max returning
numeric_limits<int>::min so I would imagine that the boost
numeric stuff suffered as well.
VC7.1 used to rate 100% but it seems that the last version
of boost has two failures, graph and spirit. I don't use either
of these so I haven't noticed problems.
Ed Mulroy [TeamB]
> > use what seems appropriate for getting the task done
> > with an eye for the use of subtleties or exotic features.
>
> I don't see the intent of this claim, except as a personal
> attack when you know your cause is lost.
I do not understand how you can interpret what I wrote as
a personal attack.
You described it as a "pathetic product" and I dissagreed.
I said that I used the compiler. I then described how I use
it and how I judge it. My intent was clear, to tell the basis
I used in my judgement of the compiler.
. Ed
> Oscar Fuentes wrote in message
> news:1xdp80...@wanadoo.es...
Ed Mulroy [TeamB]
I don't use TThread or boost threads (or boost anything)
so I not have enountered those items. My reply was to a
statement about Win32 apps without VCL where the poster
had the opinion that the compiler was not good for that.
Very little of what I write uses the VCL.
For threads I use _beginthread - seems to work.
For pointers I use pointers - they work the same as they
always have. If I am feeling lazy or concerned about
checking for when they get deleted, I wrap them in a class,
and find myself doing more of that. For an extensible array
I use a vector instead of a pointer. For items such as a
Windows handle I most often wrap them in a class so the
destructor releases them (for example, a find handle which
is released by FindClose instead of CloseHandle that is
used for most Windows handles). I have done little Linux
work so know little of my techniques would not work on
that platform.
. Ed
> Duane Hebert wrote in message
> news:41c300b9$1...@newsgroups.borland.com...
Oscar Fuentes
>> > When I create a program it is to perform a task and
>> > use what seems appropriate for getting the task done
>> > without regard for if it is impressive when examined
>> > with an eye for the use of subtleties or exotic features.
>>
>> I don't see the intent of this claim, except as a personal
>> attack when you know your cause is lost.
>
> I do not understand how you can interpret what I wrote as
> a personal attack.
I admit that my interpretation of your words went a bit too far. What
I still think is that type of arguments are too weak to use them on
any serious discussion.
> You described it as a "pathetic product" and I dissagreed.
>
> I said that I used the compiler. I then described how I use
> it and how I judge it. My intent was clear, to tell the basis
> I used in my judgement of the compiler.
What I've read on your previous message was, basically: "The way I use
the compiler, it works. It's true that the compiler is broken wrt
certain features, but those are used only to demonstrate how smart you
are and not because they are actually useful."
It is not nice to read that type of arguments.
--
Oscar
John Kaster (Borland)
> Yes, the discussion was market share.
Ok, tx for the reply. MS will always have a larger market share than
Borland for supporting their platform.
Ed Mulroy [TeamB]
> basically: "The way I use the compiler, it works. It's
> true that the compiler is broken wrt certain features,
> but those are used only to demonstrate how smart you
> are and not because they are actually useful."
Not what I meant.
This started with someone's statement that he did not
understand how anyone can find the compiler to be of
use for Win32, non-VCL apps. Most of the Windows
stuff that I do is Win32, non-VCL. I am that "anyone",
use it regularly and find it to be an effective tool.
Take a compiler, any compiler and you will find a bug
here and there. The idea that the fact that a compiler
has a bug necessarily means that it is not usable is
not one with which I agree. I have done good, effective,
productive work with the C++ Builder compiler without
excessive problems with bugs.
For clarity I also inserted text indicating that none of
what I am speaking of involved approaching the edges
of C++. I not only do not use but avoid approaching
the language limits and exotic features in code I
intend as "work product".
For example:
Were you to take the source code of a Windows
program of mine over to a VC++ shop (or a shop
using another non-Borland but reasonable C++
compiler that can build for Windows), once you
converted the make file to their tool and library
structure I would expect it to build just fine (current
VC++, but probably not the previous version).
> ... only to demonstrate how smart you are ...
We've a long history of conversations on here. I do not
think that in any of them I have indicated an opinion of
you such as you inferred. Yes, I do think you follow and
learn what is the leading edge and possible future of C++
but no, I do not see you in the light you inferred.
. Ed
> Oscar Fuentes wrote in message
> news:u0qk7q...@wanadoo.es...
Chris Uzdavinis
...
> For threads I use _beginthread - seems to work.
>
> For pointers I use pointers - they work the same as they
> always have.
Yes, but smart pointers are easier to work with, and boost's reference
counting works very well, and will eventually become part of the
standard C++ library. I think it has already been accepted.
> If I am feeling lazy or concerned about checking for when they get
> deleted, I wrap them in a class, and find myself doing more of that.
That's what boost's smart pointers already do, but it's de facto
standard, and thoroughly reviewed and widely tested.
> For an extensible array I use a vector instead of a pointer. For
Glad to hear that!
> items such as a Windows handle I most often wrap them in a class so
> the destructor releases them (for example, a find handle which is
> released by FindClose instead of CloseHandle that is used for most
> Windows handles).
This is another form of smart pointer.
> I have done little Linux work so know little of my techniques would
> not work on that platform.
It sounds like everything you listed above would work fine except for
dealing with windows handles or calling _beginthread.
But boost::thread should compile the same code on both windows and
linux without any changes (in your code) at all. Same with their
smart pointers.
--
Chris (TeamB);
Ed Mulroy [TeamB]
> > as they always have.
>
> Yes, but smart pointers are easier to work with, and
Wrong context.
-------------
SomeFunc(&variable_name)
or
for (condition; test; increment)
{
const type_name *ptr = array_or_vector[loop_counter];
DoThis(ptr);
DoThat(ptr);
}
or
type_name *return_val = FuncName(arg list);
or
char full_name[MAX_PATH + 1];
char *name_ptr;
GetFullPathName(
"filename.ext", // pointer
sizeof(full_name),
full_name, // pointer
&name_ptr); // pointer to pointer
which upon return becomes
full_name -> "c:\\windows\\dirname\\filename.ext"
name_ptr-> "filename.ext" (addr in the full_name array)
-------------
> ... boost's reference counting ...
I have a long history of being punished by reference
counting and default to thinking little of code which uses
it.
> > items such as a Windows handle I most often wrap
> > them in a class so the destructor releases them ...
>
> This is another form of smart pointer.
Only in part. If I wrap up a find handle then I also do
FindFirstFile and FindNextFile calls in the class, ending
with FindClose - I try to also put the use of the item in
the class. The need for a delete/close at the end is but
a part of the issues to properly handle when using it. I
do not understand why a memory/resource leak from a
pointer or handle gets so much attention while the proper
use of it does not. Remembering to delete/close
something is but the tip of the iceberg.
> But boost::thread should compile the same code on
> both windows and linux without any changes (in your
> code) at all. Same with their smart pointers.
Boost did extensive modifications to support VC++ but
little to support Borland's compiler. I do not use VC++
specific libraries.
I seem to be out of date. When did Linux get threads?
When last I looked people were simulating them.
. Ed
> Chris Uzdavinis wrote in message
> news:j5vfb0p...@explicit.atdesk.com...
>
> > For pointers I use pointers - they work the same as
> > they always have.
>
> Yes, but smart pointers are easier to work with, and
> boost's reference counting works very well, and will
> eventually become part of the standard C++ library. I
> think it has already been accepted.
>
> > ...wrap them in a class ...
>
> That's what boost's smart pointers already do, but it's
> de facto standard, and thoroughly reviewed and widely
> tested.
>
> > For an extensible array I use a vector instead of a
> > pointer.
>
> Glad to hear that!
>
> > items such as a Windows handle I most often wrap
> > them in a class so the destructor releases them ...
Oscar Fuentes
[snip]
> This started with someone's statement that he did not
> understand how anyone can find the compiler to be of
> use for Win32, non-VCL apps.
This is not correct. What Greg asked was, paraphrased "why anyone
doing plain C++ programming would use Borland's C++ compiler and not
Intel, MSVC++ or GCC"? I think it is a fair question, and the answer
is, IMO, "there is no reason to choose Borland, it is inferior on each
and every aspect". Note that nobody said it is unusable.
[snip]
> Take a compiler, any compiler and you will find a bug
> here and there. The idea that the fact that a compiler
> has a bug necessarily means that it is not usable is
> not one with which I agree.
Nobody said this. Bugs is just one aspect. It is true that Borland is
pretty buggy, much more than the competition, but it is inferior on
everything else too.
> I have done good, effective,
> productive work with the C++ Builder compiler without
> excessive problems with bugs.
Some years ago I was forced to choose among using certain effective
C++ techniques and using BCB. Last time my project was built with
Borland it ran 2 times slower than Intel (full
optimization). Furthermore: for passing all tests, I need to switch
off optimizations because of code generation bugs. This is a total
disaster.
> For clarity I also inserted text indicating that none of
> what I am speaking of involved approaching the edges
> of C++. I not only do not use but avoid approaching
> the language limits and exotic features in code I
> intend as "work product".
Who says what the limits are? Everything I use is because a good
reason. Same can be said of Boost's internals. Everything is there to
do useful work on the best possible way.
> For example:
>
> Were you to take the source code of a Windows
> program of mine over to a VC++ shop (or a shop
> using another non-Borland but reasonable C++
> compiler that can build for Windows), once you
> converted the make file to their tool and library
> structure I would expect it to build just fine (current
> VC++, but probably not the previous version).
Everything I write works with all current C++ compilers *except*
Borland.
>> ... only to demonstrate how smart you are ...
>
> We've a long history of conversations on here.
[snip]
I know that. Knowing you, it was an overreaction by my side :-)
--
Oscar
Oscar Fuentes
[snip]
> Boost did extensive modifications to support VC++
This was true on the past, but current VC++ needs little or no
workarounds to work.
> but little to support Borland's compiler.
This is the consequence of two facts: lack of interest about Borland
on the C++ community and the severity of the bugs on certain areas.
[snip]
> I seem to be out of date. When did Linux get threads?
Long time ago. Couldn't say the exact date, but 5 years minimum.
> When last I looked people were simulating them.
--
Oscar
Duane Hebert
"Chris Uzdavinis (TeamB)" <ch...@uzdavinis.com> wrote in message
news:j5vfb0p...@explicit.atdesk.com...
> Yes, but smart pointers are easier to work with, and boost's reference
> counting works very well, and will eventually become part of the
> standard C++ library. I think it has already been accepted.
And they're standard and generally understood.
> But boost::thread should compile the same code on both windows and
> linux without any changes (in your code) at all. Same with their
> smart pointers.
They do. Out of the box.
Duane Hebert
"Ed Mulroy [TeamB]" <dont_e...@bitbuc.ket> wrote in message
I don't want to get into an argument with you
about C++ as I'm sure to lose but I have to
comment.
> For threads I use _beginthread - seems to work.
> For pointers I use pointers - they work the same as they
> always have. If I am feeling lazy or concerned about
> checking for when they get deleted, I wrap them in a class,
Of course you can do without boost and use your own
classes to do similar things. For that matter, you don't
need to use STL at all but STL is part of the language.
Boost is nearly part of the language. A modern C++
compiler should support it.
> and find myself doing more of that. For an extensible array
> I use a vector instead of a pointer. For items such as a
> Windows handle I most often wrap them in a class so the
> destructor releases them (for example, a find handle which
> is released by FindClose instead of CloseHandle that is
> used for most Windows handles). I have done little Linux
> work so know little of my techniques would not work on
> that platform.
Well our code now works on both Linux and Windows
as is. I understand that this is not a common requirement
with people here.
Also most of us can write our own stuff to do what we need
but when we have tools that are both well written and
well tested why bother? Doing it because our development
tools don't support standard stuff doesn't make sense.
How large is your team? When working with a group,
it's useful to have common tools. When interviewing
new SEs we try to make sure they understand STL
and Boost as well as design. This is reasonable as it's part of the language.
New hires have less problem becoming productive if
they can recognize common tools. It also makes for
less bugs and better test drivers etc.
At any rate, I see a lot of reasons to use these tools.
I find that they save us money in development time
and allow us to spend more of our resources developing
our application.
Chris Uzdavinis
>> But boost::thread should compile the same code on both windows and
>> linux without any changes (in your code) at all. Same with their
>> smart pointers.
>
> They do. Out of the box.
I said "should" because I wasn't sure if they worked out of the box
with Borland. I know some of boost cannot be compiled, but others
can. I'm just now sure which libraries belong in which categories.
:)
--
Chris (TeamB);
Ed Mulroy [TeamB]
> > threads?
>
> Long time ago. Couldn't say the exact date, but 5
> years minimum.
Ok, then when did they remove them? <g>
As I understand it, Linux only simulates threads.
. Ed
> Oscar Fuentes wrote in message
> news:llbw7m...@wanadoo.es...
Oscar Fuentes
>> > I seem to be out of date. When did Linux get
>> > threads?
>>
>> Long time ago. Couldn't say the exact date, but 5
>> years minimum.
>
> Ok, then when did they remove them? <g>
>
> As I understand it, Linux only simulates threads.
Your understanding is wrong.
--
Oscar
Ed Mulroy [TeamB]
. Ed
> Oscar Fuentes wrote in message
> news:8y7w7d...@wanadoo.es...
Duane Hebert
"Chris Uzdavinis (TeamB)" <ch...@uzdavinis.com> wrote in message news:j5mzwcp...@explicit.atdesk.com...
No, we were talking about how VC7.1 supports boost as
opposed to Borland. With VC7.1 they work out of the
box. To get threads to work, I could only use version 1.30
and then had to create a static lib from their cpp files.
Some of this had to do with CG but it's been a while
since I last tried it.
The smart pointers seemed to work though.
Oscar Fuentes
>> > As I understand it, Linux only simulates threads.
>>
>> Your understanding is wrong.
>
> So they no longer are using clone() to simulate a thread?
I don't know what they do for supporting threads. What I know is that
Linux supports the pthreads specification, and my multithreaded
software works on Linux as it does on Windows.
--
Oscar
Alex Bakaev
> So they no longer are using clone() to simulate a thread?
>
> . Ed
http://linas.org/linux/threads-faq.html#LinuxSupport
http://www.onlamp.com/pub/a/onlamp/2002/11/07/linux_threads.html
As of 2.6 kernel, NPTL is the standard threading on Linux.
.a
Randall Parker
compatibility most of all. Faster code generation is a lower priority for me.
I'd also like to see the compiler/linker pair play better with the debugger so that
it more rarely gets into a state where the debugger no longer works.
Similarly, I want to see an end to whatever prevents it from compiling with an
internal error relating to the use of ActiveX/COM where it stops on a source line
that reads:
TComModule _ProjectModule(0);
Plus, fix any more scaling bugs in the linker.
So I want better standards compatibility and a few bugs slain in the compiler/linker.
Though faster code gen would be nice too.
Leroy Casterline wrote:
> The C++ compiler portion of this system is weak. I hope it will be
> strengthened over the next few releases until it is once again the best
> C++ compiler around. But it it's not, I can live with it as it is today.
> What I can't live without is the VCL. I certainly wouldn't be using
> Borland C++ if the VCL weren't in the picture.
Ed Mulroy [TeamB]
know that the other schemes, which by the way seem
to still be used, start a new process and pretend that
it's a thread. The description on NPTL is a little muddy
on that point. It will take a bit of reading to find out if
it's threading or just an optimized system which hides
that the threads are other processes. Independent of
that point, the graph shown in the onlamp link seems
to indicate the severe performance problems are fixed.
. Ed
> Alex Bakaev wrote in message
> news:41c36ea8$1...@newsgroups.borland.com...
>
> > So they no longer are using clone() to simulate a thread?
>
Randall Parker
Greg Chicares
> "Ed Mulroy [TeamB]" <dont_e...@bitbuc.ket> writes:
>
>>Boost did extensive modifications to support VC++
>
> This was true on the past, but current VC++ needs little or no
> workarounds to work.
>
>>but little to support Borland's compiler.
_Less_, perhaps; but I wouldn't say _little_.
Grep the boost library for BORLAND and you'll see plenty of
workarounds. Toward the bottom of this page
http://boost.org/more/index.htm
are "Portability Hints" for the two compilers that boost
wrote special articles about; here
http://boost.org/more/int_const_guidelines.htm
is another paper that focuses largely on borland and msvc
workarounds. I think those were the two most problematic
compilers for windows. As Oscar points out, ms fixed
their compiler, so borland kind of stands alone now.
Everyone's welcome to contribute patches to make boost
work better with borland tools. Look:
http://lists.boost.org/MailArchives/boost/msg12101.php
| Greg Chicares wrote:
| > Patches 1 and 2 below probably take care of most of the win32 problems;
| > I've only tested them with gcc and borland, though.
[...]
| > 2. This patch removes other code that raises hardware exceptions
| > with the borland compiler
I'd really rather get the problems solved than deplore
them. I've actually spent time trying to help. Surely
others could do a much better job than I.
If other workarounds can be devised, then borland or its
expert users can send patches to boost and squelch all
these discussions.
> This is the consequence of two facts: lack of interest about Borland
> on the C++ community and the severity of the bugs on certain areas.
The converse - how interested is borland in the C++
community? - is a question that has been asked here so
often over the years that one is led to doubt.
I've seen similar questions asked elswhere about gcc's
support for ada or objective-C, and I'm led to doubt
that those languages are real important to the gcc
maintainers. If I wanted to write those languages,
prudence might suggest I look elsewhere for tools.
But I don't see messages speculating that gcc doesn't
care about C or C++, or that they're going to stop
improving them on any platform I care about.
Ed Mulroy [TeamB]
are a couple of implementations of that. I did not know
about the second. The first was simulated threads by
spinning off a process when a thread was requested and
the performance was not there.
. Ed
> Randall Parker wrote in message
> news:41c3931a$1...@newsgroups.borland.com...
Leroy Casterline
>I'd also like to see the compiler/linker pair play better with the debugger so that
>it more rarely gets into a state where the debugger no longer works.
Debugger fixes and enchantments are high on my want list!
Oscar Fuentes
>> Randall Parker wrote in message
>> news:41c3931a$1...@newsgroups.borland.com...
>>
>> I think they added the POSIX threads API a few years ago.
>
> Yes but as you can see at the links Alex posted, there
> are a couple of implementations of that. I did not know
> about the second. The first was simulated threads by
> spinning off a process when a thread was requested
If the final result is indistinguishable of a thread, is this
``simulation"? BTW, the kernel knows about threads and processes.
> and the performance was not there.
If you worry about the cost of launching a thread because it is
similar to launching a process, remember that ``forking" processes is
a common practice on *nix. Hence, it was optimized to reduce the cost
to a minimun. AFAIK, forking a *nix process is much faster than
launching a Win32 process. *Maybe* launching a Linux thread is not as
fast as starting a Win32 thread, but every OS has winner points over
the others.
--
Oscar
John Kaster (Borland)
> Debugger fixes and enchantments are high on my want list!
Debugger fixes would be enchanting, indeed.
I normally don't point out typos, but when I really like the result, I
do. This one is a keeper ... "debugger fixes and enchantments". Arthur
C Clarke would appreciate it!
Russell Hind
> That depends upon how you do things and what you want.
> If your goal is to program to the edge of the language
> specification envelope then you are doing something different
> than I. When I create a program it is to perform a task and
> use what seems appropriate for getting the task done without
> regard for if it is impressive when examined with an eye for
> the use of subtleties or exotic features.
>
I agree about using the tools that are most appropriate to the task.
For example we were using boost::ublas for large matrix work (didn't
want to implement our own matrix library). As of boost-1.32.0, we can't
use ublas because it has moved on, and bugs in bcc32-5.6.4 prevent it
from working with Borland now.
So it becomes a problem when the most appropriate tools for the job
can't be used because of problems with the compiler. I'm not trying to
push the language, but can't always use the most appropriate tools.
Cheers
Russell
Ed Mulroy [TeamB]
compiler then there is little choice. When you get
to matrix manipulation, reducing to tri-diagonal,
eigenvalues and vectors, etc, the complication and
associated debugging of a custom implemetation is
a massive task to load onto a project. You have to
use an already developed block of code for that.
I remember spending nearly a month on writing and
debugging code to invert complex NxN matrices. It
was not what you could call fun, especially since it
was only one of the tasks in a long list needed to
complete only one of the modules in a program. Had
there been a viable package around which would do
the job then the time and effort saved would require
that it be used.
. Ed
> Russell Hind wrote in message
> news:41c4169d$1...@newsgroups.borland.com...
Leroy Casterline
>Leroy Casterline wrote:
>
>> Debugger fixes and enchantments are high on my want list!
>
>Debugger fixes would be enchanting, indeed.
>
>I normally don't point out typos, but when I really like the result, I
>do. This one is a keeper ... "debugger fixes and enchantments". Arthur
>C Clarke would appreciate it!
<G>!!! Perhaps you could add Harry Potter to your R&D team. Talk about
Freudian slips...
Ed Mulroy [TeamB]
If the final result properly simulates a thread then I
contend that it IS a thread. The internal implementation
by the OS is not an issue at that point.
The cost of launching a thread is not what most bothers
me. Processes are citizens of the OS, like countries.
Threads are of processes, like cities or provinces.
Processes are given resources, notably time slices. A
thread is supposed to share the process' resources,
share the time slices allocated to the process.
If threads are implemented as processes they then cause
a finer division of the resources shared by all processes,
including time slices and they are known by a global
identifier, a process id rather than a local identifier as an
element of an aggregate which is represented by the
process id. As processes by another name they in effect
become a "secret way" for a program to bypass the OS
apportionment method and take time slices, resources,
which would otherwize go to other programs which are also
running.
. Ed
> Oscar Fuentes wrote in message
> news:vfb05l...@wanadoo.es...
Oscar Fuentes
>> ... If the final result is indistinguishable of a thread ...
>
> If the final result properly simulates a thread then I
> contend that it IS a thread. The internal implementation
> by the OS is not an issue at that point.
[snip]
> As processes by another name they in effect
> become a "secret way" for a program to bypass the OS
> apportionment method and take time slices, resources,
> which would otherwize go to other programs which are also
> running.
You can rest assured that Linux is not different from other
multithreaded OSes on this aspect (Win32, for instance). Except that
I know some people that says Win32 sucks when using a few dozens
threads per process, even when most of those threads are on wait
state. That people (not Linux bigots by any definition) says Linux
does much better on that scenario. Maybe this is a consequence of
Win32 being architected as a desktop OS and Linux as a server OS.
--
Oscar
Ed Mulroy [TeamB]
for Win32 installations configured for the desktop is not
trivial.
However the overhead in administration is not the item
of which I was trying to speak.
In an environment where threads are implemented as
processes then threads draw their time slice resources
from the OS as processes rather than sharing their
main process' time allocation. Therefore spinning off
threads becomes a method of increasing the priority
of the overall process, subverting that part of the OS
which administers the time slices and handles requests
to alter process time allocation.
. Ed
> Oscar Fuentes wrote in message
> news:3by35w...@wanadoo.es...
Randall Parker
features that would be enchanting in the more non-supernatural meaning of the word. I
didn't even see it as a misspelling.
John Kaster (Borland)
> My lazy mind read what Leroy wrote and figured he meant that he wants
> really neat new features that would be enchanting in the more
> non-supernatural meaning of the word. I didn't even see it as a
> misspelling.
Well, he certainly could have cut me to the quick and said "what typo?
I meant it that way in the first place!" :)
Hendrik Schober
> Agreed. If what you must use doesn't work with the
> compiler then there is little choice. When you get
> to matrix manipulation, reducing to tri-diagonal,
> eigenvalues and vectors, etc, the complication and
> associated debugging of a custom implemetation is
FWIW, we had our own smart pointer class
templates for years. I thought this was
stupid, because there a good and tested
ones out there, but the other guys agreed
that there's nothing complicated enough
about a smart pointer to need a big
community to get it right.
This changed when someone tracked that
cause of a bug down to the smart pointer.
I proofed that it had a very subtle bug
and sent around some links into the boost
mailing list archieve where they discussed
the issue and how they gotten around it.
Since then, we're using boost's smart
pointers.
Schobi
--
Spam...@gmx.de is never read
I'm Schobi at suespammers dot org
"The presence of those seeking the truth is infinitely
to be prefered to those thinking they've found it."
Terry Pratchett
mr_organic
news:41c3...@newsgroups.borland.com:
> Ok, then when did they remove them? <g>
>
> As I understand it, Linux only simulates threads.
>
> . Ed
>
As one of the (probably hundreds) of people who will respond to this, let
me add my $0.02: wrong, wrong, wrong.
Linux has had native POSIX threading support since *at least* 1998, which
is when LinuxThreads made it into the 2.0.x series kernel. The threading
support wasn't all that robust and didn't fully support the pthreads
spec, but they were real, sure-enough kernel threads.
Since the 2.4.2x series kernels, the threading model has moved to M+N
model (M kernel threads mapping to N user-space threads), just as Solaris
does. It's called NPTL, or Next-gen Posix Threading Library. (IBM
actually worked on another library called NGPT - Next Generation Posix
Threads, based on Gnu's PTH, but NPTL was chosen as the standard
instead.)
Here is a link to more information: http://people.redhat.com/drepper/
Regards,
mr_organic
mr_organic
news:41c6da80$1...@newsgroups.borland.com:
> You need to remember that threading is *always* simulated on single-
> processor CPUs (even on Windows). It's just a question of where the
> simulation is handled: in the kernel, or in userspace.
>
I should note that Intel's "Hyperthreading" technology does muddy the
waters a little bit in this respect - some P4 and Athlon series of x86 CPUs
can indeed operate *some* thread operations in parallel. But it still
doesn't quite equate to the same true concurrency you'd get with multiple
CPUs since some operations must still be serialized -- many of the MMU and
math functions are in this category.
quux111
mr_organic
Sorry for using the quux111 sig instead of mr_organic - had the wrong
profile activated. Apologies.
mr_organic
mr_organic
@newsgroups.borland.com:
You need to remember that threading is *always* simulated on single-
processor CPUs (even on Windows). It's just a question of where the
simulation is handled: in the kernel, or in userspace.
Prior to the 2.0.x series of kernels, Linux was like many old-line *nixes
in that it supported only the fork() command to spawn new processes, but
each process was monolithic and had only a single thread of execution per
process. (There were several userspace threading libraries available, of
which GNU's Pth (http://www.gnu.org/software/pth/) was - and remains -
the best.) However, with the introduction of LinuxThreads in the 2.0.x
series of kernels, Linux got "real" threading support.
LinuxThreads mapped new threads to lighweight processes, so each new
thread got its own PID. This did cause some performance problems with
applications that spawned lots of threads (e.g., web servers) due to the
housekeeping overhead of keeping track of all the active PIDs. These
performance problems were not so much due to the threading model so much
as deficiencies in the kernel itself.
When NPTL was introduced in the 2.4.x series of kernels, Linux moved to
the more modern M+N model in use on platforms like Solaris. This approach
uses the "lightweight kernel process" implementation, and also allows for
multiple userspace threads to be mapped to a single kernel thread.
Linux actually has a more modern threading model than Windows 2000/XP,
which is based on a more monolithic model (although I think Windows 2003
and Longhorn have moved to the M+N model as well).
Many old-time Unix guys still maintain that threading is much overused
(http://threading.2038bug.com/threads/http,,,c2.com,cgi,wiki,ThreadsConsi
deredHarmful), and that similar results can be achieved in a more robust
way with other methods. A good example of this is the classic X Window
server: it is *not* multithreaded, but instead uses a closed loop and a
select() statement to handle input, and it achieves very good concurrency
without using threads at all. (Many X Window programs *do* make use of
threading, however, especially these days.)
Regards,
quux111
Alisdair Meredith [TeamB]
> You need to remember that threading is always simulated on single-
> processor CPUs (even on Windows). It's just a question of where the
> simulation is handled: in the kernel, or in userspace.
Or even in the hardware, if you have a hyperthreaded P4!
AlisdairM(TeamB)
mr_organic
<alisdair.NO.SPAM...@uk.renaultf1.com> wrote in
news:41c6...@newsgroups.borland.com:
Thus my follow-up on this exact point.
Lots of newer CPUs do this kind of "parallel execution" - IBM's POWER
series does it, SPARCs have done it for just about forever, DEC's Alpha
does it, and PA-RISC does it. In fact, I can't think of any modern CPU
design that *doesn't* do it, except for the low-end x86 stuff from VIA
(the Joshua series). And with VIA that's a fair trade because you can run
at a decent clip with only a heatsink; no noisy fan!
Still, parallel execution of certain instructions doesn't speed things up
as much as you might think. That's because certain instructions -- many
math and MMU functions -- cannot be parallelized. Also, the
parallelization overhead often "breaks" the deep pipelines used by CPUs
like the P4, inflicting a pretty gross speed penalty due to cache misses
and whatnot. In this scenario, hyperthreading can actually *slow down*
certain types of applications.
Ultimately, threading is like a pistol: a useful tool, but dangerous in
the wrong hands.
Regards,
mr_organic