«

Is there a more or less accepted authority describing how to structure a
project? I know Julie has asked about namespaces. That is certainly a
part of my question, but I want to know about the whole picture.

If such a thing doesn't exist, then would someone with enough name
recognition to have an influence please decree such a guideline. I'd be
happy to simply be able to say my project is organized in accordance with
the [place name here] recommendation.

The KDE has an approach, so does Mozilla, I trust GNOME also has some kind
of proscribed structure. Perhaps my best bet is to examine these projects
and select what I find useful from each. I would like to have some sense
that my projects are organized in such a way as to be readily understood by
other programmers who share widely accepted conventions. I also want my
work to integrate smoothely with other people's.

I'm a firm believer in the idea that even the smallest project should
conform to extensible conventions. I want to get in the habit of doing
things right, but I don't really know what right is.

Stroustrup provides some discussion of these issues in the final chapters of
TC++PL(SE). Have his recommendations been adopted by a large number of
programmers? I have not yet read the chapters. Are they thorough enough to
provide a solid foundation for organizing a large-scale project?

Maven is something I am aware of form a past life:

http://maven.apache.org/

It's actually a bit too broadly focused for my purposes. I'm only
presenting it as an example of the kind of thing I'm looking for.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

Steven T. Hatton wrote:
<snip>
>
> Stroustrup provides some discussion of these issues in the final
> chapters of TC++PL(SE). Have his recommendations been adopted by a
> large number of programmers? I have not yet read the chapters. Are
> they thorough enough to provide a solid foundation for organizing a
> large-scale project?
>

I thought of these chapters when I saw the subject text. I highly suggest
you read the chapters; they're very good IMO.

- Pete

<snip>

Steven T. Hatton wrote:

> Is there a more or less accepted authority describing how to structure a
> project? I know Julie has asked about namespaces. That is certainly a
> part of my question, but I want to know about the whole picture.

These are mostly Software Engineering issues.
You might try

"Large-Scale C++ Software Design" by John Lakos.

http://www.amazon.com/exec/obidos/tg...29721?v=glance

But be careful. It was published in July 1996
and contains some out-of-date recommendations.

"Steven T. Hatton" wrote:
>
> Is there a more or less accepted authority describing how to structure a
> project? I know Julie has asked about namespaces. That is certainly a
> part of my question, but I want to know about the whole picture.

Have you looked at the NASA SEL?

I looked at that a *long* time ago, and don't remember anything about it, but
it just popped into my head...

"E. Robert Tisdale" <> wrote...
> Steven T. Hatton wrote:
>
> > Is there a more or less accepted authority describing how to structure a
> > project? I know Julie has asked about namespaces. That is certainly a
> > part of my question, but I want to know about the whole picture.
>
> These are mostly Software Engineering issues.

So, why not recommend news:comp.software-eng ?

> [...]

"Julie" <> wrote
> "Steven T. Hatton" wrote:
> >
> > Is there a more or less accepted authority describing how to structure a
> > project? I know Julie has asked about namespaces. That is certainly a
> > part of my question, but I want to know about the whole picture.
>
> Have you looked at the NASA SEL?
>
> I looked at that a *long* time ago, and don't remember anything about it,
but
> it just popped into my head...

That's a good source for very abstract information, but it has very little
that would help with C++ specific issues. The articles are also of varying
quality. The best I've found were the ones on quality metrics and the ones
on fault tolerance.

Claudio Puviani

Claudio Puviani wrote:

> "Julie" <> wrote
>> "Steven T. Hatton" wrote:
>> >
>> > Is there a more or less accepted authority describing how to structure
>> > a
>> > project? I know Julie has asked about namespaces. That is certainly a
>> > part of my question, but I want to know about the whole picture.
>>
>> Have you looked at the NASA SEL?
>>
>> I looked at that a *long* time ago, and don't remember anything about it,
> but
>> it just popped into my head...
>
> That's a good source for very abstract information, but it has very little
> that would help with C++ specific issues. The articles are also of varying
> quality. The best I've found were the ones on quality metrics and the ones
> on fault tolerance.
>
> Claudio Puviani

I believe I found my answer WTFM!
http://docs.kde.org/en/HEAD/kdevelop.../newfiles.html
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

Julie wrote:

> "Steven T. Hatton" wrote:
>>
>> Is there a more or less accepted authority describing how to structure a
>> project? I know Julie has asked about namespaces. That is certainly a
>> part of my question, but I want to know about the whole picture.
>
> Have you looked at the NASA SEL?
>
> I looked at that a *long* time ago, and don't remember anything about it,
> but it just popped into my head...

This is a living example of one of the most successful C++ dominated
software projects ever: http://www.mozilla.org/projects/

I recall looking at the NASA site a while back as well. The kind of stuff
I'm looking for is not the high-level abstraction, how to design your
interfaces between packages, etc., kind of literature. I want more
fundamental guidance on how to use the plethora of alternatives provided by
the features described in the Standard. I just read through Clause 3
(Chapter 3) of PL-C++03. This is out of date, but it will give a hint of
what the current document reads like. The stuff on name lookup is
mind-boggling. http://www.itga.com.au/~gnb/wp/cd2/

I do have a way of establishing a pretty powerful project structure in a
hurry. The KDE and KDevelop are doing a wonderful job. Unfortunately, some
of the outstanding performance is due to the contributions of uniquely
tallanted people, and not a codified approach. But it is open to
examination: http://ng-project.org/~kdevelop/apid.../inherits.html

The following is from a 'hello world' created by KDevelop:

hattons@ljosalfr:~/code/c++/managed/
Wed Apr 07 04:30:01:> find . -name "*"
..
../po
../po/Makefile.am
../po/Makefile.in
../doc
../doc/en
../doc/en/Makefile.am
../doc/en/Makefile.in
../doc/en/index.docbook
../doc/Makefile.am
../doc/Makefile.in
../src
../src/hi16-app-managed.png
../src/managed.cpp
../src/managed.lsm
../src/main.cpp
../src/managed.h
../src/Makefile.am
../src/Makefile.in
../src/managedui.rc
../src/hi32-app-managed.png
../src/managed.desktop
../NEWS
../TODO
../admin
../admin/CVS
../admin/CVS/Root
../admin/CVS/Repository
../admin/CVS/Entries
../admin/CVS/Template
../admin/compile
../admin/Doxyfile.global
../admin/depcomp
../admin/Makefile.common
../admin/ltmain.sh
../admin/config.pl
../admin/configure.in.min
../admin/config.guess
../admin/acinclude.m4.in
../admin/install-sh
../admin/config.sub
../admin/missing
../admin/mkinstalldirs
../admin/cvs.sh
../admin/bcheck.pl
../admin/nmcheck
../admin/conf.change.pl
../admin/am_edit
../admin/libtool.m4.in
../admin/ylwrap
../admin/cvs-clean.pl
../admin/debianrules
../admin/detect-autoconf.sh
../admin/ChangeLog
../admin/Doxyfile.am
../admin/configure.in.bot.end
../debug
../debug/po
../debug/po/Makefile
../debug/doc
../debug/doc/en
../debug/doc/en/Makefile
../debug/doc/en/index.cache.bz2
../debug/doc/Makefile
../debug/src
../debug/src/Makefile
../debug/src/.deps
../debug/src/.deps/managed.Po
../debug/src/.deps/main.Po
../debug/src/.libs
../debug/src/managed.moc
../debug/src/managed
../debug/src/managed.o
../debug/src/main.o
../debug/Makefile
../debug/config.status
../debug/libtool
../debug/config.log
../debug/config.h
../debug/stamp-h1
../aclocal.m4
../README
../configure
../autom4te.cache
../autom4te.cache/requests
../autom4te.cache/output.0
../autom4te.cache/traces.0
../configure.in
../subdirs
../Makefile.am
../Makefile.in
../configure.files
../configure.in.in
../config.h.in
../Makefile.cvs
../acinclude.m4
../managed.kdevelop
../stamp-h.in
../AUTHORS
../INSTALL
../ChangeLog
../COPYING
../Doxyfile
../templates
../templates/h
../templates/cpp
hattons@ljosalfr:~/code/c++/managed/


But, now I want to pull in stuff from boost, and Xerces. I know some of
it's just a question of time and experience, but there also seems to be
something fundamentally missing that would pull everything together. I'm
trying very hard not to draw comparrisons, but I've see some aspects of
programming managed more effectively than a lot of C++ stuff.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org