Board index » cppbuilder » Re: Borland was too late for me.

Re: Borland was too late for me.


2005-03-24 04:44:59 AM
cppbuilder74
What's IPP?
Rob
"Boian Mitov" < XXXX@XXXXX.COM >wrote in message
Quote
As you pointed out, it is getting a bit better already ;-)
Cheers,
Boian

BTW: Are you still interested in a tool that allows you to use M$
libraries directly from inside Delphi/BCB ? We have it working, and we
have the Intel IPP working as library under BCB and Delphi. It is still
designed for internal use, and not ready for a release as a tool, but I
can get it for you if you have the need for it.

 
 

Re:Re: Borland was too late for me.

Hi Tim,
While I agree that Borland has done that, I must note that it seems
to be the same case as example with the VB developers in M$. Those
unfortunate events seem to happen. The good news is that at least now
Borland seems to be reversion some bad decisions. As it also seems to be
the case with M$ not pushing any more the C# and going back to C++. So
the things are at least moving into somewhat right direction in both
companies. We should at least admit that.
Cheers,
Boian
tim wrote:
Quote
Remy,

You're right I don't. But it was speculation based on my own personal
insights. It wasn't an attack.

The fact that so many people around here are defensive about so many
things, is just in my opinion, indicative of SO many things. Borland has
poisoned its drinking water and its a shame.


cheers,


tim
 

Re:Re: Borland was too late for me.

Intel Performance Primitives.
Cheers,
Boian
Robby Tanner wrote:
Quote
What's IPP?

Rob
 

{smallsort}

Re:Re: Borland was too late for me.

We do offer free support ;-) . But then again may be we are nobody ;-) .
Dennis Jones wrote:
Quote
Yes, as I mentioned in another thread just recently, Borland's technical
support used to be free for paying customers -- I sorely miss those days,
but practically nobody offers free technical support anymore, and they get
away with it because we as customers have done nothing that forces them to
(such as boycotting the product, etc).
 

Re:Re: Borland was too late for me.

Boian,
Is your use of MFC essential?
Boian Mitov wrote:
Quote
4 MFC combinations.
6 RTL combinations.

4 * 6 = 24

Hendrik Schober wrote:

>
>Wow. I never did any MFC. How do you get so
>many?
>
 

Re:Re: Borland was too late for me.

I avoid it at cost any time I can ;-) .
Cheers,
Boian
Randall Parker wrote:
Quote
Boian,

Is your use of MFC essential?

 

Re:Re: Borland was too late for me.

"Boian Mitov" < XXXX@XXXXX.COM >wrote in message
Quote
We do offer free support ;-) . But then again may be we are nobody ;-)
.

Dennis Jones wrote:

>support used to be free for paying customers -- I sorely miss those
days,
You probably meant something different, but that's an amusing statement, out
of context and all...
 

Re:Re: Borland was too late for me.

Well he claims that nobody offers free support any more... I was just
pointing out that either we are nobody, or he is probably wrong ;-)
Robby Tanner wrote:
Quote

You probably meant something different, but that's an amusing statement, out
of context and all...


 

Re:Re: Borland was too late for me.

"Robby Tanner" < XXXX@XXXXX.COM >wrote in message
Quote
>Dennis Jones wrote:
>
>>support used to be free for paying customers -- I sorely miss those
days,

You probably meant something different, but that's an amusing statement,
out
of context and all...
Ha! Yes, I didn't even realize how funny that was until you pointed it out.
What I meant was, technical support was provided free-of-charge to those who
purchased the product.
- Dennis
 

Re:Re: Borland was too late for me.

Oh I certainly didn't mean to imply one is better than the other. :)
Putting all your eggs into any proprietary, whether it be VCL or VB,
technology is inherently risky.
Also, you mentioned C# not being pushed and MS going back toward C++.
How did you reach that conclusion? I'd like to read something about that.
cheers,
tim
Boian Mitov wrote:
Quote
Hi Tim,

While I agree that Borland has done that, I must note that it seems to
be the same case as example with the VB developers in M$. Those
unfortunate events seem to happen. The good news is that at least now
Borland seems to be reversion some bad decisions. As it also seems to be
the case with M$ not pushing any more the C# and going back to C++. So
the things are at least moving into somewhat right direction in both
companies. We should at least admit that.
Cheers,
Boian


 

Re:Re: Borland was too late for me.

"Dennis Jones" < XXXX@XXXXX.COM >wrote in message
Quote

"Robby Tanner" < XXXX@XXXXX.COM >wrote in message
news:4241fa9a$ XXXX@XXXXX.COM ...

>>Dennis Jones wrote:
>>
>>>support used to be free for paying customers -- I sorely miss those
>days,
>
>You probably meant something different, but that's an amusing statement,
out
>of context and all...

Ha! Yes, I didn't even realize how funny that was until you pointed it
out.

What I meant was, technical support was provided free-of-charge to those
who
purchased the product.
I thought it was something along those lines....
 

Re:Re: Borland was too late for me.

Hi Tim,
Read MSDN. It is old news.
Cheers,
Boian
tim wrote:
Quote
Oh I certainly didn't mean to imply one is better than the other. :)
Putting all your eggs into any proprietary, whether it be VCL or VB,
technology is inherently risky.

Also, you mentioned C# not being pushed and MS going back toward C++.
How did you reach that conclusion? I'd like to read something about that.


cheers,


tim
 

Re:Re: Borland was too late for me.

Robby Tanner wrote:
[big snip]
Please, quote appropriately.
Thanks,
.a
 

Re:Re: Borland was too late for me.

Boian Mitov wrote:
Quote
Hi Andre,


[...]
there is a bit of a problem. I can't see at all why VC++ will have
problem finding the entry point in the library regardless of
Debug/Release version. It is after all the same entry point, and it
makes no sense. I assume this to be actually a bug in VC++, as I have
not see another compiler that does that.
The problem is perhaps not the entry point, surely it would be possible
to link each memory allocation to the same function, as itīs done
in BCB. I donīt know the detailed memory allocation schemes of VC, but
it should be something like the following:
debug: malloc(100) --->
[....] [100] [....]
where [....] are magic idīs initialized on allocation and checked
on deallocation, which are located before and after the "normal memory
block".
allocation in release version: should be similiar to BCB
malloc(100) --->
[] [100] []
So if the debug rtl has to free a block of memory, it has to
substract the size of the magic id from the memory block, to get the
correct heap pointer to deallocate.
If it would be possible to mix release and debug versions in VC, the
release version might get a debug allocated memory block pointer, which
would lead to memory leaks or heap corruptions. The other way round it
would lead definitively to heap corruptions.
Itīs VCīs way to implement something like BCBīs CodeGuard
(only for memory allocations)
The downside is surely, that you canīt mix debug and release builds
that easily as you can do it in BCB.
Quote
The configuration manager at least should make the life a bit easier.
The pragmas are a good idea, and we are experimenting with them. Your
I find it much easier, than specifying the lib files in the project or
make files and iīve didnīt found a downside yet and to play it
safe, they could be disabled by using another macro or other header
file, not using them. So the library user would be free to choose.
And the best, this pragma is support by BCB and VC and perhaps other
compilers too.
Quote
suggestion is a good one, and I will explore it further. I appreciate it.
I want to see both BCB and VC++ improved, not the other way around.
I agree and i donīt want to see either BCB nor VC die. I want to see
them both compete and get improved.
Quote
I
just think that it is a bit unfair to Borland when indeed they have done
something better than M$, not to get some credit for it.
Letīs say theyīve done it differently. VC does a lot of heap checking
in the debug version and BCB has CodeGuard for this task.
BCB is easier to handle than VC, but if i have to handle multiple
projects in a project group i miss some features in BCB.
The minimum functionality i need is to define the project build order,
so that my (own) library projects are built at first.
Donīt get me wrong, i donīt want to state that the way BCB handles libs
is bad or that the way VC does it is generally better.
There are reasons for both strategies and both should get the credit for
it - and yes - handling of libraries is easier in BCB, but thereīs a
very good reason why itīs not that simple in VC as iīve pointed out
above and i simply denied the statement, that itīs not that simple
than in BCB because they want to annoy their customers.
BCB shall get itīs credit, but i think the missing features should be
mentioned too and what can be improved. The other way round it should
be done in the MS group *g* - competition is good for both sides *g*
Quote
P.P.S. Now you make much more sense, and seems like we are getting on
the same page ;-)

Yep - i prefer to do it the easy way, too. The other way round would
make that much sense (for me) ;-)
Quote
[...]
Cheers,
Andre
 

Re:Re: Borland was too late for me.

Hi Andre,
I agree with you. I think that both tools need a lot of improvements. I
just felt that the initial statements ware a bit unfair to Borland,
however we must have a better project management actually in both VC++
and BCB. I find both of them not adequate for different reasons.
Cheers,
Boian
Andre Kaufmann wrote:
Quote
<SNIP>
Letīs say theyīve done it differently. VC does a lot of heap checking
in the debug version and BCB has CodeGuard for this task.
BCB is easier to handle than VC, but if i have to handle multiple
projects in a project group i miss some features in BCB.

The minimum functionality i need is to define the project build order,
so that my (own) library projects are built at first.

Donīt get me wrong, i donīt want to state that the way BCB handles libs
is bad or that the way VC does it is generally better.
There are reasons for both strategies and both should get the credit for
it - and yes - handling of libraries is easier in BCB, but thereīs a
very good reason why itīs not that simple in VC as iīve pointed out
above and i simply denied the statement, that itīs not that simple
than in BCB because they want to annoy their customers.

BCB shall get itīs credit, but i think the missing features should be
mentioned too and what can be improved. The other way round it should
be done in the MS group *g* - competition is good for both sides *g*


>P.P.S. Now you make much more sense, and seems like we are getting on
>the same page ;-)
>

Yep - i prefer to do it the easy way, too. The other way round would
make that much sense (for me) ;-)