Home » Community » Coffee corner » C++ FQA
|
|
| Re: C++ FQA [message #12518 is a reply to message #12515] |
Wed, 07 November 2007 00:41   |
Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
|
Experienced Contributor |
|
|
Yes, this FQA led into massive discussion in Russian livejournal segment (more than 250 answers). I`d conclude the discussion mentioned this way: "Yes, C++ may sometimes be difficult as hell and it makes possible writing horrible code, yes there are many other problems with it. But as soon as we don`t have ANOTHER language accumulating all the might of OOP/FP along with C-like performance - C++ will live." (c)
P.S. Some time ago I`ve spent some hours learning new Pascal-languages branch: Oberon, Oberon-2, Zonnon. These are interesting things but, comparing to C++, they lack of some important abilities.
Also I`ve proposed graphical approach for creating programs, but was crucified with other massive livejournal discussion.
So, I would say for now we do not have any adequate alternatives for C++.
[Updated on: Wed, 07 November 2007 00:49] Report message to a moderator |
|
|
|
|
|
| Re: C++ FQA [message #12522 is a reply to message #12521] |
Wed, 07 November 2007 11:33 |
cbpporter
Messages: 1428
Registered: September 2007
|
Ultimate Contributor |
|
|
I've read a good deal of the FQA (and the FAQ too) and while it is mostly right, it is also strongly biased. It still makes a point though, and I think a lot of people agree that C++ is too complicated for it's and everybody else's sake. I would love for an alternative, something that is more simple, straight-forward, but still powerful.
Right now D could be the only alternative (C++0x is even more complicated and redundant). I used D for 2500+ line project (which in C++ would have been about 4000-5000 lines) with about 20 files and I think I have a pretty good idea of what it can do. It has some strong points:
1. True module support.
No more including hundreds of kilobytes if not megabytes of header files in each compilation unit. No more writing every ddecalration twice. Modules act like Java packages, can be fully qualified to avoid name clashes and can be combined to create a library with different access levels. And because each module is compiled only once, D is lightning fast. My entire project compiled from scratch almost instantly, and if I only modified the content of a function or other miner detail, truly instantly.
2. A lot of built in features, like variable length array and hash maps, which combined with some extra functions, can be used to create types like Vector or Map, but even more easy to use and without templates. char[] and about 10 extra functions could make String and StringBuffer obsolete.
3. Templates + mixins + static ifs are stronger than templates in C++ + preprocessor. I never used them, because you can do in D a lot more without templates than in C++.
4. Optional (but defaulted to true) garbage collection.
As much as you could dislike the idea of garbage collection, memory management in C++ is a nightmare, and from this point of view, even U++ which has a lot less such issues, is not able to give such pain free management.
But is also has some disadvantages. Mostly because it has been branched to D 1.0, which is stable, and 2.0 which is a moving target, is not compatible with 1.0, and is a little more complex. It introduces const correctness as in C++, but D can live a lot easier without such extra access methods to have to deal with. Also, the standard library is widely disliked, and a third party library has been created, which is pretty good (even though a little to C++ style), but cross linking between the libraries is impossible. Also operator overloading is just a little bit less powerful.
Still, it is quite a good programing language, having a lot of pain free features and performance comparable to C/C++. I would love to see such a great GUI library as U++ for D, and I'm sure it will continue to evolve.
|
|
|
|
| Re: C++ FQA [message #12523 is a reply to message #12522] |
Wed, 07 November 2007 13:15 |
|
|
| Quote: |
1. True module support.
No more including hundreds of kilobytes if not megabytes of header files in each compilation unit. No more writing every ddecalration twice. Modules act like Java packages, can be fully qualified to avoid name clashes and can be combined to create a library with different access levels. And because each module is compiled only once, D is lightning fast. My entire project compiled from scratch almost instantly, and if I only modified the content of a function or other miner detail, truly instantly.
|
Yeah, I like it too but there is a paper about modules in new C++ too http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n207 3.pdf . I do not know how much similar (or not) they are to D modules but it seems to be a step in the right direction.
| Quote: |
2. A lot of built in features, like variable length array and hash maps, which combined with some extra functions, can be used to create types like Vector or Map, but even more easy to use and without templates. char[] and about 10 extra functions could make String and StringBuffer obsolete.
|
True. But I remember that D-people wanted to have String class. I prefere it too even if bulit-in char type is powerful and easy to use.
| Quote: |
3. Templates + mixins + static ifs are stronger than templates in C++ + preprocessor. I never used them, because you can do in D a lot more without templates than in C++.
|
Yes, some D coders (like Don Clugston for example) proved they are much more powerful than C++ ones.
| Quote: |
4. Optional (but defaulted to true) garbage collection.
As much as you could dislike the idea of garbage collection, memory management in C++ is a nightmare, and from this point of view, even U++ which has a lot less such issues, is not able to give such pain free management.
|
I prefer RAII approach and U++ is a very good example that this really works. Frankly if you use NTL or STL (and follow the RAII way) there is a rare situation when you have to worry about memory management. I don't know why this still is an issue.
D uses GC but fortunately it allows for deterministic destruction in "scope classes". At least in theory  Must check it.
I think new C++ should break compatibility and be more like D. I don't understand why it cannot be since all current/old apps can be developed with old compilers. This way C++ will be fatter and fatter (and more complicated) with each standard revision.
[Updated on: Wed, 07 November 2007 13:30] Report message to a moderator |
|
|
|
| Re: C++ FQA [message #12524 is a reply to message #12523] |
Wed, 07 November 2007 14:03 |
Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
|
Experienced Contributor |
|
|
Talking about D, are there any comparisons in exe size / execution speed of the same code for C++ and D?
Again, I just don`t like an idea of uncontrolled garbage collection. Developing some time-cricical programms for industrial automation, I dislike the fact that my time-critical code can be interrupted or slowned down by some uncontrolled process of garbage collection.
[Updated on: Wed, 07 November 2007 14:11] Report message to a moderator |
|
|
|
| Re: C++ FQA [message #12526 is a reply to message #12524] |
Wed, 07 November 2007 14:57 |
cbpporter
Messages: 1428
Registered: September 2007
|
Ultimate Contributor |
|
|
| Quote: |
I think new C++ should break compatibility and be more like D. I don't understand why it cannot be since all current/old apps can be developed with old compilers. This way C++ will be fatter and fatter (and more complicated) with each standard revision.
|
That sound great and is pretty similar with the modules from D, with the only difference that they are already present in D, and by the time these features will be included in C, we'll all be retired programmers. I hate to be pessimistic, but if history has though us anything is that those behind C++ are a bunch of close minded people who have no intention to break compatibility and will gladly bloat the language with absolutely retarded and redundant features. Just have a look at C++0x, and see that most stuff just tries to fix old problems with new redundant features and by keeping the old ones. And even if they do introduce modules, by the time there will be a compliant compiler, I hope that C++ will be less popular for real-life application development.
| Quote: |
I prefer RAII approach and U++ is a very good example that this really works. Frankly if you use NTL or STL (and follow the RAII way) there is a rare situation when you have to worry about memory management. I don't know why this still is an issue.
|
It's probably because I'm not as skilled with high level C++ features, but the issues with memory management are quite present for me in U++.
While the language has deep copy, value references, copy constructors, etc., I think that it is impossible not to have such issues. And in U++ I spend a great deal of time just messing with const correctness and other low level details which I shouldn't be forced to worry about.
| Quote: |
Again, I just don`t like an idea of uncontrolled garbage collection. Developing some time-cricical programms for industrial automation, I dislike the fact that my time-critical code can be interrupted or slowned down by some uncontrolled process of garbage collection.
|
Well in D you can always chose not to use garbage collection for a class or even just a part of your code. You can use C style pointers, and even call malloc if there is a need to. But I consider this some kind of a myth. Has there been a documented case where garbage collection had serious impact on performance. It is true that such applications sometimes have the bad habit of hanging for 2-3 seconds when a garbage collection cycle starts, but this shouldn't be an issue in non GUI applications. And U++ and even STL does a lot of "garbage collection", only it is more deterministic, but not necessarily faster.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: C++ FQA [message #12539 is a reply to message #12535] |
Thu, 08 November 2007 00:13 |
Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
|
Experienced Contributor |
|
|
| cbpporter |
They are by far not uncontrolable, and only happen in some apps.
|
OK, as a developer who likes D programming paradigm, and who wants writing efficient applications, I will consider changing language to D if
1) There`s a simple way to guarantee no hangups at all.
2) My .exe will be <10%-15% slower than corresponding C++ code in any case.
These are critical conditions. Can D, or any other alternative fit?
P.S. luzr, I just thought that D and U++ comparison is not quite honest. It would be better to compare internal language features of D and C++. According to the tests described in D site (I looked at them as you recommended), D is no slower than C++ (at least in some cases?). So porting the U++ classes and algorithms to D, adopting them for D specifics could make U+D (U++ for D) as fast as original U++. It`s just a theory, of course.
[Updated on: Thu, 08 November 2007 00:20] Report message to a moderator |
|
|
|
|
|
| Re: C++ FQA [message #12543 is a reply to message #12539] |
Thu, 08 November 2007 05:34 |
 |
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
| Mindtraveller wrote on Wed, 07 November 2007 18:13 |
| cbpporter |
They are by far not uncontrolable, and only happen in some apps.
|
OK, as a developer who likes D programming paradigm, and who wants writing efficient applications, I will consider changing language to D if
1) There`s a simple way to guarantee no hangups at all.
2) My .exe will be <10%-15% slower than corresponding C++ code in any case.
|
3) Add to mix memory requirements. In that "Alice" benchmark, D used about 2-3 times more memory than U++ (if I remember well).
BTW, it is some time when I last tried it. I would really be very glad if somebody reproduced my results; here is U++ code:
#include <Core/Core.h>
using namespace Upp;
#define BENCHMARK // for benchmark purposes, output is omitted
#ifdef BENCHMARK
#define BENCHBEG for(int i = 0; i < 1000; i++) {
#define BENCHEND }
#else
#define BENCHBEG
#define BENCHEND
#endif
void main(int argc, const char *argv[])
{
VectorMap<String, int> map;
BENCHBEG
for(int i = 1; i < argc; i++) {
String f = LoadFile(argv[i]);
int line = 1;
const char *q = f;
for(;;) {
int c = *q;
if(IsAlpha(c)) {
const char *b = q++;
while(IsAlNum(*q)) q++;
map.GetAdd(String(b, q), 0)++;
}
else {
if(!c) break;
if(c == '\n')
++line;
q++;
}
}
}
BENCHEND
Vector<int> order = GetSortOrder(map.GetKeys());
#ifndef BENCHMARK
for(int i = 0; i < order.GetCount(); i++)
Cout() << map.GetKey(order[i]) << ": " << map[order[i]] << '\n';
#endif
printf("%d\n", map.GetCount());
}
(I had to loop over it more times, otherwise the execution for Alice.txt was too fast to be measurable).
| Quote: |
P.S. luzr, I just thought that D and U++ comparison is not quite honest. It would be better to compare internal language features of D and C++. According to the tests described in D site (I looked at them as you recommended), D is no slower than C++ (at least in some cases?). So porting the U++ classes and algorithms to D, adopting them for D specifics could make U+D (U++ for D) as fast as original U++. It`s just a theory, of course.
|
I think this is not quite possible, as language features are way too different.
OTOH, in this particular benchmark, D is using internal language features, while C++/U++ is using library. Still, we are faster and the code is shorter. That IMO says a lot about language flexibility.
Mirek
|
|
|
|
| Re: C++ FQA [message #12546 is a reply to message #12539] |
Thu, 08 November 2007 13:33 |
Zardos
Messages: 62
Registered: April 2007
|
Member |
|
|
| Mindtraveller wrote on Thu, 08 November 2007 00:13 |
OK, as a developer who likes D programming paradigm, and who wants writing efficient applications, I will consider changing language to D if
1) There`s a simple way to guarantee no hangups at all.
2) My .exe will be <10%-15% slower than corresponding C++ code in any case.
These are critical conditions. Can D, or any other alternative fit?
|
I switched from D to UPP because:
D uses an old object format which makes it impossible to link you d programs with ordinary c libraries. You have to compile the c libraries with digital mars c. Or you have to use some convertes which converts the libs in the old format
Lack of D libraries: While I was in the language - D was an constant moving target. Every weekly new version broke your code (and the code of the libraries)
No professional GUI library available. Well you could build one of you own.. But see the point above.
Performance: Some D code compiles to very efficient code. Sometimes even better than MSVC, but some parts are unacceptable slow. For example the built in associative arrays are horrible slow. ...And you can not fix this by fixing the library, because they are really built into the language
Garbage collection: Even if the last version of the grabage collection is less conservative it is still a conservative garbage collection. -> See Mireks comment.
No useful IDE with integrated dubugger avilable. Productivity is not only related to the language...
And I completely lost interest of the language at the time when Walter decided to at CONST to the language (currently only in the development branch). Well he claims "you don't have to use it..." but I doubt this. I expect a similar disaster as in C++: Add one const and the source is infected...
IMHO C++ sucks. But I don't see a serious choice for my requirements. UPP showed me again that you can ship (most times) around the flaws of C++...
But I'm still dreaming of a language like D without the shortcomings. May be compiled to C++ in the first incarnation to make all C++ libraries available automatically?
So don't get me wrong. I think D is really great (except of the added const). It has fantastic template and meta programming capabilities and its design is clean and ellegant. It has all the state of the art constructs you would expect from a modern language...
[Updated on: Thu, 08 November 2007 14:01] Report message to a moderator |
|
|
|
|
|
|
|
| Re: C++ FQA [message #12558 is a reply to message #12556] |
Fri, 09 November 2007 08:51 |
|
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
| mdelfede wrote on Thu, 08 November 2007 17:39 |
| luzr wrote on Thu, 08 November 2007 19:25 |
Well, as of const, I generally tend to thing that while initially it feels like plague, after a while you can find it quite useful, at least to describe the interface better.
Been through it ages ago....
|
me too.... at the beginning I found it boring and ennoying stuff, now I find it very useful. The bad thing is that c++ allow you to recast const to non-const... so a badly written library can do what he wants.
Max
|
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.
In other words, you can also say that a well written library can do what it needs 
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).
Mirek
|
|
|
|
| Re: C++ FQA [message #12576 is a reply to message #12515] |
Fri, 09 November 2007 12:56 |
 |
tvanriper
Messages: 85
Registered: September 2007
Location: Germantown, MD, USA
|
Member |
|
|
Actually, I rather like C++ as it is, too.
But then, after having worked with it for so many years, I'm maybe rather comfortable with it, enough to make it do pretty much whatever I want.
I don't want a language that coddles me (by trying to prevent me from doing something dumb), but I also don't want to deal with machine-code. I want something that can scale, but let me deal with the bit-twiddling details if necessary. C++ provides all of this for me.
And, most of the time, if I've found my application is starting to look a little wordy, it's probably because of a bad design.
This isn't to say that I'm not intrigued by some of the other developments I've heard about in C++0x and others, but I'm happy with C++ as it is.
C++0x, if I recall, is really an attempt to make the language easier to handle for folks new to the language. As such, at this point in my life, I have no need for it.
I haven't really looked deeply into D, so I can't really comment on it, except to say that I haven't met a lot of people who know how to program in D, so commercial projects written in D would require a very special person to maintain it, which could drive up costs. I might consider writing fun stuff with D, but until the language becomes more mainstream, I'd hesitate to use it for work that provides me with a paycheck.
|
|
|
|
| Re: C++ FQA [message #12579 is a reply to message #12558] |
Fri, 09 November 2007 13:41 |
mdelfede
Messages: 1310
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: 14290
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: 1310
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: 1310
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: 14290
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: 14290
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: 1310
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: 1310
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: 1310
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: 14290
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: 1310
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: Wed Apr 29 10:30:11 GMT+2 2026
Total time taken to generate the page: 0.01979 seconds
|
U++ framework
Search
Help
Members
Register
Login
Home
)
