Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » Coffee corner » C++ FQA
Re: C++ FQA [message #12579 is a reply to message #12558] Fri, 09 November 2007 13:41 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
luzr wrote on Fri, 09 November 2007 08:51


Well, but that is useful feature and this is one of things I like with C++ - the "default" mode is "safe", but you can always do dirty things when you need them.


no, here I don't agree.... such things make virtually impossible write 'safe' libraries. A 'const' should be a 'const', not a 'maybe const'.... as 'private' should be so, not a maybe one.
I've seen constructs like that :
#define private public
#include "alib.h"

just to overcome a private class declaration and access the low-level stuffs inside it.... Then, when library changes, people (maybe also people that hasn't nothing to do with such a hack) starts wondering why his program that up to the day before worked like a charm just crash. IMHO that has nothing to do with commercial-grade applications.

Quote:


In other words, you can also say that a well written library can do what it needs Smile


well, a well written lib should do what the coder will, *not* what the user is missing. Before using C++ hacks to overcome libs limitations, you have 3 solutions :
1) Patch the sources, if you have them
2) Ask the original programmer to enhance the lib
3) Just find another lib that suit your needs

Quote:


Actually, interestingly it seems like I am the only one here who in fact likes C++ as it is (except some quite small issues and the standard library, which IMO only looks like a good design).



Well, I agree that C++ *is* useful and *is* the only widespread system-wide programming language. But I really can't say that is a good language. Besides static memory management, which I prefere against a gc approach (I like do code what I want, not what the compiler want...), it contains really too many caveats dues mostly (but not all) because of compatibility issues.
It is :
- slow compiling
- not modular at all
- object model is missing too many useful stuffs (properties, delegates, a true rtti system, just among all)
- operator overloading is just awful, as is missing rvalue-lvalue different behaviour
- missing high-level types (strings, arrays.....)
- cumbersome templates
- no binary objects specifications... in particular with respect to to name mangling
- this damn'd preprocessor that does what he wants Twisted Evil
Just an example about this... on a really poorly written code :
#define a_type mytype
#define an_include </my/include/dir/a_type/mytype.hxx>
#define another_include "/my/include/dir/a_type/mytype.hxx"
#include an_include
#include another_include

That has the wonderful (sigh) result of :
#include </my/include/dir/mytype/mytype.hxx>
#include "/my/include/dir/a_type/mytype.hxx"

I stumbled about such a problem and it tooks half a day to understand that inside <> you have macro substitution, but inside "" not.... and I'm still not sure that it isn't a compiler behaviour.

IMHO, what we needs is a new system wide language, that maybe resembles to C++, but gets rid of all caveats and introduces the missing things. C++ is a language that, in order to be able to compile 1980's code is just becoming a monster and still missing what a modern oo language should have.

Ciao

Max
Re: C++ FQA [message #12587 is a reply to message #12579] Fri, 09 November 2007 14:48 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mdelfede wrote on Fri, 09 November 2007 07:41

luzr wrote on Fri, 09 November 2007 08:51


Well, but that is useful feature and this is one of things I like with C++ - the "default" mode is "safe", but you can always do dirty things when you need them.


no, here I don't agree.... such things make virtually impossible write 'safe' libraries. A 'const' should be a 'const', not a 'maybe const'.... as 'private' should be so, not a maybe one.
I've seen constructs like that :
#define private public
#include "alib.h"

just to overcome a private class declaration and access the low-level stuffs inside it.... Then, when library changes, people (maybe also people that hasn't nothing to do with such a hack) starts wondering why his program that up to the day before worked like a charm just crash. IMHO that has nothing to do with commercial-grade applications.



Sure, this is awful, but very often, the alternative is that it is not possible to finish your job.

Note that all these "high-level" language, whose propagators despise C/C++, have interfaces for these languages so that the dirty stuff can be done.

Quote:


well, a well written lib should do what the coder will, *not* what the user is missing. Before using C++ hacks to overcome libs limitations, you have 3 solutions :
1) Patch the sources, if you have them
2) Ask the original programmer to enhance the lib
3) Just find another lib that suit your needs



And if neither is possible? You quit the job?

Mirek
Re: C++ FQA [message #12588 is a reply to message #12587] Fri, 09 November 2007 15:52 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
luzr wrote on Fri, 09 November 2007 14:48



Sure, this is awful, but very often, the alternative is that it is not possible to finish your job.

Note that all these "high-level" language, whose propagators despise C/C++, have interfaces for these languages so that the dirty stuff can be done.



I'm not telling about 'make a new ""high level"" language, just speaking about making a system-level language more consistent and comfortable. Missing properties, delegates, right handling for rvalues-lvalues, awful macro language has *nothing* to do with the ability of doing system-level stuffs. GC is another matter but there I agree, i see GC as a way to do things without thinking, and has nothing to do with a language that has to be fast and real-time. Modularity also brings only advantages... so why not ? As I told in another thread, Borland did a great job with delphi, adding many useful extensions to pascal language, whithout loosing anything... better said, adding also the ability of low level machine access somewhere.
As an example, bring pick_ and reference counting inside the language would not break anything, if they're put as an option. The same for properties, delegates and some better handling of overloaded operators. Modularity should be not difficult too, it's just a matter of define a new object format that contains precompiled declarations too, as borland did with their packages for delphi. All that could stay side-by-side with actual c++ implementation.
Adding also a good string and array base types should not be a big problem too, and could also be much faster than actual template solutions.... so why not ?

Quote:


Quote:


well, a well written lib should do what the coder will, *not* what the user is missing. Before using C++ hacks to overcome libs limitations, you have 3 solutions :
1) Patch the sources, if you have them
2) Ask the original programmer to enhance the lib
3) Just find another lib that suit your needs



And if neither is possible? You quit the job?




Well, you must agree that the cases on which neither of the 3 solutions is possible are very rare... and yes, in such a case, I'd quit the job Very Happy

Ciao

Max

Re: C++ FQA [message #12589 is a reply to message #12588] Fri, 09 November 2007 17:07 Go to previous messageGo to next message
waxblood is currently offline  waxblood
Messages: 95
Registered: January 2007
Member
mdelfede wrote:

Quote:

#define private public
#include "alib.h"


Nice trick... I think I'll start using it..... Laughing


As for C++ language, I'd like much a 100% ansi-compliant C++ interpreter... Nowadays many people write their C++ programs and link them to some so-called scripting langauge (one for all: Python) to have more flexibility, but why can't I use C++ to perform the same task?

I've looked into cint
: while covers most (if not all) C, it is still at 85% of ansi c++, and the same authors say it will never reach the 100% goal. Sad


David
Re: C++ FQA [message #12593 is a reply to message #12589] Fri, 09 November 2007 19:51 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
waxblood wrote on Fri, 09 November 2007 17:07

mdelfede wrote:

Quote:

#define private public
#include "alib.h"


Nice trick... I think I'll start using it..... Laughing


eheheheheh

Quote:


As for C++ language, I'd like much a 100% ansi-compliant C++ interpreter... Nowadays many people write their C++ programs and link them to some so-called scripting langauge (one for all: Python) to have more flexibility, but why can't I use C++ to perform the same task?

I've looked into cint
: while covers most (if not all) C, it is still at 85% of ansi c++, and the same authors say it will never reach the 100% goal. Sad



If you need a nice scripting c-like language, there is also squirrel (www.squirrel-lang.org) that has some nice features.
Of course, is *not* ansi c++, but it has dynamic built-in structures that make it useful as a scripting lang.
Among others, it's used also on codeblocks scripting engine.

Ciao

Max

Re: C++ FQA [message #12603 is a reply to message #12588] Sat, 10 November 2007 15:14 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mdelfede wrote on Fri, 09 November 2007 09:52


Quote:


Quote:


well, a well written lib should do what the coder will, *not* what the user is missing. Before using C++ hacks to overcome libs limitations, you have 3 solutions :
1) Patch the sources, if you have them
2) Ask the original programmer to enhance the lib
3) Just find another lib that suit your needs



And if neither is possible? You quit the job?




Well, you must agree that the cases on which neither of the 3 solutions is possible are very rare... and yes, in such a case, I'd quit the job Very Happy

Ciao

Max




Interesting, I find them quite common. E.g. U++ has to use similar trick with X11, because X11 polutes the global namespace with too many simple names as "Font".

There it no chance Xlib.h being changed and in order to use X11, I cannot use different library. I cannot realistically patch the sources too. Or, BTW, you can consider that hackery as "patching sources from outside" Smile It is dirty, but at least it is possible.

Mirek

[Updated on: Sat, 10 November 2007 15:15]

Report message to a moderator

Re: C++ FQA [message #12604 is a reply to message #12588] Sat, 10 November 2007 15:22 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mdelfede wrote on Fri, 09 November 2007 09:52


As an example, bring pick_ and reference counting inside the language would not break anything, if they're put as an option. The same for properties, delegates and some better handling of overloaded operators.



Well, I guess they are reluctant to make already very complex language even more complex. And many of these issues do not bring anything really new to the table. (but I would certailny liked better syntax sugar for "pick_", this is the only thing in C++ I seriously miss).

Quote:


Modularity should be not difficult too, it's just a matter of define a new object format that contains precompiled declarations too, as borland did with their packages for delphi. All that could stay side-by-side with actual c++ implementation.



Well, but keep in mind that C++ *standard* is intended as multiplatform solution. It e.g. must not have anything in it preventing the use of language on platform that is only capable of working with 36 bit words...

What you demand is possible even now - there is nothing in C++ standard that would make it impossible for specific implementation.

Quote:


Adding also a good string and array base types should not be a big problem too, and could also be much faster than actual template solutions.... so why not ?



Or you would be stuck with slow implementation and no way how to improve it...

Mirek
Re: C++ FQA [message #12605 is a reply to message #12604] Sat, 10 November 2007 16:58 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
luzr wrote on Sat, 10 November 2007 15:22



Well, I guess they are reluctant to make already very complex language even more complex. And many of these issues do not bring anything really new to the table. (but I would certailny liked better syntax sugar for "pick_", this is the only thing in C++ I seriously miss).



Uhmmm.. they already made huge changes with templates, at least from the beginning of C++ standards... and other stuffs. pick_, refcounts and properties would *not* break existing code, so I really don't understand why they're not inside... in particular, properties do belong to a good OO language, and give absolutely no problem to existing code.

Quote:


Well, but keep in mind that C++ *standard* is intended as multiplatform solution. It e.g. must not have anything in it preventing the use of language on platform that is only capable of working with 36 bit words...

What you demand is possible even now - there is nothing in C++ standard that would make it impossible for specific implementation.


I know, but it wouldn't be standard. __property construct was added by borland to his C++ Builder, and effectively simplified much code writing. Also __published properties were a very good addition, as they brought good RTTI inside classes and made easy to write RAD tools.

Take in mind that C++ object files are, IMHO, *not* standardized, in particular with respect to code mangling... M$ has his one, borland another one and I guess GCC again a different one. So, it's impossible to link objs made with different C++ compilers, which was indeed possible with plain C. I think that was the real big problem of Borland tools... M$ came later, made worse compilers and made object files totally incompatible with borland ones.... so people that wanted to write code linking with M$ libs *had* to go to M$ tools.
That's again a big miss of C++ standart. So, what prevents put in C++ standard a documented obj format WITH module support ? That I don't really understand. It could also be done keeping the compatibility with old obj format (at least, on one compiler....).

Quote:


Or you would be stuck with slow implementation and no way how to improve it...



Well, here you must agree that bringing refcounts and/or pick_ INSIDE the language would make it possible compile-level optimizations that now are not possible. Of course, if you have a bad compiler that's slow, but that belongs to many other stuffs too.

Ciao

Max
Re: C++ FQA [message #12606 is a reply to message #12603] Sat, 10 November 2007 17:06 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
luzr wrote on Sat, 10 November 2007 15:14


Interesting, I find them quite common. E.g. U++ has to use similar trick with X11, because X11 polutes the global namespace with too many simple names as "Font".

There it no chance Xlib.h being changed and in order to use X11, I cannot use different library. I cannot realistically patch the sources too. Or, BTW, you can consider that hackery as "patching sources from outside" Smile It is dirty, but at least it is possible.



Well, I don't know what have you done (and why did you need to..) on respect to Xlib. I know that Xlib comes from old times and has old stuffs inside. But I think you could do it without hacks, of course that would have been more difficult to avoid name clashes and so. But IMHO, if you use undocumented features to ease your job, you're not guaranteed your app will work on next Xlib release. You'll loose control of your app, and so will do your customers. Your app will depend on 3dy part changes in code.
That's the same with the '#define private public' hack. You can access all level of foreign code, but you loose control on it.

Ciao

Max
Re: C++ FQA [message #12608 is a reply to message #12606] Sat, 10 November 2007 17:31 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
Well Delphi is really great. I used it for many years and I never understood why it wasn't used more extensively (especially now, that there is a free version available). And it is great that you can use it comfortably without templates and other stuff.

For those looking into Delphi and not afraid to experiment a little, here is a nice third party lib: http://kolmck.net/. It is as easy to use as the original, but it uses some very clever compiler and preprocessor tricks to obtain very small exe sizes. I saw an mp3 player and a zip extractor with about 100kb exe size. It's quite stable and bug free, but very hard to debug the sources of the lib.

And I'm quite surprised to see people who don't like gc, but have nothing against reference counting, which is slower and almost impossible to use efficiently in a multi-threading application.
Re: C++ FQA [message #12613 is a reply to message #12608] Sat, 10 November 2007 17:54 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
cbpporter wrote on Sat, 10 November 2007 11:31


And I'm quite surprised to see people who don't like gc, but have nothing against reference counting, which is slower and almost impossible to use efficiently in a multi-threading application.



I mostly agree with this...

Mirek
Re: C++ FQA [message #12615 is a reply to message #12515] Sat, 10 November 2007 22:26 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 825
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor
Excuse me for my blatant ignorance, but the last time I was checking GC inner working they were pretty much all based upon ref counting.

They did either evolve great deal since I take that fast glance on them (quite possible), or by using GC you get everything ref counted by default.

In the latter case I don't understand this thing at all:
Quote:

And I'm quite surprised to see people who don't like gc, but have nothing against reference counting, which is slower


Please, don't send me links on the modern GC designs, just tell me I'm wrong and miss some centuries of evolution. Very Happy
(I will maybe check the modern GC design later, right now I have more important things to do. Sad )
Re: C++ FQA [message #12616 is a reply to message #12615] Sat, 10 November 2007 22:35 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mr_ped wrote on Sat, 10 November 2007 16:26

Excuse me for my blatant ignorance, but the last time I was checking GC inner working they were pretty much all based upon ref counting.



Nope, real GC cannot be based on ref counting - that does not solve the circular references.

Quote:


They did either evolve great deal since I take that fast glance on them (quite possible), or by using GC you get everything ref counted by default.



Real GC is based on mark&sweep algorithm. Google it Smile

Mirek
Re: C++ FQA [message #12618 is a reply to message #12613] Sat, 10 November 2007 23:57 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
luzr wrote on Sat, 10 November 2007 17:54

cbpporter wrote on Sat, 10 November 2007 11:31


And I'm quite surprised to see people who don't like gc, but have nothing against reference counting, which is slower and almost impossible to use efficiently in a multi-threading application.



I mostly agree with this...




As with GC, refcount can be made thread safe, IMHO.
And, as GC, it can be made more or less efficient code.
Even pick_ can be not thread safe, if it's bad coded, and must have some sort of synchronizing code to be thread safe. Of course, the 'blocking' code in pick_ should be a bit less than in refcount, and (I guess) much less than in GC.
Even copying a whole array can be a big problem in multithreading stuff, and can become slow.
At least, refcount (and GC) can be made thread safe by design, without requiring additional sync code by user program; new(), delete() and malloc() and manual memory management requires thread safe stuffs in user code. Of course they CAN be faster, but more error-prone too.
I *don't* like GC, but only because I want to know when memory is being freed; I *do* like refcount because gives you some coding comfort without too much performance penalty; pick_ gives you less code comfort with best performance, and has great advantage over more manual stuff that gives you an error if you access picked objects.

That said, GC is nothing modern, lisp has it since before 1980, and also appleII pc with its basic had it, awfully slow, too, for string management. If I remember well, some GC have a mix of refcount AND other stuffs to solve circular references, but I'm not sure. It could be made working with refcounts, some linked list stuff and the GC traversing them to solve circular refs, at a cost of performance.

I would not accept a language based mostly on GC, but I've got nothing against an optional gc among other management stuffs.

BTW, I can't see how refcount can be slower than GC... maybe I'm wrong, but I'd like to have it explained !

ciao

Max

[Updated on: Sun, 11 November 2007 00:00]

Report message to a moderator

Re: C++ FQA [message #12621 is a reply to message #12618] Sun, 11 November 2007 09:54 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
mdelfede wrote on Sat, 10 November 2007 17:57

luzr wrote on Sat, 10 November 2007 17:54

cbpporter wrote on Sat, 10 November 2007 11:31


And I'm quite surprised to see people who don't like gc, but have nothing against reference counting, which is slower and almost impossible to use efficiently in a multi-threading application.



I mostly agree with this...




As with GC, refcount can be made thread safe, IMHO.



The things is that even thread unsafe reference counting is about as fast or slower than mark&sweep GC.

And, w.r.t. thread safety, the another trouble is that you cannot safely use atomic operations only when the object is really shared between threads (when it is needed).

Quote:


Even pick_ can be not thread safe, if it's bad coded, and must have some sort of synchronizing code to be thread safe.



Everything can be thread unsafe if you really try. Anyway, the simplest pick_ implementation is naturaly thread safe.

Quote:


I would not accept a language based mostly on GC, but I've got nothing against an optional gc among other management stuffs.



The problem is that this is not quite possible.

Quote:


BTW, I can't see how refcount can be slower than GC... maybe I'm wrong, but I'd like to have it explained !



OK, only think about the amount of operations that have to be performed in simple "return the value" scenario

RefCounted<Foo> Fn() {
   RefCounted<Foo> x = new Foo;
   .....
   return x;
}

void Fn2() {
   RefCounted<Foo> y = new Foo;
   ...
   y = Fn();
}


Mirek
Re: C++ FQA [message #12622 is a reply to message #12621] Sun, 11 November 2007 11:25 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
luzr wrote on Sun, 11 November 2007 09:54

mdelfede wrote on Sat, 10 November 2007 17:57

luzr wrote on Sat, 10 November 2007 17:54

cbpporter wrote on Sat, 10 November 2007 11:31


And I'm quite surprised to see people who don't like gc, but have nothing against reference counting, which is slower and almost impossible to use efficiently in a multi-threading application.



I mostly agree with this...




As with GC, refcount can be made thread safe, IMHO.



The things is that even thread unsafe reference counting is about as fast or slower than mark&sweep GC.


Well, here that depends on *what* do you mean with 'faster'.
Let's speak for example about linux kernels, the normal one and the low-latency one. Which is faster ? That depends on what do you mean! Low latency kernel responds faster than normal one, but in overall time it is slower. The normal kernel can have troubles with real-time apps, but is overall faster.
So, refcount DOES add overhead on allocation operations, so for the single op IS slower than GC. But, when GC comes in place, you do have a long latency. In overall application time, GC is of course faster than many refcount ops.... with the counterpart of some 'program stops' during GC. In conclusion :
GC is faster in overall app time, and is faster on single memory operation, BUT it has the big problem of GC stop time
Refcount is slower on single memory ops, is slower globally BUT has no stop times and it's execution is smoother.
If you don't need real-time response, GC is better, otherwise can be very bad.
The big problem, as you say here later, is that is very difficult to use other memory allocations in conjunction with GC.

Quote:


And, w.r.t. thread safety, the another trouble is that you cannot safely use atomic operations only when the object is really shared between threads (when it is needed).


I didn't understand that one... Sad

Quote:


Quote:


Even pick_ can be not thread safe, if it's bad coded, and must have some sort of synchronizing code to be thread safe.



Everything can be thread unsafe if you really try. Anyway, the simplest pick_ implementation is naturaly thread safe.


Let's say that pick_ is very easy to make thread safe stuff

Quote:


Quote:


I would not accept a language based mostly on GC, but I've got nothing against an optional gc among other management stuffs.



The problem is that this is not quite possible.


I agree with this one... mostly. That's why I don't like GC.

And, in conclusion, I agree with you that pick_ is the best when you don't need a true object copy, or even when you do need it but you're ready to think much on what your code will do.
Refcount lets you to 'turn brain off', you must not bother about what your code will do with your object, mostly. So, less error prone. GC is the best for 'lazy people', it does all the dirty job but it leads often to slow apps... because people start allocating hundreds of objects on the fly without thinking about optimization.

Ciao

Max
Re: C++ FQA [message #12623 is a reply to message #12608] Sun, 11 November 2007 11:36 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
cbpporter wrote on Sat, 10 November 2007 17:31

Well Delphi is really great. I used it for many years and I never understood why it wasn't used more extensively (especially now, that there is a free version available). And it is great that you can use it comfortably without templates and other stuff.


I think that real problem on Delphi and even CBuilder where the binary incompatibility with M$ ones. You could *not* link a delphi or BC++ app with M$ libs, or even (and that's the real bad) with C++ DLL without huge efforts. I made many apps in BC++ builder to extend Autocad, and I could not use ARX internals because of code mangling incompatibility. I resorted about a COM app embedded with the use of some hacks calling 2-3 funcs of ARX internals, just translating the mangling schemas between compilers... a cumbersome work, and those were only 2-3 funcs to call, not the 1000+ of the whole stuff.
Borland should have taken the decision to make its binaries compatible with the (whorse) M$ one in order to stay on the market... but they didn't.
Re: C++ FQA [message #12626 is a reply to message #12623] Sun, 11 November 2007 18:22 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

For me, main BC++B problems were:
1) Compiler errors and IDE issues (buggy IDE and debugger Razz )
2) Ineffective and poor framework (even that was much better than MFC) which wasn`t really upgraded since smth like 1997-1999 (leading VCL developer was bought by M$ for .NET platform).
3) Wrong development direction: since first versions BC++B was strongly modified for database applications against the interest of all others.
Re: C++ FQA [message #12631 is a reply to message #12626] Sun, 11 November 2007 18:52 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Mindtraveller wrote on Sun, 11 November 2007 18:22

For me, main BC++B problems were:
1) Compiler errors and IDE issues (buggy IDE and debugger Razz )


well, not too many bugs... often less than M$ counterparts.
It was quite usable.

Quote:


2) Ineffective and poor framework (even that was much better than MFC) which wasn`t really upgraded since smth like 1997-1999 (leading VCL developer was bought by M$ for .NET platform).


well, IMHO not so ineffective nor poor... at least, an order of magnitude better than M$ one.

Quote:


3) Wrong development direction: since first versions BC++B was strongly modified for database applications against the interest of all others.


That depends on what you code... I don't like database apps, too, but if they did so, maybe it was for some reason.
Re: C++ FQA [message #12642 is a reply to message #12631] Mon, 12 November 2007 00:58 Go to previous messageGo to previous message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

mdelfede

not too many bugs... often less than M$ counterparts.
It was quite usable.

I`ve used BCB until this autumn, when I found U++. And I had problems with it`s bug. The worst compiler bug is that it sometimes ignores source code line next to the "}". Also, debugging multithreaded applications frequently lead BCB IDE to hang. There are more some critical bugs and issues. VCL also may show different behaviour on Win98 and WinXP systems with the same code (ini files, etc).

mdelfede

not so ineffective nor poor... at least, an order of magnitude better than M$ one.
Yes, as I mentioned, it`s much better than MFC and much more lightweight than .NET.
My common BCB application has something like 30% of code with Win32 API calls (threads and core objects, serial i/o, grid cells drawing, advanced registry work, ...). This shows for me that VCL is rather poor when we discuss what we can do with it. Yes, it`s much-much more than nothing but it is still insufficient.
Again VCL is good, it was wonderful back in 90-s, but now after so much time passed, Borland could do much, but they didn`t.
So VCL is still a pascal-derived library, ignoring most of C++ features.
So, adding notes about efficiency, do you know how VCL handles it`s forms? Forms and components are converted to textual representation. The borland IDE gives text to linker, which adds these text resources to the end of .exe files. When you start any BCB application, it runs special parser (which is by default in dll!). Text resources are parsed. How? Application gives this text to internal engine, then to newly-created components which serialize their properties from text parts. That is how BCB application starts.
Also, BCB has it`s own memory manager which gives you something like 1Mb-size pool for variables. And there is no way to switch to any other memory manager, as soon as you use VCL components or even VCL strings.
The greatest issue for me personally is that IDE "insists" on the only one programming style. More your application uses VCL forms and components, more time you must spend making your code the way you need, not BCB IDE. For example, BCB makes you having all your form and component event handler in one file. Even when they are logically belong to very different parts of program logics (different classes).
And, yes, it`s .lib files are incompatible with Microsoft ones. The utility for coversion (implib) isn`t that good also.
Isn`t that enough? I can count more critical issues if it`s not clearly fow now. All I say is that VCL was good in 90-s, but it was abandoned by Borland. VCL had to be improved, upgraded, optimized for general-purpose applications. Then - for specific needs. It had a chance to become much more popular than M$ thumb "framework" like MFC.

mdelfede

I don't like database apps, too, but if they did so, maybe it was for some reason.
They thought that their reason was serious enough and they lost. BCB is nearly dead for last years and according to the information I have, Borland`s made a decision to abandon VCL completely, switching all development to QT or .NET.
Previous Topic: Tools or methodologies you use when developing software
Next Topic: About vista....
Goto Forum:
  


Current Time: Thu Mar 28 10:45:25 CET 2024

Total time taken to generate the page: 0.02685 seconds