Board index » cppbuilder » Re: Delphi/BCB Integration (Part 2)

Re: Delphi/BCB Integration (Part 2)


2004-04-21 05:45:23 PM
cppbuilder85
Hendrik Schober wrote:
Quote

>Generics are already slated to be inclued in Delphi anyways so


Are they?


The generics discussed for Java on the BDN only allow type-based classes
such as vector etc which are useful, but no-way near demonstrate the
power of TMP.
Generics are, AFAICT, as Ed described, type based #defines, TMP is much
more than this.
Cheers
Russell
 
 

Re:Re: Delphi/BCB Integration (Part 2)

ross < XXXX@XXXXX.COM >wrote:
Quote
Barry Kelly wrote:
>"Adam Versteegen" < XXXX@XXXXX.COM >wrote:
>
>
>>Well you'd clearly know better than me :). I don't use delphi, so woudln't
>>know. I just find that whenever i'm looking for code samples, libraries,
>>routines etc, its quite easy to find things in C++. I didn't know if the
>>same could be said for delphi.
>
>
>It's unbelievably easy to find mountains of samples, libraries and
>routines written for Delphi.
>
>I really mean that. Unbelievably easy.
>

Ok heres one. Free Fast Fourier Transform libraries, something akin to
FFTW which is C based.
Free one - www.fullspectrum.com/deeth/programming/fft.html
One that cost $20 for complete DElphi source (no Dlls)
www.aho.ch/fft/
A list of different Digital Signal Processing, Fourier Analysis, FFTs available/usable with Delphi (some free some not)
homepages.borland.com/efg2lab/Library/Delphi/MathFunctions/Engineering.htm
 

Re:Re: Delphi/BCB Integration (Part 2)

Barry Kelly < XXXX@XXXXX.COM >wrote:
Quote
"Ed Mulroy [TeamB]" < XXXX@XXXXX.COM >wrote:

>Template metaprogramming is in essence a type-sensitive #define
>mechanism that is especially useful for doing factorial calculations
>and other cs100 parlour tricks.

It does however turn the compiler into a Turing-complete engine for
producing code in a standard, platform-independent way!

But it is also nothing special about C++ templates. Any
generics implementation can accomplish the same thing. The
biggest reason it probably would not show up in Delphi generic
is that it would require it to be a two pass compiler which the
team has stayed away from due to the blazing speed of the
compiler today is considered an advantage for Delphi. Templates
are just one way to accomplish generics, it is not the only way.
Jsut because there is one side effect of the template implementation
of generics does not mean other generic implementations can't
also have the same side effect.
 

{smallsort}

Re:Re: Delphi/BCB Integration (Part 2)

I do not doubt that there are situations where template
metaprogramming is the best solution. I do not know offhand what is
not possible with C++ that is possible with Fortran let alone what
template metaprogramming can do to change that. I'd like to know
that. Have you a 'quicky' example? (note that while I've done a lot
of Fortran, all of it was Fortran IV or V on an IBM 360's/370's - most
of it on the code for Eispack).
I do doubt that the situations are common or at least not the ones
commonly seen.
The idea that using the compiler as a recursive calculator as a good
general technique flies in the face of any considerations for
efficiency. I think it is best viewed as a specialized technique and
should be presented as such.
Quote
... I understand your dislike for hypes ...
Sometimes hypes are entertaining - when that is the case I like them.
<g>
. Ed
Quote
Hendrik Schober wrote in message
news: XXXX@XXXXX.COM ...

>Template metaprogramming is in essence a type-
>sensitive #define mechanism that is especially useful
>for doing factorial calculations and other cs100 parlour
>tricks.

C'mon Ed. I understand your dislike for
hypes. Nevertheless, there are usefull
applications of TMP and you do know
that.
The very first thing TMP did (after
puzzling everyone who looked at it for
the first time) was to make C++ usefull
for applications that so far were only
possible on FORTRAN.
Reducing TMP to the usefullness of the
educational factorial example is like
reducing C++ to the "Hello, world!"
example and then mutter about it not
beeing very usefull.
 

Re:Re: Delphi/BCB Integration (Part 2)

Ed Mulroy [TeamB] < XXXX@XXXXX.COM >wrote:
Quote
I do not doubt that there are situations where template
metaprogramming is the best solution. I do not know offhand what is
not possible with C++ that is possible with Fortran let alone what
template metaprogramming can do to change that. I'd like to know
that. Have you a 'quicky' example? (note that while I've done a lot
of Fortran, all of it was Fortran IV or V on an IBM 360's/370's - most
of it on the code for Eispack).
With expression templates (google for Todd
Veldhuizen's blitz++ lib) C++ became fast
enough to par with FORTRAN in scientific
computing.
Quote
I do doubt that the situations are common or at least not the ones
commonly seen.

The idea that using the compiler as a recursive calculator as a good
general technique flies in the face of any considerations for
efficiency. I think it is best viewed as a specialized technique and
should be presented as such.
Have you read the paper I sent you a few
weeks ago?
Quote
>... I understand your dislike for hypes ...

Sometimes hypes are entertaining - when that is the case I like them.
<g>

. Ed
[...]
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"Sometimes compilers are so much more reasonable than people."
Scott Meyers
 

Re:Re: Delphi/BCB Integration (Part 2)

Quote
With expression templates (google for Todd
Veldhuizen's blitz++ lib) C++ became fast
enough to par with FORTRAN in scientific
computing.
Ahhh, "fast enough" - that's different. I took issue with "can't do"
but cannot contest "fast enough".
Quote
Have you read the paper I sent you a few
weeks ago?
I don't remember it. I'll have to go back into my email and look for
it. I hope it didn't get labeled as spam by Popfile - if so, it's
gone :-(
Quote
... google for Todd Veldhuizen's blitz++ lib...
I've seen "blitz++" mentioned in web pages but paid little attention.
There are very many libraries out there and a high percentage of them
have problems so I tend to not look into one merely because it was
mentioned on a web page. Mentioned by you is another thing entirely.
I'll look into it.
Just looked. Found www.oonumerics.org/blitz/platforms/
From that page's text it does work with BCB. I'm downloading it and
will investigate it.
. Ed
Quote
Hendrik Schober wrote in message
news: XXXX@XXXXX.COM ...
 

Re:Re: Delphi/BCB Integration (Part 2)

I spoke too soon. From the information on the page whose link I
posted Blitz++ is neither viable nor usable.
. Ed
Quote
Hendrik Schober wrote in message
news: XXXX@XXXXX.COM ...
 

Re:Re: Delphi/BCB Integration (Part 2)

Hendrik Schober wrote:
Quote
With expression templates (google for Todd
Veldhuizen's blitz++ lib) C++ became fast
enough to par with FORTRAN in scientific
computing.
Schobi, Since all templates expand out to regular C/C++ code how can templates allow
code that is faster than non-template code?
 

Re:Re: Delphi/BCB Integration (Part 2)

"Randall Parker" wrote:
Quote
Hendrik Schober wrote:

>With expression templates (google for Todd
>Veldhuizen's blitz++ lib) C++ became fast
>enough to par with FORTRAN in scientific
>computing.

Schobi, Since all templates expand out to regular C/C++ code how can
templates allow
code that is faster than non-template code?
community.borland.com/article/print/0,1772,10526,00.html
en.wikipedia.org/wiki/Template_metaprogramming
Peter
 

Re:Re: Delphi/BCB Integration (Part 2)

They get expanded at compile time so the compiler spends the time
needed to sort things out, recursing if necessary only putting the
results into your executable.
In some cases, for example the factorial trick that I mentioned, all
that goes into the executable is a number. In most cases what goes
into the executable is code that is greatly simplified from how it
appears in the source.
. Ed
Quote
Randall Parker wrote in message
news: XXXX@XXXXX.COM ...

>With expression templates (google for Todd
>Veldhuizen's blitz++ lib) C++ became fast
>enough to par with FORTRAN in scientific
>computing.

Schobi, Since all templates expand out to regular C/C++
code how can templates allow code that is faster than
non-template code?
 

Re:Re: Delphi/BCB Integration (Part 2)

Ed Mulroy [TeamB] < XXXX@XXXXX.COM >wrote:
Quote
I spoke too soon. From the information on the page whose link I
posted Blitz++ is neither viable nor usable.
Note: I have never used blitz, I don't
think I even downloaded it. It is just
_the_ classical example for what TMP
(in this case, Expression Templates)
is for and what can be done with it.
I think it is older than the C++ std,
which already is 5 years old. I have
no idea how usefull, up-to-date, or
hip it is today.
Quote
. Ed
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"Sometimes compilers are so much more reasonable than people."
Scott Meyers
 

Re:Re: Delphi/BCB Integration (Part 2)

Hi,
snip
Quote
>>It's unbelievably easy to find mountains of samples, libraries and
>>routines written for Delphi.
>>
It's a petty Borland stopped continuing their Turbo toolbox a long time
ago. It has helped me a lot. Because indeed there much less to find in
Pascal then there is in Fortran or C.
That Toolbox contained nice FFT routines which could easilly be imported
in Delphi and contained a lot more, like a good book which explains the
software.
Ben
 

Re:Re: Delphi/BCB Integration (Part 2)

Magnificant Flame!
"Jeff Overcash (TeamB)" wrote:
Quote

MS does not prove your point since the tools division loses
money each year. It has always been considered a support
division within MS.
So M$ would be better off if they folded their tools division and let Borland handle that
end? I don't know. Loss leaders are common. I'd prefer BCB be a loss leader than to
disappear. <And if your overtone is right, M$ needs to give Borland more doe, and a few
people back too, and fire the rest of the tools division>:-).
The very thing you avoid, here, is the issue. At least its clear that its deliberate.
I think your point is that Borland is a tool maker, Ok.
M$ made(in millions):
Client $2,527 $2,924 $7,868 $8,792
Server and Tools 1,827 2,177 5,215 6,177
Information Worker 2,327 2,739 6,880 7,921
Microsoft Business Solutions 147 153 388 471
MSN 508 591 1,394 1,628
Mobile and Embedded Devices 46 61 112 177
Home and Entertainment 453 530 2,265 2,377
"The company's server and tool business accounted for nearly a quarter of total sales in
its first quarter and sales growth here is helping to offset sluggish growth in
Microsoft's client division, which includes the traditional operating systems for PCs,
and its information worker unit, which includes sales of its Office software ."
(money.cnn.com/2004/01/21/technology/microsoft/)
Quote

>Which company can
>you point out that has lost this gamble. Borland never tried it. M$ has resorted to
>it.

MS had too. You do not need at all BCB if you are a Delphi
programmer. There is absolutely nothing you can't do in Delphi
you can do in C++.
Yes, you give every indication of being a fantastic Delphi guy, (This is a complement, I
think), that doesn't share code with a bunch of imbeded programmers (a plus I assure
you).
Maybe if Borland makes a compiler that will allow embeded programmers to use Delphi, I
will agree completely. ("Embeded", in my case, means various electric meter firmware, and
"sharing", for example, means proprietary communications code. This can be quite complex
to reimplement, but quite easy to copy code in C and take care of the big/little endian
byte order and alignment issues.) Can this be done in Delphi? At the same low cost? Yes
to both, if BCB/Delphi were one.
Quote
With the MS tools, VC++ is not good at
building GUI apps at all and VB, which is good at building GUI
apps, has several areas it can't do at all and other areas it
does not do efficiently, making a need to use mulitple tools to
get the job done. This is not true nor needed for either BCB
or Delphi.
The choir hears you loud an clear on that.
I've made similar statements. In fact, thanks for explaining what I meant by "resorted
to" in the prior snip.
I would further your statement and say that Borland may have pushed M$ to create VS with
Delphi and Builder.
But thats not exactly the line of thought that I was getting at.
M$ makes OS's. Borland makes Delphi. M$ adds to the $ orthogonally by making compilers.
The question, highly altered, is, "can Borland make money with C++ in the same way M$
makes money with compilers?". Jeff, you probably, will think not. Given more information
than we Builder plebs, you may have already answered the question in a different way than
Des suggests. But you implied that Des is absolutely off base. I'm not so sure its as
absolute as you conclude.
I was initially very disappointed to find that BCB 1.0 could not use pascal source more
easily and I was extremely disappointed that I could not very easily create components
that would be used by Delphi customers directly. I did not "presume to tell Borland there
business" then, and I do not now. But I think it was an initial mistake.
Quote

>Who has the working stratagy?

Considering Borland is a tools vendor traditionally making
money and the tools division at MS historically loses money, I'd say Borland.

I only argue that overall it makes money for M$ ( for you I'll say, "when used in support
of their OS/Server products"). Only when one closes the mind into a small box does M$
loose money producing VS. It depends on where you look on the balance sheet. (I guess
since I easily found the part of the balance sheet that VS tools is positive, you'll look
and find where it is reported as negitive, but will it be harder to find?-| )
Quote

>And where do you find proof to back up your
>beliefs.
>

I'm under an NDA, I can't answer that without breaking my NDA.

I admire your restraint and composure. I appreciate you being as open as you can. I've
seen you out here for years and would hate to see you say anything to get you booted off
or censured. Eventually though, somebodys gotta say somethin'.
I anticipate that the proof you cannot mention is measurable and well defined. I've
expressed confidence in Borland to come through. I'm not convinced that Borland would
loose money enabling programmers to do things their way. I did concede, however, the
risk, with the funds, personnel and time to market constraints, not only on BCB X 2.0,
but also the coming of Whidbey and Longhorn. I will also have some confidence, due to
your continuing trust of Borlands future, that the solution they pick will be amenable.
Without seeing and hearing such proof, though, its difficult remain positive. I ignore my
outright hatred of Borlands marketing and legal departments due to my affinity for the
former creations of the engineering staff; there is nothing logical about that.
Quote

>They sound logical. They feel logical. But do these beliefs prove true. Not for M$.

Once again, MS loses money with their tools division.

Once again, they gain more money than they loose. Once again, you determine to dismiss
the real question posed.
If you were a politician I would have to say great going. Maybe Borland would loose more
than it gained by adding C#/C++ to Delphi and maybe not. Maintaining the same posture and
insight, it seems certain. Off subject:(NAFTA under Clinton, more jobs for more Americans
and more jobs for other countries. NAFTA under Ross Perot, a "giant sucking sound" out of
the states and slave labor for 3rd worlders--look at his real hiring practice, this is
not speculation. NAFTA under Bush, a leaky job bucket. NAFTA is a matter of execution and
self determining belief of its executors.) Maybe theres a connection there somewhere,
darned if I can put my finger on it.
You do have a point that Borland is just... just a tool vendor, but we have never seen
what Delphi would sell like if it were entirely interoperable with C++.
This knowledge, not only, is not publicly availible, nor can it be known without doing it
well. I'm not sure your presupposing former C++ users is guarenteed to be a resonable
estimator of Delphi sales with C#/C++; nor do I think presupposing Delphi guys running
for the hills because Delphi contains C++ that never have to use is an accurate estimator
of losses. How could I be sure? How can you?
You said:
"Resource wise you save nothing. BCB and Delphi (7 and lower) already shared an
IDE so you are still talking about sharing an IDE so the IDE resources stay
roughly the same. Documentation - same resources. VCL - same resources.
Compiler - same resources. I have yet to find a single resource that you think
will be saved by this. There was plenty of overlap before and the ROI was poor
for BCB, the overlap and non overlap is still roughly the same with this idea as
it was before with less overall revenue generated."
You know, I hope, more about Borland's solution, which, I hope, makes customers
suggestions less interesting than what's actually happening right now at Borland. I
understand this bias, but don't you think that if that bias were removed, Des' suggestion
might not seem so absurd.
Dream:
If BCB and Delphi were the same product, release dates would be forced to be the same,
they could not lag. I wonder if that alone wouldn't foster or necessitate sharing and
crossover not utilized at present. Your description makes use of present methodology that
may consist of several unnecessary steps; Delphi component creation by one group,
training of, and communication to, another group, and BCB component wrapper creation (I
assume it is not automated). Maybe that whole thing becomes Delphi component creation and
BCC simply knows how to read compiled pascal units. Maybe, to aid bidirection, BCB/Delphi
use common interface files for components rather than seperate .dcu and .h files. Maybe
the automatic code produced at the high level for each unit, is just a check in the
project manager, and if you want to use C++ or Pascal, the IDE just does. Pascal purists
don't have to see C++ to use C++ components. C++ users need only worry about pascal in
the cases that they already do now, at the user interface level. Most sane C++
developers, and almost no BCB users, care enough about C++ standards, when at this level,
to disregard the product. I admit two things, I'm thinking out of the box narrowly
constructed now, and that C++ users might continue to feel confined and constrained,
limited to the Delphi constructs for components.
Now, would such a thing out sell Delphi? I think so. Perhaps, and likely, you think not.
Would there be savings in VCL creation? I think so. Infact, given BCC knows .dcu's,
considerable savings.
IDE Resources? Higher - but maybe not enough to offset.
Compiler? Higher - but maybe not enough to offset.
Again, I claim no confidence. I am not suggesting Borland follow the suggestion. I just
question dismissing the possibilities outright.
Quote
the tools division exists to support the OS and Office
divisions primarily and that is the primary purpose for it
being in existance, not to make money.
I'll forgive this one. Your usual form is usually much tighter than this. Leave it to me
to sling fast and loose. Even if I take your pinpoint view on the tools division, this
statement is loose. You clearly are just tired of telling me the same thing over and
over, that M$ is the most generous of billionares on the planet, that pay us to take
their tools.
Quote

>I admit Des suggestion is a gamble. But lets not say it is not possible before
>testing to see if our beliefs hold water.
>

If you do not know the current user base overlap how can you
possibly say it holds water.
I refer to the general dismissive tone used, suggesting that we do not totally disregard
ideas that cannot be proven incorrect. Thats all. Now if you've reason to believe the
weight of evidence suggests something different to you than to me, great. Not everyone
has seen the research you have, but if you can't say it, doesn't it make sense to be
gracious to the readers perspective? Even if you have the best marketing opinion Borland
has to offer on BCB or C++, that, in itself, has not been proven infallible.
Quote
The primary key piece of
information to make such a claim is not publicly known.
Amen. Never said it was. Just hoping to discover it somewhere. Hope Borland has it hidden
someplace, and is not just pretending to have some secret plan.
 

Re:Re: Delphi/BCB Integration (Part 2)

ross wrote:
Quote
Ok heres one. Free Fast Fourier Transform libraries, something akin to
FFTW which is C based.
How about arbitrary precision *float* arithmetics. There are tons of
C/C++ libraries out there, but none for Delphi that I'm aware of.
Or, for C#, either.
LP,
Dejan
 

Re:Re: Delphi/BCB Integration (Part 2)

DS wrote:
Quote

ross wrote:
>Ok heres one. Free Fast Fourier Transform libraries, something akin to
>FFTW which is C based.

How about arbitrary precision *float* arithmetics. There are tons of
C/C++ libraries out there, but none for Delphi that I'm aware of.

Or, for C#, either.

In less than 5 minutes using google I found this -
www.delphiforfun.org/Programs/bigfloat.htm
codecentral.borland.com/codecentral/ccweb.exe/listing
www-rab.larc.nasa.gov/nmp/nmpCode.htm
There were also many more hits, but I wasn't going to waste my time tracking
them down. People who think something isn't available for Delphi tend to have
no idea about what is really available out there.
Also Delphi can use any of the C libraries too, all you have to do is compile
them with BCB and link the obj in, very simple to do.
Quote
LP,
Dejan
--
Jeff Overcash (TeamB)
(Please do not email me directly unless asked. Thank You)
A human being should be able to change a diaper, plan an invasion, butcher
a hog, conn a ship, design a building, write a sonnet, balance accounts, build
a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act
alone, solve equations, analyze a new problem, pitch manure, program a computer,
cook a tasty meal, fight efficiently, die gallantly. Specialization is for
insects. (RAH)