Home » Community » Coffee corner » C++ FQA
| Re: C++ FQA [message #12579 is a reply to message #12558] |
Fri, 09 November 2007 13:41   |
mdelfede
Messages: 1308
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 
|
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 
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 |
 |
mirek
Messages: 14257
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 |
mdelfede
Messages: 1308
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 
Ciao
Max
|
|
|
|
|
|
| Re: C++ FQA [message #12593 is a reply to message #12589] |
Fri, 09 November 2007 19:51 |
mdelfede
Messages: 1308
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..... 
|
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. 
|
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 |
|
mirek
Messages: 14257
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
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" 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 |
|
mirek
Messages: 14257
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 |
mdelfede
Messages: 1308
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 |
mdelfede
Messages: 1308
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" 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 #12618 is a reply to message #12613] |
Sat, 10 November 2007 23:57 |
mdelfede
Messages: 1308
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 |
|
mirek
Messages: 14257
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 |
mdelfede
Messages: 1308
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...
| 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 #12642 is a reply to message #12631] |
Mon, 12 November 2007 00:58 |
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.
|
|
|
|
Goto Forum:
Current Time: Sun May 11 17:31:21 CEST 2025
Total time taken to generate the page: 0.04188 seconds
|
Members
Pages
Help
Register
Login
Home
)
