future of the C++
in [C++]
|
Prev: Generating a derived class from a base class
Next: Why is the return type of count_if() "signed" rather than "unsigned"?
From: Mathias Gaunard on 5 Jul 2010 23:45 On Jul 6, 2:50 am, Andre Kaufmann <akfmn...(a)t-online.de> wrote: > I don't know why B.S. has chosen to let macros propagate over header > file boundaries. You mean you would like that, when you #include a file, the current context doesn't get transported to the processing of the included file? That sounds like not such a bad idea, but wouldn't that prevent the preprocessor to be used for loops? -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andre Kaufmann on 6 Jul 2010 04:18 joe wrote: > Andre Kaufmann wrote: >> Agreed, C# and Java strings are not perfect, but better than C++ >> standard strings regarding Unicode. I think C# has been influenced by >> Windows Unicode support. >> > > What is wrong with fixed-width Unicode (UCS-2 or UCS-4)? If someone has > put those out in the dumpster, then I'm a garbage-picker! You make it > sound like fixed-width is evil. Do tell what you think/are thinking! I don't think it is evil, have I stated that ? -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: nmm1 on 6 Jul 2010 04:12 In article <i0tdt0$1j5$1(a)speranza.aioe.org>, Dragan Milenkovic <dragan(a)plusplus.rs> wrote: >Walter Bright wrote: >[snip] >> Because of this, I suspect that trying to use purity and immutability >> purely by >> convention is doomed to failure. >> >> (And also, since the compiler cannot know about its purity and >> immutability, it >> also cannot take any advantage of that information to produce better >> code. The >> compiler cannot even cache pointer to const values.) > >GCC provides attributes "pure" and "const" which indeed allow >taking advantage. However, it seems that it doesn't verify >the correctness of implementation. I don't know how easy such >a feature could be added (my guess is not too hard), >and whether it would be beneficial. It would be diabolical, starting from here, though very beneficial. Fortran has done it, but doesn't have the same problems that C++ does. The first point is to decide what purity means - and that's not obvious, even at the hardware level! For example, floating-point is not strictly pure once you allow IEEE 754 exception flags or even (God help us!) fixup by interrupt. Not a C++ problem today, but becomes one in C++0X. Most of the C++ library could be defined as pure or impure, but there would be screams from implementors who did things differently. And there are a lot of borderline cases in the inherited C library. POSIX massively increases the confusion, of course :-( And then there is the dreaded exception question. Does the licence to raise an exception destroy purity? If so, the previous questions more-or-less state that nothing non-trivial can be pure. But, if not, some extremely careful design is needed to avoid making the concept meaningless. Regards, Nick Maclaren. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andre Kaufmann on 6 Jul 2010 04:18 Dragan Milenkovic wrote: > Andre Kaufmann wrote: > [...] > GCC features precompiled headers for C++. I believe it solves Most C++ compilers have that feature. It helps to speed up compilation. But anyways I think it fights only symptoms. > all mentioned problems. But what _I_ want is to remove private: > part from the header :-D Seriously now, a smart pointer field > [...] > IMHO, a C++ developer does not decouple code manually to prevent > recompilation, but for the purposes of modularity, maintenance, > good design, etc. Templates do make a nice mess, however. I use pimpl frequently too, but still have the odd feeling I do something the compiler could do by itself. I agree that a small (pimpl) interface looks fine, but I have manually implement the same functions multiple times (depends on the pimpl variant) to call internal functions of a pimpl class or access private data through a pointer. To your arguments: modularity: Does it really decouple the sources on a module basis. E.g. that the header and cpp file can be moved to another project ? To get a true separated "module" IMHO the #include instructions have to be removed completely. Otherwise the sources are still coupled - aren't they ? And try to decouple pimpl code with template code ;-) maintenance: At first you have to invest more time to implement pimpl. I agree that pimpl helps to maintain big C++ projects much better additionally it speeds up compilation speed. But I think most problems wouldn't occur with C++ modules. good design: Decoupling forces a better design, because the developer has to think about dependencies. But IMHO that can be done without having to manually decouple code via pimpl. Basically pimpl is IMHO not a good OO design, but enforces it somewhat. > Modules should interact by the means of interfaces. I don't see > any problem with this and nothing to improve. In your case a) No difference if templates are used or not b) Single unit file, which helps to maintain code modules / projects c) You can extract/separate modules more easily, since the dependency tree is reduced to single #import instructions -> tools can easily track dependencies d) Decoupling is commonly not needed, but there's no restriction to do it anyway, either in a single unit or by using the old header file model >[...] > One question - how do D modules get along with templates? Don't know the internals. But I don't think there is a huge difference between code modules and template modules, besides that the compiler has to generate code, instead of just "include the interface". Perhaps W.Bright can shed some light on this ? -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andre Kaufmann on 6 Jul 2010 04:19
ThosRTanner wrote: > On Jul 6, 2:50 am, Andre Kaufmann <akfmn...(a)t-online.de> wrote: > > <snip> > >> And with a two pass compiler (like C#) you don't even have to include >> anything. The compiler just does want it should do - compile the code. >> >> (Disclaimer: I once thought header files and preprocessor to be a good >> design decision too - now I think just the opposite) > > I think this would be a bad thing. With a 2 pass compiler, rather than > separate headers (or at least interfaces) and implementation, if you > alter the implementation, you need to recompile the clients. Yes, but a) If development/compilation would be 1000 times faster, I wouldn't care b) You can still decouple modules, by creating some kind of libraries. Therefore only a small part would be triggered for recompilation. > > That's really bad (IMHO, YMMV, etc) Just as bad as a template code file which is used throughout the project ;-) Do you wonder too, why people try that hard to find arguments why something new won't work, but don't think that much about "how it could be done better", without introducing new problems ? E.g. how the compiler could keep track of changes and dependencies to prevent complete recompilation. > One of the problems with C++ is that you don't really implement an > interface. Instead you provide a header file which is part > implementation, part private data, and part interface. This has the > mildly unfortunate side effect that your clients can be dependent on > your private data. pimpl alleviates that at the header level, but not > at the implementation level. Yes. But who does care about private data dependencies ? It should be a single module, which depends on other modules. In other languages there aren't problems too, I think in C++ we are just used to this model and think it's just the best. Would it be that bad to have another option in C++ ? -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |