İLERİ DANİSMANLİK'TAN KOBİ'LERE DESTEK
İLERİ DANİSMANLİK'TAN KOBİLE'RE MALİ DANİSMANLİK HİZMETİ KOBİ'lere Mali Danışmanlık hizmeti! Avukatlara ve Mali Müşavirlere dosya hazırlıkta destek! Tüm hizmetlerimiz için web sitemizi ziyaret ediniz. www.ileridanismanlikhizmetleri.com Vergi Davaları Uzlaşma Vergi Suçları İflasın Ertelenmesinde İyileştirme Projesi Yargıtay ve Danıştay Kararları Hukuk Davaları Ceza Davaları Destek hizmetlerimiz için kapsamlı bir bilgi bankası oluşturduk. Hizmetlerimize ulaşmak için tıklayınız. www.ileridanismanlikhizmetleri.com Mail Listemizden Çıkmak İstiyorsanız Bu maili Yanıtlayarak çıkmak istediğinizi belirtebilir yada boş mail atabilirsiniz. İleri Danışmanlık Hizmetleri www.ilerdanismanlikhizmetleri.com ye...@ileridanismanlikhizmetleri.com
Re: Proposal for automatic generation of c++ header files
On Thu, Jan 13, 2011 at 9:53 PM, Ian Lance Taylor wrote: > Achilleas Margaritis writes: > >> How much do you spend in maintaining headers? answers welcomed from >> other members as well. > > In C++, I personally spend very little time doing what I would describe > as "maintaining headers." I write class definitions in .h files and > function implementations in .cc files. The only data which appears in > both places is the function signature. Yes, it would be slightly nice > if I didn't have to write that twice. But it's a minor issue. Don't you ever had to modify the classes after you've written them? I am surprised, because I have talked to other developers and they have too said that it would be nice if headers could be avoided. > > Of course these days I mostly work on Go, which doesn't have this issue > at all, because the language implements something along the lines of the > C++ modules proposal. Which I think is the right way to go. Don't get > confused by the language standardization process here; your proposal is > also a change to the language. The pace of the standardization process > is independent of whether gcc should implement a language change. The > important point is that in order to implement what you want, the > question is not whether to change the language, it is how to change it. > And how it should be changed is the way that works best for most people, > which need not be the way that most nearly replicates the way the > language currently works. > > Ian > I do think that the modules proposal is the way to go, but I don't see that happening soon. I may have retired when the modules proposal is usable :-). My proposal does not change the language in any way, it only is a copy-and-paste job.
Re: Proposal for automatic generation of c++ header files
Ian Lance Taylor wrote: In C++, I personally spend very little time doing what I would describe as "maintaining headers." I write class definitions in .h files and function implementations in .cc files. The only data which appears in both places is the function signature. Yes, it would be slightly nice if I didn't have to write that twice. But it's a minor issue. Interesting, as an Ada person, I actually LIKE the idea of writing the signature in both places. The Ada view here is that it serves very different purposes, in the header, it is part of the specification, and in the implementation it is there for easy access to anyone reading the implementation, and is a reminder that the implementation must conform to this spec. I think it helps readability to have it in both places (with of course the compiler checking that it is the same). Its a slight pain for the writer, but in Ada we never care even a little bit about the convenience of the writer over the convenience of the reader, and of course appropriate tools could simplify the duplication. Don't you ever had to modify the classes after you've written them? I am surprised, because I have talked to other developers and they have too said that it would be nice if headers could be avoided. Again, I like using headers in this way, I think it clarifies the structure of the program. As I say, I am influenced by Ada. It is always interesting to see the range of possible views of C headers from a) annoying junk required by the compiler, spend the least possible time messing with them, and certainly don't bother commenting them. to b) headers function like package specifications in Ada, and should be regarded as specifications and fully commented accordingly. If you follow path b) you end up with C or C++ code that has quite an Ada-like feel with regard to separation of spec and implementation.
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 3:35 PM, Robert Dewar wrote: > Ian Lance Taylor wrote: > >> In C++, I personally spend very little time doing what I would describe >> as "maintaining headers." I write class definitions in .h files and >> function implementations in .cc files. The only data which appears in >> both places is the function signature. Yes, it would be slightly nice >> if I didn't have to write that twice. But it's a minor issue. > > Interesting, as an Ada person, I actually LIKE the idea of writing the > signature in both places. The Ada view here is that it serves very > different purposes, in the header, it is part of the specification, > and in the implementation it is there for easy access to anyone > reading the implementation, and is a reminder that the implementation > must conform to this spec. I think it helps readability to have it in > both places (with of course the compiler checking that it is the same). > > Its a slight pain for the writer, but in Ada we never care even a little > bit about the convenience of the writer over the convenience of the > reader, and of course appropriate tools could simplify the duplication. > >> Don't you ever had to modify the classes after you've written them? I >> am surprised, because I have talked to other developers and they have >> too said that it would be nice if headers could be avoided. > > Again, I like using headers in this way, I think it clarifies the > structure of the program. As I say, I am influenced by Ada. It is > always interesting to see the range of possible views of C headers > from > > a) annoying junk required by the compiler, spend the least possible > time messing with them, and certainly don't bother commenting them. > > to > > b) headers function like package specifications in Ada, and should > be regarded as specifications and fully commented accordingly. > > If you follow path b) you end up with C or C++ code that has quite > an Ada-like feel with regard to separation of spec and implementation. > I've heard this argument in other places that headers serve as specification, aiding in readability and conformance. I strongly disagree, for the following reasons: 1) conformance is checked by the compiler. There is no need for the programmer to check the conformance of the implementation to the specification. If it compiles without errors, the implementation is ok. 2) the actual knowledge about the program stored in a header is, from my rough estimation, up around 20% of what the program actually does. In order to incorporate the actual knowledge required, a lot of documentation has to be written. I comment my code with docified comments heavily in order to document every little detail of my program. This knowledge can never be deduced by the headers. The docified comments result in a nicely formatted documentation which is actually much easier to read than code in headers. So, if the compiler checks the code, and the documentation says whatever must be said about the program, headers are completely redundant.
Re: Proposal for automatic generation of c++ header files
On 1/14/2011 8:47 AM, Achilleas Margaritis wrote: 2) the actual knowledge about the program stored in a header is, from my rough estimation, up around 20% of what the program actually does. In order to incorporate the actual knowledge required, a lot of documentation has to be written. I comment my code with docified comments heavily in order to document every little detail of my program. This knowledge can never be deduced by the headers. The docified comments result in a nicely formatted documentation which is actually much easier to read than code in headers. The task of documenting specifications (what needs to be known by clients) is radically different from documenting implementations (what needs to be known by people fiddling with the implementation, the client should NEVER need to look at the implementation, and implementation details are not only irrelevant to the client, but it is evil for the client to depend on them). That's the Ada philosophy in a nutshell, for Ada people, it is the single most important feature of the language that it encourages and to some extent mandates separation of spec and implementation (I say to some extent, because I have seen C folk writing Ada who regard the Ada specs as nuisance headers and don't document them at all, which is a horrible sin from an Ada perspective). So, if the compiler checks the code, and the documentation says whatever must be said about the program, headers are completely redundant. But then you don't have proper documentation of the specification.
Re: Proposal for automatic generation of c++ header files
I guess I would just summarize things as follows. You can possibly generate headers automatically (just as you could generate subprogram specifications in Ada automatically). No one would ever think of suggesting doing this automatically in Ada. Why not? Because you might be able to generate the syntax of the specs, but you can never extract the specification from the implementation. That's because by its nature the implementation over-specifies. For example, if you have a sort package, the spec may simply require sorting, but not stable sorting. The implementation may happen to use an algorithm that happens to be stable. But if you have only the implementation you won't be able to tell if the stabilitiy is part of the specification. Then if you find later that you could speed things up hugely by abandoning the stability, you won't know if clients are legitimately depending on this or not. So from my narrow Ada perspective, I don't like any suggestion of automatic generation of c++ header files, but on the other hand, I understand that there are lots of people who have view a of headers (nuisance required by the compiler), and for such people it may ease writing to have such automatic generation. As I said before I never care at all about ease of writing code, compared to ease of reading it (and in the case of library packages, clients are readers).
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 4:09 PM, Robert Dewar wrote: > On 1/14/2011 8:47 AM, Achilleas Margaritis wrote: > >> 2) the actual knowledge about the program stored in a header is, from >> my rough estimation, up around 20% of what the program actually does. >> In order to incorporate the actual knowledge required, a lot of >> documentation has to be written. I comment my code with docified >> comments heavily in order to document every little detail of my >> program. This knowledge can never be deduced by the headers. The >> docified comments result in a nicely formatted documentation which is >> actually much easier to read than code in headers. > > The task of documenting specifications (what needs to be known > by clients) is radically different from documenting implementations > (what needs to be known by people fiddling with the implementation, > the client should NEVER need to look at the implementation, and > implementation details are not only irrelevant to the client, > but it is evil for the client to depend on them). I never said anything about documenting the implementation. I am talking about documentation about the 'client' (I assume that you mean the programmers that will use a library or the programmers that will inherit the codebase). Documenting the implementation is done through comments in the implementation. It's totally irrelevant. I am talking about documenting the way an API is supposed to be used. > > That's the Ada philosophy in a nutshell, for Ada people, it is > the single most important feature of the language that it > encourages and to some extent mandates separation of spec > and implementation (I say to some extent, because I have > seen C folk writing Ada who regard the Ada specs as nuisance > headers and don't document them at all, which is a horrible > sin from an Ada perspective). > >> So, if the compiler checks the code, and the documentation says >> whatever must be said about the program, headers are completely >> redundant. > > But then you don't have proper documentation of the specification. Yes, you have: you run Doxygen (or your favorite doc extraction program) and you get nicely formatted and searchable HTML.
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 4:14 PM, Robert Dewar wrote: > I guess I would just summarize things as follows. You > can possibly generate headers automatically (just as > you could generate subprogram specifications in Ada > automatically). > > No one would ever think of suggesting doing this > automatically in Ada. > > Why not? Because you might be able to generate > the syntax of the specs, but you can never extract > the specification from the implementation. That's > because by its nature the implementation over-specifies. > > For example, if you have a sort package, the spec may > simply require sorting, but not stable sorting. > > The implementation may happen to use an algorithm that > happens to be stable. > > But if you have only the implementation you won't > be able to tell if the stabilitiy is part of the > specification. > > Then if you find later that you could speed things > up hugely by abandoning the stability, you won't know > if clients are legitimately depending on this or not. > > So from my narrow Ada perspective, I don't like any > suggestion of automatic generation of c++ header > files, but on the other hand, I understand that there > are lots of people who have view a of headers (nuisance > required by the compiler), and for such people it may > ease writing to have such automatic generation. As I > said before I never care at all about ease of writing > code, compared to ease of reading it (and in the case > of library packages, clients are readers). > There is nothing that prevents the specification code to be in the same file as the implementation code, other than the will of the language author. All newer languages don't have header files...
Re: Proposal for automatic generation of c++ header files
On 1/14/2011 9:23 AM, Achilleas Margaritis wrote: All newer languages don't have header files... And to me, it is a serious flaw :-) One of several, e.g. in Java.
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 4:55 PM, Robert Dewar wrote: > On 1/14/2011 9:23 AM, Achilleas Margaritis wrote: > >> All newer languages don't have header files... > > And to me, it is a serious flaw :-) One of > several, e.g. in Java. > > Actually, it is not a flaw, it is a blessing :-).
Re: Proposal for automatic generation of c++ header files
On 14 January 2011 13:26, Achilleas Margaritis wrote: > My proposal does not change the language in any way, it only is a > copy-and-paste job. That's not true, your example with an inline member function demonstrates that the compiler must be changed to support your proposal, so that functions defined inline are given a non-inline definition that can be linked to by other translation units. If it was a copy'n'paste job, it could be done by an external tool, which you've disputed. Anyway, you don't seem to be convincing anyone of your proposal, but if you want to see it in gcc you are free to download and modify the source, or pay someone else to do it for you.
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 4:58 PM, Jonathan Wakely wrote: > On 14 January 2011 13:26, Achilleas Margaritis wrote: >> My proposal does not change the language in any way, it only is a >> copy-and-paste job. > > That's not true, your example with an inline member function > demonstrates that the compiler must be changed to support your > proposal, so that functions defined inline are given a non-inline > definition that can be linked to by other translation units. > > If it was a copy'n'paste job, it could be done by an external tool, > which you've disputed. My proposal doesn't change anything of the language from the programmer's perspective. The #autoinclude pragma can select to inline only those member functions that are good candidates for inlining. I.e. it can inline trivial code. I believe the GCC code already contains such criteria, like any other good compiler. > > Anyway, you don't seem to be convincing anyone of your proposal, but > if you want to see it in gcc you are free to download and modify the > source, or pay someone else to do it for you. There is a lot of resistance to this idea, I admit; but I haven't seen any concrete argument about why my proposal is not good. It seems the resistance comes in two flavors: 1) It is not interesting work for me, so you do it or pay someone else to do it (you seem to be into that camp). 2) I like headers because they are specifications (they aren't, but what can I do if one believe so? nothing). Hey, at least I tried :-).
Re: Proposal for automatic generation of c++ header files
On 1/14/2011 10:17 AM, Achilleas Margaritis wrote: The #autoinclude pragma can select to inline only those member functions that are good candidates for inlining. I.e. it can inline trivial code. I believe the GCC code already contains such criteria, like any other good compiler. Not sure what you are suggesting here, it is only deep in the back end code generation that the decision can be made as to whether something is a good candidate for inlining. How does that help you? There is a lot of resistance to this idea, I admit; but I haven't seen any concrete argument about why my proposal is not good. It seems the resistance comes in two flavors: 1) It is not interesting work for me, so you do it or pay someone else to do it (you seem to be into that camp). That's always an appropriate response! The remedy is to propose a patch yourself (or pay someone to do it), then we can see if it makes sense when the details are worked out. 2) I like headers because they are specifications (they aren't, but what can I do if one believe so? nothing). Hey, at least I tried :-).
Re: Proposal for automatic generation of c++ header files
>> 1) It is not interesting work for me, so you do it or pay someone else >> to do it (you seem to be into that camp). > > That's always an appropriate response! The remedy is to propose a > patch yourself (or pay someone to do it), then we can see if it > makes sense when the details are worked out. Is it? I don't think so. If you don't care, don't respond. Don't come up with excuses like 'it cannot be done' or 'no one cares about that'. Anyway, enough politics. If one does not care about this proposal, you don't have to respond. And proposing a patch myself is not a realistic solution. It can take many months for me to get acquainted with the GCC codebase.
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 05:17:12PM +0200, Achilleas Margaritis wrote:
> On Fri, Jan 14, 2011 at 4:58 PM, Jonathan Wakely
> wrote:
> > On 14 January 2011 13:26, Achilleas Margaritis wrote:
> >> My proposal does not change the language in any way, it only is a
> >> copy-and-paste job.
> >
> > That's not true, your example with an inline member function
> > demonstrates that the compiler must be changed to support your
> > proposal, so that functions defined inline are given a non-inline
> > definition that can be linked to by other translation units.
> >
> > If it was a copy'n'paste job, it could be done by an external tool,
> > which you've disputed.
>
> My proposal doesn't change anything of the language from the
> programmer's perspective.
I think the point Jonathan wanted to make is the following: your
original example does not compile -- and can not compile without a
change of the language. If you create by hand the auto-include file you
proposed:
main.cpp:
#include "foo.hpp"
int main() {
Foo *foo = new Foo;
foo->bar();
foos.push_back(foo);
}
foo.cpp:
#include
class Foo {
public:
void bar() {}
};
std::list foos;
static int data = 0;
foo.hpp:
#ifndef FOO_HPP
#define FOO_HPP
#include
class Foo {
public:
void bar();
};
extern std::list foos;
#endif //FOO_HPP
There is a violation of the C++-standard:
- when main.cpp is compiled, the compiler reads "foo.hpp" -- and it
learns that the class "Foo" has a member-function "bar" which can be
call from within main.cpp -- so main.cpp is compiled without problem.
- when "foo.cpp" is compiled, the compiler does not read "foo.hpp" and
thus it sees that the function "bar" is defined INLINE. So the
compiler will NOT export Foo::bar() -- it will be impossible to
link to Foo::bar() from another compilation unit.
- finally, you try to link both compilation units. Result: main() tries
to call a function "Foo::bar()" -- but that does not exist ==>
compilation error.
On my machine, I get exactly that:
g++ main.cpp foo.cpp
/tmp/ccszFpug.o: In function `main':
main.cpp:(.text+0x27): undefined reference to `Foo::bar()'
collect2: ld returned 1 exit status
So in fact you have to change the language, I believe (at least it is
necessary to remove the rule "if a member function is defined inline in
a class, it is marked as "inline" and NOT exported"). But may be there
are also other problems?
HTH,
Axel
Re: kfreebsd-gnu etc. issues
2011/1/12 Robert Millan : >> * The headers config/kfreebsd-gnu.h etc. override >> GLIBC_DYNAMIC_LINKER. But the 64-bit configurations >> x86_64-*-kfreebsd*-gnu and x86_64-*-knetbsd*-gnu do not appear to >> use any header that would override GLIBC_DYNAMIC_LINKER32 and >> GLIBC_DYNAMIC_LINKER64, which are what LINK_SPEC in linux64.h >> actually uses. Thus those configurations would use Linux-specific >> dynamic linker settings, which seems unlikely to be as intended. > > It's not as intended. On amd64 we use /lib/ld.so.1 and > /lib/ld-kfreebsd-x86-64.so.1. It seems x86_64-kfreebsd-gnu has been broken for a while. I just realized that I wrote a patch to fix this in 2006 [1], but somehow it was never merged in GCC (actually I'm not even sure I submitted it). In the meantime Debian GNU/kFreeBSD has been using this patch to build GCC on their "kfreebsd-amd64" port. I can prepare an updated version of this patch (relative to trunk + your linux.h overhaul [2]). [1] http://svn.debian.org/viewsvn/glibc-bsd/trunk/web/patches/upstream-only/gcc.diff?view=markup&pathrev=1424 [2] http://gcc.gnu.org/ml/gcc-patches/2010-12/msg02055.html -- Robert Millan
Re: kfreebsd-gnu etc. issues
2011/1/12 Ian Lance Taylor : > All that said, I see little harm in using a PT_GNU_STACK header on > binaries even if the kernel does not fully support them. Except for the > small amount of wasted space in every .o file and every executable, but > I lost that argument years ago. Thanks Ian. Seeing that there's so little harm in enabling it gratuitously, I think it'd be best to assume that PT_GNU_STACK is supported unless someone can prove otherwise. -- Robert Millan
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 5:29 PM, Axel Freyn wrote:
> On Fri, Jan 14, 2011 at 05:17:12PM +0200, Achilleas Margaritis wrote:
>> On Fri, Jan 14, 2011 at 4:58 PM, Jonathan Wakely
>> wrote:
>> > On 14 January 2011 13:26, Achilleas Margaritis wrote:
>> >> My proposal does not change the language in any way, it only is a
>> >> copy-and-paste job.
>> >
>> > That's not true, your example with an inline member function
>> > demonstrates that the compiler must be changed to support your
>> > proposal, so that functions defined inline are given a non-inline
>> > definition that can be linked to by other translation units.
>> >
>> > If it was a copy'n'paste job, it could be done by an external tool,
>> > which you've disputed.
>>
>> My proposal doesn't change anything of the language from the
>> programmer's perspective.
> I think the point Jonathan wanted to make is the following: your
> original example does not compile -- and can not compile without a
> change of the language. If you create by hand the auto-include file you
> proposed:
>
> main.cpp:
> #include "foo.hpp"
> int main() {
> Foo *foo = new Foo;
> foo->bar();
> foos.push_back(foo);
> }
>
> foo.cpp:
> #include
> class Foo {
> public:
> void bar() {}
> };
> std::list foos;
> static int data = 0;
>
> foo.hpp:
> #ifndef FOO_HPP
> #define FOO_HPP
> #include
> class Foo {
> public:
> void bar();
> };
> extern std::list foos;
> #endif //FOO_HPP
>
> There is a violation of the C++-standard:
> - when main.cpp is compiled, the compiler reads "foo.hpp" -- and it
> learns that the class "Foo" has a member-function "bar" which can be
> call from within main.cpp -- so main.cpp is compiled without problem.
> - when "foo.cpp" is compiled, the compiler does not read "foo.hpp" and
> thus it sees that the function "bar" is defined INLINE. So the
> compiler will NOT export Foo::bar() -- it will be impossible to
> link to Foo::bar() from another compilation unit.
> - finally, you try to link both compilation units. Result: main() tries
> to call a function "Foo::bar()" -- but that does not exist ==>
> compilation error.
> On my machine, I get exactly that:
> g++ main.cpp foo.cpp
> /tmp/ccszFpug.o: In function `main':
> main.cpp:(.text+0x27): undefined reference to `Foo::bar()'
> collect2: ld returned 1 exit status
>
> So in fact you have to change the language, I believe (at least it is
> necessary to remove the rule "if a member function is defined inline in
> a class, it is marked as "inline" and NOT exported"). But may be there
> are also other problems?
>
> HTH,
>
> Axel
>
There is a solution to that: the compiler, knowing that foo::bar is
not an inline function, it does not inline the function but it
automatically compiles the relevant symbol in the foo.o object file.
The trick is to let the compiler know that foo::bar is not an inline
function. The information that foo::bar is not an inline function is
contained in the header, as I've shown:
foo.hpp:
#ifndef FOO_HPP
#define FOO_HPP
#include
class Foo {
public:
void bar();
};
extern std::list foos;
#endif //FOO_HPP
So, if the compiler was informed about foo::bar not being inlined, it
could then produce the appropriate symbol. This could happen if the
autogenerated header is automatically included when the implementation
file that produced the autogenerated header is compiled.
The compiler could check if there is an autogenerated header in the
same folder as the implementation file; if there is, then it is
included automatically in the implementation file.
Then the compiler manages the clash of symbols as needed.
>From the programmer's language perspective, it is not a change in the language.
Re: Proposal for automatic generation of c++ header files
> ... > > 2) I like headers because they are specifications (they aren't, but > what can I do if one believe so? nothing). I think that's a matter of opinion, and language-specific as well. C is such a loose language that applying the notion of "specification" is hard. Ada is quite another story. From what little I know of it, I would go along with the Ada experts' comments. And as an implementer of large C/C++ based embedded systems, I tend to the view that, while some programmers don't think of headers as specifications, they should, and doing so is helpful to achieving high quality. paul
Re: Proposal for automatic generation of c++ header files
> And as an implementer of large C/C++ based embedded systems, I tend to the > view that, while some programmers don't think of headers as specifications, > they should, and doing so is helpful to achieving high quality. Back many years ago when I was doing VLSI design, there was one large CAD system written in C (I forget which one now) that had extensive documentation in their header files. I think that was a major part of the quality of that tool.
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 5:59 PM, Paul Koning wrote: >> ... >> >> 2) I like headers because they are specifications (they aren't, but >> what can I do if one believe so? nothing). > > I think that's a matter of opinion, and language-specific as well. I disagree that it is 'a matter of opinion'. It is not. The concepts we are discussing are specific and concrete, they are not abstract. We are not talking religion or morality. It's not a philosophical subject. > C is such a loose language that applying the notion of "specification" is > hard. Ada is quite another story. From what little I know of it, I would go > along with the Ada experts' comments. Just like any other language, Ada has declarations and definitions. The Ada people call their headers 'specifications', because a lot of program specifications are placed in those headers. But they are not specifications in a sense that you can have multiple implementations of them. I.e. there is a 1-to-1 correspondence between Ada package declarations and package bodies. Feel free to correct me if I am mistaken. > > And as an implementer of large C/C++ based embedded systems, I tend to the > view that, while some programmers don't think of headers as specifications, > they should, and doing so is helpful to achieving high quality. > > paul How do headers thought of specifications are helpful in achieving high quality? please give us a concrete example of a case that not having the headers provides less quality.
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 6:07 PM, Richard Kenner wrote: >> And as an implementer of large C/C++ based embedded systems, I tend to the >> view that, while some programmers don't think of headers as specifications, >> they should, and doing so is helpful to achieving high quality. > > Back many years ago when I was doing VLSI design, there was one large > CAD system written in C (I forget which one now) that had extensive > documentation in their header files. I think that was a major part of > the quality of that tool. > The same documentation can be put in the implementation file. The Qt source code contains all the documentation in the implementation files (for a good reason: headers are parsed again and again).
Re: Proposal for automatic generation of c++ header files
On 1/14/2011 11:07 AM, Richard Kenner wrote: Back many years ago when I was doing VLSI design, there was one large CAD system written in C (I forget which one now) that had extensive documentation in their header files. I think that was a major part of the quality of that tool. There you go Richard, corrupted by all those years of hanging around with Ada folks :-) :-)
Re: Proposal for automatic generation of c++ header files
> The Ada people call their headers 'specifications', because a lot of > program specifications are placed in those headers. > > But they are not specifications in a sense that you can have multiple > implementations of them. I.e. there is a 1-to-1 correspondence between > Ada package declarations and package bodies. > > Feel free to correct me if I am mistaken. You are mistaken. ;-) It's not uncommon to have multiple different implementations of the same specification, for example for different target architectures or one might be production and the other development.
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 6:20 PM, Richard Kenner wrote: >> The Ada people call their headers 'specifications', because a lot of >> program specifications are placed in those headers. >> >> But they are not specifications in a sense that you can have multiple >> implementations of them. I.e. there is a 1-to-1 correspondence between >> Ada package declarations and package bodies. >> >> Feel free to correct me if I am mistaken. > > You are mistaken. ;-) I am not mistaken. For a single Ada program that compiles successfully, there is 1-to-1 correspondence of a package declaration and package body. > > It's not uncommon to have multiple different implementations of the > same specification, for example for different target architectures or > one might be production and the other development. That's what conditional compilation, modules and build systems are for.
Re: Proposal for automatic generation of c++ header files
On 1/14/2011 11:08 AM, Achilleas Margaritis wrote: On Fri, Jan 14, 2011 at 5:59 PM, Paul Koning wrote: ... 2) I like headers because they are specifications (they aren't, but what can I do if one believe so? nothing). I think that's a matter of opinion, and language-specific as well. I disagree that it is 'a matter of opinion'. It is not. The concepts we are discussing are specific and concrete, they are not abstract. We are not talking religion or morality. It's not a philosophical subject. There you are definitely wrong. Of course headers are specifications, they specify the parameter types etc. Now the question is whether to go beyond that (after all that's all the Ada syntax really does itself) and regard them as the proper repository of all the information that is part of the specification. That *is* a matter of taste and viewpoint. You are free to disagree with that as a desirable approach, but it is indeed a matter, not of religeon or morality (truly weird references in this discussion) but of desirable viewpoint. And you saying categorically that "they aren't" does not help the discussion. The proper viewpoint to take here to support the idea of automatic generation is to recognize that there is a legitimate difference of opinion, but that there are lots of people whose opinion (not statement of fact) matches yours, that headers should not be regarded as specifications, and therefore it is useful to generate them automatically. I think if you take the attitude that everyone has to agree with your viewpoint, you will have even less success than you already have in pushing this idea. There are two issues here really 1. How do we deal with the language distortion that your proposal causes. this seems a significant problem to me, and I have not really seen you address it. 2. Will having this capability discourage people from viewing headers as specifications? If so, that might be a good thing or bad thing depending on your point of view. My view is that it won't make much difference, I can't see people thinking It's really nice that I can use headers to mimic the effect of separate specifications, I will do that ... oh oh, I can generate them automatically, so much for that idea I can't be bothered. It's really quite a strong separation of viewpoints here, and I can't see someone's viewpoint being modified much by the availability of automatic generation of headers. But I do think it must be done in a way that does not distort the language, and for my taste, if this cannot be done with an external tool, and no changes to the compiler, it is a non-starter. The Ada people call their headers 'specifications', because a lot of program specifications are placed in those headers. But they are not specifications in a sense that you can have multiple implementations of them. I.e. there is a 1-to-1 correspondence between Ada package declarations and package bodies. This is completely wrong, it is quite normal to have specifications in Ada with multiple bodies, e.g. for different targets, then you select the body you want to use. This is one of the advantages of this approach. For example, this approach is used extensively in the GNAT Ada run time. How do headers thought of specifications are helpful in achieving high quality? please give us a concrete example of a case that not having the headers provides less quality. You can definitely answer this question yourself, I don't think you can expect anyone to give you a long tutorial on why this separation is desirable. A lot has been written on this subject, and there are lots of programs to use as examples.
Re: Proposal for automatic generation of c++ header files
On 1/14/2011 11:10 AM, Achilleas Margaritis wrote: The same documentation can be put in the implementation file. Yes, if you have formal conventions for documentation you can achieve the separation (as is done in well-written Java programs), but it is so much easier to do if you have separate specs, and it solves the problem of multiple implementations with a single specification so much more cleanly. The Qt source code contains all the documentation in the implementation files (for a good reason: headers are parsed again and again). Surely you are not claiming that parsing comments in header files takes a significant amount of time, if so, that's a patently incorrect claim, which you cannot back up with quantitative data since it is false (how do I know it is false, we DO have such data for Ada, from early on when we wondered whether to bother with it, and that was with machines of the speed of 20 years ago, and the answer was no then, and is even more definitely no now).
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 05:39:58PM +0200, Achilleas Margaritis wrote:
> > [...]
> > There is a violation of the C++-standard:
> > - when main.cpp is compiled, the compiler reads "foo.hpp" -- and it
> > learns that the class "Foo" has a member-function "bar" which can be
> > call from within main.cpp -- so main.cpp is compiled without problem.
> > - when "foo.cpp" is compiled, the compiler does not read "foo.hpp" and
> > thus it sees that the function "bar" is defined INLINE. So the
> > compiler will NOT export Foo::bar() -- it will be impossible to
> > link to Foo::bar() from another compilation unit.
> > - finally, you try to link both compilation units. Result: main() tries
> > to call a function "Foo::bar()" -- but that does not exist ==>
> > compilation error.
> > On my machine, I get exactly that:
> > g++ main.cpp foo.cpp
> > /tmp/ccszFpug.o: In function `main':
> > main.cpp:(.text+0x27): undefined reference to `Foo::bar()'
> > collect2: ld returned 1 exit status
> [...]
> There is a solution to that: the compiler, knowing that foo::bar is
> not an inline function, it does not inline the function but it
> automatically compiles the relevant symbol in the foo.o object file.
I agree, one can solve it -- but with a change of the language. And for
example I use the fact that member-functions which are defined inline
ARE inline (e.g. to speedup trivial access functions).
>
> The trick is to let the compiler know that foo::bar is not an inline
> function. The information that foo::bar is not an inline function is
> contained in the header, as I've shown:
>
> foo.hpp:
> #ifndef FOO_HPP
> #define FOO_HPP
> #include
> class Foo {
> public:
>void bar();
> };
> extern std::list foos;
> #endif //FOO_HPP
>
> So, if the compiler was informed about foo::bar not being inlined, it
> could then produce the appropriate symbol. This could happen if the
> autogenerated header is automatically included when the implementation
> file that produced the autogenerated header is compiled.
But that is not possible, as in this case you violate the C++-Standard:
Adding '#include "foo.hpp"' to foo.cpp in the example results in the
fact that class Foo is two times defined, which is illegal C++ -- and
in addition, the two definitions differ (once "bar" is inline, once it
isn't).
So the compiler would need to realize in addition that "foo.hpp" is an
autogenerated file -- and thus the compiler would have to use different
compilation rules.
>
> The compiler could check if there is an autogenerated header in the
> same folder as the implementation file; if there is, then it is
> included automatically in the implementation file.
>
> Then the compiler manages the clash of symbols as needed.
But with that everything becomes much more complex:
- When the compiler compiles "foo.cpp" -- how does he already know
that there is a "pragma autoinclude" in another file (here:
main.cpp)? Either you have to guarantee that "main.cpp" is compiled
before "foo.cpp" -- or you have to include the information "foo.hpp
will be autogenerated" also in the file "foo.cpp"
- How can the compiler detect that the file "foo.hpp" is autgenerated
-- and thus a different language-standard has to be used to treat
the class "Foo"? (allowing redefinition of the class; ignoring the
fact that the two class-definition differ, ...) -- just try adding
'#include "foo.hpp"' in the file foo.cpp, this results in:
g++ foo.cpp
foo.cpp:4: error: redefinition of ‘class Foo’
foo.hpp:6: error: previous definition of ‘class Foo’
- the code is no longer understandable by other compilers: it is
impossible to write by hand a "replacement header" with which an
unpatched compiler (without this new extension) could compile the
code (at least I don't see a possible way)
So I think, this extension would make it necessary at least:
- to change the language standard (and add special rules how classes
defined in an autogenerated-header are treated)
- to add also in "foo.cpp" the information that "foo.hpp" will be
autogenerated
- to mark "foo.hpp" as being autogenerated
And it will be impossible to compile such a code with another compiler
(which does NOT know those special rules), even if one supplies by hand
the generated header files.
Axel
Re: Proposal for automatic generation of c++ header files
On 1/14/2011 11:18 AM, Achilleas Margaritis wrote: On Fri, Jan 14, 2011 at 6:20 PM, Richard Kenner wrote: The Ada people call their headers 'specifications', because a lot of program specifications are placed in those headers. But they are not specifications in a sense that you can have multiple implementations of them. I.e. there is a 1-to-1 correspondence between Ada package declarations and package bodies. Feel free to correct me if I am mistaken. You are mistaken. ;-) I am not mistaken. For a single Ada program that compiles successfully, there is 1-to-1 correspondence of a package declaration and package body. In a particular link, yes, in the non-generic case, but of course if you use generics you can achieve the effect of multiple bodies. But I don't think you know how Ada is used at all with respect to this feature (I suspect you have never built or worked with a large Ada application). It's not uncommon to have multiple different implementations of the same specification, for example for different target architectures or one might be production and the other development. That's what conditional compilation, modules and build systems are for. But as every Ada programmer knows, doing it with separate specs and bodies is FAR more straight forward and far easier. For an extensive example study the Ada run-time example, and by the way study a-adaint.c in the same run-time for an example of how not to do things (a-adaint.c is full of conditional target dependent cconditional compilation and is unfortunatrely a bit of a mess)
Re: Proposal for automatic generation of c++ header files
> There you are definitely wrong. Of course headers are specifications,
> they specify the parameter types etc.
Headers contain specifications, I agree to that. However:
1) headers could contain anything, at least in C/C++.
2) said specifications can be part of a single file of code; there is
no need to split it in too.
> Now the question is whether to
> go beyond that (after all that's all the Ada syntax really does itself)
> and regard them as the proper repository of all the information
> that is part of the specification. That *is* a matter of taste
> and viewpoint.
I am not saying that separating specifications from implementations is
wrong. There is a use case for that.
What I am saying is that the artificial separation of code into header
and implementation files hurts productivity. **A lot**.
The same result (coding against specifications) can be achieved
without the separation of headers and implementation files OR without
the duplication of work.
>
> You are free to disagree with that as a desirable approach, but it
> is indeed a matter, not of religeon or morality (truly weird references
> in this discussion) but of desirable viewpoint. And you saying
> categorically that "they aren't" does not help the discussion.
Ok.
>
> The proper viewpoint to take here to support the idea of automatic
> generation is to recognize that there is a legitimate difference of
> opinion, but that there are lots of people whose opinion (not
> statement of fact) matches yours, that headers should not be
> regarded as specifications, and therefore it is useful to
> generate them automatically. I think if you take the attitude
> that everyone has to agree with your viewpoint, you will have
> even less success than you already have in pushing this idea.
Let's stay clear of politics. Please. I am not interested. I have a
job to do and many headers to create :-).
>
> There are two issues here really
>
> 1. How do we deal with the language distortion that your proposal
> causes. this seems a significant problem to me, and I have not
> really seen you address it.
I have already explained it, but I don't mind explaining it once more:
1) the pragma #autoinclude ("foo.hpp", "foo.cpp") instructs the
compiler to generate the header 'foo.hpp' from the implementation file
'foo.cpp'.
2) the compiler opens the file 'foo.cpp'.
3) for every class found in the file 'foo.cpp', a relevant class is
placed into the header.
4) for every member function that is not a candidate for inlining, the
compiler puts a function declaration in the header.
5) for every member function that is a good candidate for inlining,
the compiler puts the definition the header.
6) for every non-static variable in the implementation file, it puts
an 'extern' declaration in the header.
7) for every non-static standalone function in the implementation
file, it puts the relevant function declaration in the header.
8) for every namespace in the implementation file, the relevant
namespace is put in the header file.
9) when the compiler compiles foo.cpp, it checks if there is a
relevant autogenerated header in the same place. If there is not one,
then it proceeds to compile the implementation file as usual. If there
is an autogenerated header:
10) if a class in the implementation file is part of the header, then:
11) if a member function has only a declaration in the header, then
the function body is retrieved from the implementation file and the
function is compiled as if it was defined outside of the class.
12) otherwise, the header definition is used.
> This is completely wrong, it is quite normal to have specifications
> in Ada with multiple bodies, e.g. for different targets, then you
> select the body you want to use. This is one of the advantages of
> this approach. For example, this approach is used extensively in
> the GNAT Ada run time.
Does this happen at run-time? I don't think so.
>
>> How do headers thought of specifications are helpful in achieving high
>> quality? please give us a concrete example of a case that not having
>> the headers provides less quality.
>
> You can definitely answer this question yourself, I don't think you
> can expect anyone to give you a long tutorial on why this separation
> is desirable. A lot has been written on this subject, and there are
> lots of programs to use as examples.
Links?
I am asking this because in most of the links I have found, people
wish that headers did not exist.
The only legitimate case is that of multiple compilation targets, and
it is not something that cannot be handled with conditional
compilation and a nice module system.
And I am not exactly proposing banning headers already :-).
Re: Proposal for automatic generation of c++ header files
On Fri, Jan 14, 2011 at 6:22 PM, Robert Dewar wrote: > On 1/14/2011 11:10 AM, Achilleas Margaritis wrote: > >> The same documentation can be put in the implementation file. > > Yes, if you have formal conventions for documentation you can > achieve the separation (as is done in well-written Java programs), > but it is so much easier to do if you have separate specs, There is a lot more to documentation beyond 'specs'. > Surely you are not claiming that parsing comments in header files > takes a significant amount of time, if so, that's a patently > incorrect claim, which you cannot back up with quantitative > data since it is false (how do I know it is false, we DO have > such data for Ada, from early on when we wondered whether to > bother with it, and that was with machines of the speed of > 20 years ago, and the answer was no then, and is even more > definitely no now). Oh yes it does. Have you seen a Qt source code file? we are talking about some comments being many pages long. Multiply that with multiple inclusions of the same header, add lots of files, and you get the idea.
Re: kfreebsd-gnu etc. issues
On Fri, 14 Jan 2011, Robert Millan wrote: > I can prepare an updated version of this patch (relative to > trunk + your linux.h overhaul [2]). Yes, that seems appropriate (it would now just be relevant to trunk since my gnu-user.h patch is now in trunk). -- Joseph S. Myers jos...@codesourcery.com
Re: Proposal for automatic generation of c++ header files
On 14 January 2011 15:39, Achilleas Margaritis wrote:
> On Fri, Jan 14, 2011 at 5:29 PM, Axel Freyn wrote:
>> On Fri, Jan 14, 2011 at 05:17:12PM +0200, Achilleas Margaritis wrote:
>>> On Fri, Jan 14, 2011 at 4:58 PM, Jonathan Wakely
>>> wrote:
>>> > On 14 January 2011 13:26, Achilleas Margaritis wrote:
>>> >> My proposal does not change the language in any way, it only is a
>>> >> copy-and-paste job.
>>> >
>>> > That's not true, your example with an inline member function
>>> > demonstrates that the compiler must be changed to support your
>>> > proposal, so that functions defined inline are given a non-inline
>>> > definition that can be linked to by other translation units.
>>> >
>>> > If it was a copy'n'paste job, it could be done by an external tool,
>>> > which you've disputed.
>>>
>>> My proposal doesn't change anything of the language from the
>>> programmer's perspective.
>> I think the point Jonathan wanted to make is the following: your
>> original example does not compile -- and can not compile without a
>> change of the language. If you create by hand the auto-include file you
>> proposed:
>>
>> main.cpp:
>> #include "foo.hpp"
>> int main() {
>> Foo *foo = new Foo;
>> foo->bar();
>> foos.push_back(foo);
>> }
>>
>> foo.cpp:
>> #include
>> class Foo {
>> public:
>> void bar() {}
>> };
>> std::list foos;
>> static int data = 0;
>>
>> foo.hpp:
>> #ifndef FOO_HPP
>> #define FOO_HPP
>> #include
>> class Foo {
>> public:
>> void bar();
>> };
>> extern std::list foos;
>> #endif //FOO_HPP
>>
>> There is a violation of the C++-standard:
>> - when main.cpp is compiled, the compiler reads "foo.hpp" -- and it
>> learns that the class "Foo" has a member-function "bar" which can be
>> call from within main.cpp -- so main.cpp is compiled without problem.
>> - when "foo.cpp" is compiled, the compiler does not read "foo.hpp" and
>> thus it sees that the function "bar" is defined INLINE. So the
>> compiler will NOT export Foo::bar() -- it will be impossible to
>> link to Foo::bar() from another compilation unit.
>> - finally, you try to link both compilation units. Result: main() tries
>> to call a function "Foo::bar()" -- but that does not exist ==>
>> compilation error.
>> On my machine, I get exactly that:
>> g++ main.cpp foo.cpp
>> /tmp/ccszFpug.o: In function `main':
>> main.cpp:(.text+0x27): undefined reference to `Foo::bar()'
>> collect2: ld returned 1 exit status
>>
>> So in fact you have to change the language, I believe (at least it is
>> necessary to remove the rule "if a member function is defined inline in
>> a class, it is marked as "inline" and NOT exported"). But may be there
>> are also other problems?
Thank you, Axel. Yes, that's what I meant.
>>
>> HTH,
>>
>> Axel
>>
>
> There is a solution to that: the compiler, knowing that foo::bar is
> not an inline function, it does not inline the function but it
> automatically compiles the relevant symbol in the foo.o object file.
Which is a change to the language semantics!
> The trick is to let the compiler know that foo::bar is not an inline
> function. The information that foo::bar is not an inline function is
> contained in the header, as I've shown:
>
> foo.hpp:
> #ifndef FOO_HPP
> #define FOO_HPP
> #include
> class Foo {
> public:
> void bar();
> };
> extern std::list foos;
> #endif //FOO_HPP
>
> So, if the compiler was informed about foo::bar not being inlined, it
> could then produce the appropriate symbol. This could happen if the
> autogenerated header is automatically included when the implementation
> file that produced the autogenerated header is compiled.
That's a change to how the compiler handles C++ - i.e. a change to the
language semantics.
What part of this are you finding so difficult to understand?
> The compiler could check if there is an autogenerated header in the
> same folder as the implementation file; if there is, then it is
> included automatically in the implementation file.
>
> Then the compiler manages the clash of symbols as needed.
>
> From the programmer's language perspective, it is not a change in the
> language.
A change to how the compiler processes the source code is a change to
the language. The rules on template instantiation, inline functions,
symbol visibility, inline namespaces etc. would probably all be
affected.
You also don't seem to have considered header dependencies. If
foo.cpp #includes ten files, some of which are needed for the
interface and some for the implementation, how many of them should be
copied to foo.hpp by your "simple" copy'n'paste? Should the compiler
analyse which headers are needed just for the interface declarations,
and only include those headers? Or auto-generate forward-declarations
of all the needed entities?
Or just include all of them, even though some headers may only be
needed for the implementations, resulting in namespace pollution in
other translation units and possible ambiguities, conflicts, or
dependency cycles?
Re: Proposal for automatic generation of c++ header files
On 1/14/2011 11:44 AM, Achilleas Margaritis wrote: Oh yes it does. Have you seen a Qt source code file? we are talking about some comments being many pages long. Multiply that with multiple inclusions of the same header, add lots of files, and you get the idea. There are lots of specs in the Ada run time that have thousands of lines of comments (*), they cost nothing measureable to read or parse. You are making claims here without any data whatever to back up these claims. We have extensive data that backs up what I am saying (at one point we seriously considered a version of the Ada run time that would strip all comments because of this concern, the Ada specs are read over and over again just like C headers, but we found it did not make a measurable difference). I am perfectly happy to discuss real data if you have it, but not vague non-quantiative claims. For an example in the ada run time, have a look at the file g-spipat.ads, just the tutorial on pattern matching is over 600 lines long, and that's even before the comments on the specific routines provided. I really think you do your whole position a disservice by trying to argue everyone into agreeing with your viewpoint on C headers. You are not going to succeed in that argument, and you distract from what should be your main point, which is that for a lot of programmers, headers are an unnecessary nuisance, and that for those programmers, automatic generation might be helpful. You do not have to convince all the world to join this group!
Re: Proposal for automatic generation of c++ header files
>> There is a solution to that: the compiler, knowing that foo::bar is >> not an inline function, it does not inline the function but it >> automatically compiles the relevant symbol in the foo.o object file. > > Which is a change to the language semantics! The compiler can inline the trivial member functions and leave the rest as is. Although technically it is a change in language semantics, it's a very minor change, that I doubt will have anyone worried. Look at the benefit of not having to create headers though...for me, it's a good trade off. > A change to how the compiler processes the source code is a change to > the language. The rules on template instantiation, inline functions, > symbol visibility, inline namespaces etc. would probably all be > affected. I do not see how anything else other than inlining is to be affected. Care to show an example? > > You also don't seem to have considered header dependencies. If > foo.cpp #includes ten files, some of which are needed for the > interface and some for the implementation, how many of them should be > copied to foo.hpp by your "simple" copy'n'paste? Should the compiler > analyse which headers are needed just for the interface declarations, > and only include those headers? Or auto-generate forward-declarations > of all the needed entities? > Or just include all of them, even though some headers may only be > needed for the implementations, resulting in namespace pollution in > other translation units and possible ambiguities, conflicts, or > dependency cycles? All of them. I'll take automatic generation of headers + increased compilation times any day over manual generation of headers. New computers and hard disks can always be purchased and are much cheaper than people. If I encountered a problem with dependency cycles, then I would use the old way of manually writing headers, which will still be available.
Re: Proposal for automatic generation of c++ header files
On 1/14/2011 12:10 PM, Achilleas Margaritis wrote: There is a solution to that: the compiler, knowing that foo::bar is not an inline function, it does not inline the function but it automatically compiles the relevant symbol in the foo.o object file. Which is a change to the language semantics! The compiler can inline the trivial member functions and leave the rest as is. Although technically it is a change in language semantics, it's a very minor change, that I doubt will have anyone worried. Has me worried, changing language semantics for this and thus making the compiler non-conforming makes it a non-starter. This would have to be done under some switch. For me this kills the idea, we will see what others think.
Re: Proposal for automatic generation of c++ header files
On 14 January 2011 17:10, Achilleas Margaritis wrote: >>> There is a solution to that: the compiler, knowing that foo::bar is >>> not an inline function, it does not inline the function but it >>> automatically compiles the relevant symbol in the foo.o object file. >> >> Which is a change to the language semantics! > > The compiler can inline the trivial member functions and leave the > rest as is. Although technically it is a change in language semantics, > it's a very minor change, that I doubt will have anyone worried. Except compiler and linker writers. And those are the people you're asking to implement your idea, without a proper spec or convincing arguments. > Look at the benefit of not having to create headers though...for me, > it's a good trade off. > >> A change to how the compiler processes the source code is a change to >> the language. The rules on template instantiation, inline functions, >> symbol visibility, inline namespaces etc. would probably all be >> affected. > > I do not see how anything else other than inlining is to be affected. > > Care to show an example? No, the onus would be on you to demonstrate your change doesn't affect such things. I like the status quo, and am confident that doesn't require change to the language. If you don't like the status quo and claim your alternative doesn't change things, you need to demonstrate that. >> >> You also don't seem to have considered header dependencies. If >> foo.cpp #includes ten files, some of which are needed for the >> interface and some for the implementation, how many of them should be >> copied to foo.hpp by your "simple" copy'n'paste? Should the compiler >> analyse which headers are needed just for the interface declarations, >> and only include those headers? Or auto-generate forward-declarations >> of all the needed entities? >> Or just include all of them, even though some headers may only be >> needed for the implementations, resulting in namespace pollution in >> other translation units and possible ambiguities, conflicts, or >> dependency cycles? > > All of them. > > I'll take automatic generation of headers + increased compilation > times any day over manual generation of headers. New computers and > hard disks can always be purchased and are much cheaper than people. > > If I encountered a problem with dependency cycles, then I would use > the old way of manually writing headers, which will still be > available. OK, fair enough.
Re: Proposal for automatic generation of c++ header files
> the compiler non-conforming makes it a non-starter. This would have to > be done under some switch. The switch idea is fine by me, although not necessarily required, since it can be implicit anyway (it's like saying to the end-users: hey, you don't have all the functions inline with #autoinclude as in headers, but this may increase your productivity).
Re: Proposal for automatic generation of c++ header files
Achilleas Margaritis writes: > On Thu, Jan 13, 2011 at 9:53 PM, Ian Lance Taylor wrote: >> Achilleas Margaritis writes: >> >>> How much do you spend in maintaining headers? answers welcomed from >>> other members as well. >> >> In C++, I personally spend very little time doing what I would describe >> as "maintaining headers." I write class definitions in .h files and >> function implementations in .cc files. The only data which appears in >> both places is the function signature. Yes, it would be slightly nice >> if I didn't have to write that twice. But it's a minor issue. > > Don't you ever had to modify the classes after you've written them? I > am surprised, because I have talked to other developers and they have > too said that it would be nice if headers could be avoided. Of course I often have to modify classes after I've written them, but I don't see what that has to do with your argument. That is just programming. It would be the same work whether the class was defined in a header file or in a regular soruce file. > My proposal does not change the language in any way, it only is a > copy-and-paste job. No, your proposal does change the language. A program written using your proposed pragma would not work with a compiler which does not understand your pragma. Ian
Re: kfreebsd-gnu etc. issues
2011/1/12 Joseph S. Myers : >> I don't understand this code, but what I can do is confirm that disabling >> linux-unwind.h doesn't cause any breakage. Then we could disable it >> untill/unless someone more clued than me ports it to kFreeBSD. Would >> this be ok? > > That makes sense to me. Confirmed, linux-unwind.h can be removed. > If disabled for non-Linux-kernel targets, the > REG_NAME abstraction may as well be removed as not actually being useful > at present. Ack. I'll send a patch for this. -- Robert Millan
Re: RFC: Add 32bit x86-64 support to binutils
On Fri, Dec 31, 2010 at 6:50 AM, H.J. Lu wrote: > On Thu, Dec 30, 2010 at 4:48 PM, H.J. Lu wrote: >> On Thu, Dec 30, 2010 at 4:42 PM, H. Peter Anvin wrote: >>> On 12/30/2010 01:08 PM, Robert Millan wrote: Hi folks, I had this unsubmitted patch in my local filesystem. It makes Linux detect ELF32 AMD64 binaries and sets a flag to restrict them to 32-bit address space. It's not rocket science but can save you some work in case you haven't implemented this already. >>> >>> I have pushed my old kernel patches to a git tree at: >>> >>> git://git.kernel.org//pub/scm/linux/kernel/git/hpa/linux-2.6-ilp32.git >>> >>> They are currently based on 2.6.31 since that was the released version >>> when I first did this work; they are not intended to be mergeble but >>> rather as a prototype. >>> >>> Note that we have no intention of supporting this ABI for the kernel >>> itself. The kernel will be a normal x86-64 kernel. >>> >> >> Here is the updated ILP32 patch for 2.6.35. >> >> > > I put my ILP32 gdb on hjl/ilp32 branch at > > http://git.kernel.org/?p=devel/gdb/hjl/x86.git;a=summary > > and my gcc 4.4 ILP32 on hjl/ilp32/gcc-4_4-branch branch at > > http://git.kernel.org/?p=devel/gcc/hjl/x86.git;a=summary > I checked a bunch ILP32 bug fixes into binutils, gdb and gcc. I also renamed the option from n32 to x32. Binutils and gdb should work correctly now. I tested them on a simple C library with static and dynamic binaries. Gcc only works with -O0. -- H.J.
Re: Proposal for automatic generation of c++ header files
> I am not mistaken. For a single Ada program that compiles > successfully, there is 1-to-1 correspondence of a package declaration > and package body. > > > > > It's not uncommon to have multiple different implementations of the > > same specification, for example for different target architectures or > > one might be production and the other development. > > That's what conditional compilation, modules and build systems are for. Sure, but that doesn't change the issue of where to put documentation. Let's look at a typical real-world case. You're writing an FMS (Flight Management System) for airplanes. One of the critical things is knowing your "state vector", where you are and how fast you're moving. So your company has a sophisticated navigation package that has a function to which you supply which coordinate scheme and units you want used and it returns you the corresponding state vector. Given the number of coordinate schemes and units, it can take quite a lot of text to describe the specification of this package. And you have only ONE specification. However, you may have over a dozen different implementations. Some aircraft may have GPS, others not. There may be different INS's, each with different attributes. Various types of air data may be used. You very much want to have ONE common place that says "here's the specifications that all of these implementations need to meet". The implementations all may be quite different.
Re: Proposal for automatic generation of c++ header files
On 14 January 2011 16:39, Achilleas Margaritis wrote:
>
> I have already explained it, but I don't mind explaining it once more:
>
> 1) the pragma #autoinclude ("foo.hpp", "foo.cpp") instructs the
> compiler to generate the header 'foo.hpp' from the implementation file
> 'foo.cpp'.
>
> 2) the compiler opens the file 'foo.cpp'.
>
> 3) for every class found in the file 'foo.cpp', a relevant class is
> placed into the header.
You've forgotten something. What about headers included by foo.cpp?
You need to think in terms of translation units, not "foo.cpp" because
it would be possible to mix and match #include and autoinclude, so
foo.cpp might contain declarations and definitions from multiple
files. They can't all be included directly into the auto-generated
foo.hpp because that would ignore include guards. Consider:
// main.cpp
#include "bar.h"
#pragma autoinclude("foo.hpp", "foo.cpp")
If foo.cpp also includes bar.h then main.cpp would end up with that
file included twice.
So the auto-generated header would need to include bar.h *with* its
include guards (which means including it *before* preprocessing, which
is a big change to the stages of compilation)
or it would need to output #include "bar.h" into foo.hpp, which is
also a big change to the stages of compilation, as autoinclude needs
to happen before preprocessing.
(Should it also happen before converting the input files from the
basic source character set to the execution character set? Let me
guess, you haven't thought about those details.)
On 14 January 2011 16:18, Achilleas Margaritis wrote:
> On Fri, Jan 14, 2011 at 6:20 PM, Richard Kenner wrote:
>>>
>>> Feel free to correct me if I am mistaken.
>>
>> You are mistaken. ;-)
>
> I am not mistaken.
That makes it pretty clear to me that this is a waste of everyone's time.
