How to start a C++ software project?

[shuisheng]

Dear All,

I want to start a c++ software project. It is used to simulate the
propagation of sound waves in complex media. It may contain 4 parts:
GUI, preprocession, simulation and postprocession. Users can use GUI
to model their geometry, set some parameters and show the results.

The system is kind of large. I have no expierence in large codes. But
I am very familiar with the physics part and what functionaloty the
system should provide. Seems for a large system, we need do
requirement analysis, architecture design and so on. Anybody can give
me some suggestion? May I jump over them to directly code the program?
This may make the project begin immedialtly and fulfill early.

I appreciate your kind help!

Shuisheng

[Victor Bazarov]

shuisheng wrote:

I want to start a c++ software project. It is used to [...]

The system is kind of large. [..]
Seems for a large system, we need do
requirement analysis, architecture design and so on. Anybody can give
me some suggestion?

You're in a wrong newsgroup. You need to ask in comp.software-eng.
The language in which you do it does *not* matter.

May I jump over them to directly code the program?

Yes, you may. You have my expressed permission. Should you? I
don't think so. But who am I to tell you?

This may make the project begin immedialtly and fulfill early.

I think everyone should do it that way, at least once in their
lifetime. Figure out how much time you can afford to waste on
this and just do it!(tm) I mean, go ahead and waste your time!
You will most likely get NOTHING out of it except maybe some
bits a pieces of the very low-level code. But then again, if
you don't gain anything, you gain experience, right?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Michael]

I want to start a c++ software project.

>
The system is kind of large. I have no expierence in large codes.
May I jump over them to directly code the program?
This may make the project begin immedialtly and fulfill early.

To add to Victor's suggestions:
1) Before you start, get a version control system. I use Subversion +
TortoisSVN on Windows, but there are plenty of others, depending on
your OS and proclivities. At first it will seem like overkill, but
when you have some code working, then you break it, you'll be able to
get back to where you were, and will experience bliss. (Also, you'll
be able to make more changes without having to worry too much about
breaking things, because you'll always be able to get back if you need
to.)

2) There are several different development methodologies that are used
for larger projects. What they all have in common is that you
implement some pieces, test those pieces, then implement some more,
and test those, and eventually you build the whole thing in terms of
pieces that work.

Two common methodologies:
A) Structured design. This is the one they used to teach a long time
ago when I went to school.
For example, write:
int main() {
preprocess();
simulate();
postprocess();
}

Then write the preprocess function in a similar high level. Say:

void preprocess() {
preprocessA();
preprocessB();
int result = preprocessC();
if (result 3) {
preprocessD();
} else {
preprocessE();
}
}

Now write preprocessA in pieces like this. Eventually, you get to the
point where each pieces is small enough that you can write the actual
code without calling any more functions. Then you're done.

2) Agile method. This is a more modern methodology
Make a 1-page or so list of features. This probably won't take more
than 1/2 an hour.

Pick one that's the highest priority and implement it. Then pick
another and implement it, etc.

For each feature, maybe start with the most watered-down version you
can imagine, then add additional functionality until it's complete.

For example, in your case, I might decide to start with the GUI. My
first thing would be to create a window that has static text saying
"GUI coming soon." Then I'd test and make sure that works. Then I'd
change it so it has 3 buttons (assuming that's what I needed), and
when you click each one it says "You clicked Button 1" or something
like that. Then test. And piece by piece, get it working.

3) Use the KISS principle (Keep It Simple, Stupid). Large projects
are hard, and are frequently killed by trying to be too ambitious and
do everything, and as a result, you get nothing. It's much better to
prioritize and do the most important things and get them working, then
add bells and whistles later.

Good luck on your project.

Michael

[Kaz Kylheku]

On Feb 22, 9:13 am, "shuisheng" <[e-mail]:

I appreciate your kind help!

Just this: C++ is a poor choice of language for situations where you
don't initially know what you are implementing or how to implement it,
but acquire that knowledge in an exploratory way.

Firstly, you are constrained by edit-compile-link-run cycles. The
entire program has to be well-formed; everything has to dove-tail
before you can execute any of it. This property also makes programs
resistant to many of the kinds of changes you might want to experiment
with in an iterative development situation, by assigning a large cost
to those experiments: the conceptually small change requires too large
of a ripple of collateral changes so that the program continues to
compile, build and run. Insulating modules to minimize their
dependencies requires a bit of know how, and also the development of
various shims which clutter the program because they exist only for
the sake of that insulation.

The only part of your idea that benefits from C++ is the actual
simulation of the propagation of sound waves in the given given
geometry. This could be encapsulated as a library with some well-
defined binary interface: data types for communicating the model to
the library, functions for setting up the simulation paramters and
doing the simulation, and ways of obtaining the results in some given
representation, possibly with real-time feedback.

The rest of the surrounding software could be done up in some dynamic
language that has a decent GUI toolkit and a foreign-function calling
capability.

Another thing to consider is how much existing software could you
reuse. There is already software out there which can create three-
dimensional models and export them in some known format that other
programs can parse. That could be good enough for creating the
geometry for these sound wave simulations. I understand that the
objects in the model have to be attributed with additional properties
related to acoustics, but maybe some modelling programs have a way to
represent that with some user-defined generic attributes that can be
attached to the model elements.

[Noah Roberts]

Kaz Kylheku wrote:

On Feb 22, 9:13 am, "shuisheng" <[e-mail]:

Firstly, you are constrained by edit-compile-link-run cycles. The
entire program has to be well-formed; everything has to dove-tail
before you can execute any of it. This property also makes programs
resistant to many of the kinds of changes you might want to experiment
with in an iterative development situation, by assigning a large cost
to those experiments: the conceptually small change requires too large
of a ripple of collateral changes so that the program continues to
compile, build and run.

Utter and total nonsense.

[Ian Collins]

Noah Roberts wrote:

Kaz Kylheku wrote:

>On Feb 22, 9:13 am, "shuisheng" <[e-mail]:

>Firstly, you are constrained by edit-compile-link-run cycles. The
entire program has to be well-formed; everything has to dove-tail
before you can execute any of it. This property also makes programs
resistant to many of the kinds of changes you might want to experiment
with in an iterative development situation, by assigning a large cost
to those experiments: the conceptually small change requires too large
of a ripple of collateral changes so that the program continues to
compile, build and run.

Utter and total nonsense.

As someone who enjoys XP and TDD with C++, I have to agree. C++ is no
better or worse than any other language for this type of development.

--
Ian Collins.

[Fei Liu]

shuisheng wrote:

Dear All,

I want to start a c++ software project. It is used to simulate the
propagation of sound waves in complex media. It may contain 4 parts:
GUI, preprocession, simulation and postprocession. Users can use GUI
to model their geometry, set some parameters and show the results.

The system is kind of large. I have no expierence in large codes. But
I am very familiar with the physics part and what functionaloty the
system should provide. Seems for a large system, we need do
requirement analysis, architecture design and so on. Anybody can give
me some suggestion? May I jump over them to directly code the program?
This may make the project begin immedialtly and fulfill early.

I appreciate your kind help!

Shuisheng

I personally found it very efficient to follow the following cycle to
implement large software system:

1) research, see what features are required, any existing
software/library that can speed up the development, what are the
platforms to support, what tools should be used, etc

2) design and documentation, express your software system in clear text
what it does, how it does it. Try to be as precise as possible.

3) unit testing of tools, 3rd party softwares, and libraries, this is
often partially done in phase 1, but at this stage a through and
in-depth unit testing framework should be employed.

4) I personally prefer developing software by component and writing unit
test alone the way. Never underestimate the power of unit testing, even
the simplest test can save you hours of headache.

5) packaging and integration. If design is sound and documentation is
clear, software development is simply a matter of man-hour.

6) more testing.

[Fei Liu]

Fei Liu wrote:

shuisheng wrote:

>Dear All,

I want to start a c++ software project. It is used to simulate the
propagation of sound waves in complex media. It may contain 4 parts:
GUI, preprocession, simulation and postprocession. Users can use GUI
to model their geometry, set some parameters and show the results.

The system is kind of large. I have no expierence in large codes. But
I am very familiar with the physics part and what functionaloty the
system should provide. Seems for a large system, we need do
requirement analysis, architecture design and so on. Anybody can give
me some suggestion? May I jump over them to directly code the program?
This may make the project begin immedialtly and fulfill early.

I appreciate your kind help!

Shuisheng

I personally found it very efficient to follow the following cycle to
implement large software system:

1) research, see what features are required, any existing
software/library that can speed up the development, what are the
platforms to support, what tools should be used, etc

2) design and documentation, express your software system in clear text
what it does, how it does it. Try to be as precise as possible.

3) unit testing of tools, 3rd party softwares, and libraries, this is
often partially done in phase 1, but at this stage a through and
in-depth unit testing framework should be employed.

4) I personally prefer developing software by component and writing unit
test alone the way. Never underestimate the power of unit testing, even
the simplest test can save you hours of headache.

5) packaging and integration. If design is sound and documentation is
clear, software development is simply a matter of man-hour.

6) more testing.

My personal experience also shows that it often helps to master a
prototyping language such as Perl or Python, or one of the scripting
languages. I often prototype in Perl first then translate the whole
thing into C++. Again this is from my own personal experience, it's
simply much faster developing in Perl than in C++, however Perl
application's performance almost always lackluster in performance
critical environment.

Fei

[Gianni Mariani]

Noah Roberts wrote:

Kaz Kylheku wrote:

>On Feb 22, 9:13 am, "shuisheng" <[e-mail]:

>Firstly, you are constrained by edit-compile-link-run cycles. The
entire program has to be well-formed; everything has to dove-tail
before you can execute any of it. This property also makes programs
resistant to many of the kinds of changes you might want to experiment
with in an iterative development situation, by assigning a large cost
to those experiments: the conceptually small change requires too large
of a ripple of collateral changes so that the program continues to
compile, build and run.

Utter and total nonsense.

seconded.

[u.int.32.t]

On Feb 22, 1:00 pm, Noah Roberts <[e-mail]:

Kaz Kylheku wrote:

On Feb 22, 9:13 am, "shuisheng" <[e-mail]:
Firstly, you are constrained by edit-compile-link-run cycles. The
entire program has to be well-formed; everything has to dove-tail
before you can execute any of it. This property also makes programs
resistant to many of the kinds of changes you might want to experiment
with in an iterative development situation, by assigning a large cost
to those experiments: the conceptually small change requires too large
of a ripple of collateral changes so that the program continues to
compile, build and run.

Utter and total nonsense.

A bit harsh. To do a C++ project properly I usually need to do the
following:

0) Decide on toolset(s) for my platform(s)
1) Decide on a build system which supports my platform(s)
2) Decide on a unit testing framework
3) Decide on which third party libraries you need
4) Learn about 1-3
5) Integrate 2 into 1 (and build 2-3 for 0 for the platform(s) you are
on)
6) Write some code

Heaven forbid you get some flags wrong when building your third party
libraries.

Just my 2c

[Ian Collins]

u.int.32.t wrote:

On Feb 22, 1:00 pm, Noah Roberts <[e-mail]:

>>Kaz Kylheku wrote:

>>>On Feb 22, 9:13 am, "shuisheng" <[e-mail]:
Firstly, you are constrained by edit-compile-link-run cycles. The
entire program has to be well-formed; everything has to dove-tail
before you can execute any of it. This property also makes programs
resistant to many of the kinds of changes you might want to experiment
with in an iterative development situation, by assigning a large cost
to those experiments: the conceptually small change requires too large
of a ripple of collateral changes so that the program continues to
compile, build and run.

Utter and total nonsense.

A bit harsh.

Not at all.

To do a C++ project properly I usually need to do the
following:

0) Decide on toolset(s) for my platform(s)
1) Decide on a build system which supports my platform(s)
2) Decide on a unit testing framework

For each project? Stick to one for all.

3) Decide on which third party libraries you need
4) Learn about 1-3
5) Integrate 2 into 1 (and build 2-3 for 0 for the platform(s) you are
on)
6) Write some code

None of these relate to the contentious claim in the original post.

--
Ian Collins.

[u.int.32.t]

On Feb 25, 3:18 pm, Ian Collins <[e-mail]:

u.int.32.t wrote:

On Feb 22, 1:00 pm, Noah Roberts <[e-mail]:

>Kaz Kylheku wrote:

>>On Feb 22, 9:13 am, "shuisheng" <[e-mail]:
Firstly, you are constrained by edit-compile-link-run cycles. The
entire program has to be well-formed; everything has to dove-tail
before you can execute any of it. This property also makes programs
resistant to many of the kinds of changes you might want to experiment
with in an iterative development situation, by assigning a large cost
to those experiments: the conceptually small change requires too large
of a ripple of collateral changes so that the program continues to
compile, build and run.

>Utter and total nonsense.

A bit harsh.

Not at all.

Ok, well change a "core" header. Watch the ripples. No matter what you
say, every project will have one. Even if its just for
declspec(dllexport/import). Not everyone has read "Large Scale C++
Software Design".

To do a C++ project properly I usually need to do the
following:

0) Decide on toolset(s) for my platform(s)
1) Decide on a build system which supports my platform(s)
2) Decide on a unit testing framework

For each project? Stick to one for all.

You seem to be advocating using one hammer for all nails. Due
diligence and experience dictates otherwise. Even though I already
know a bunch of tools that I use quite regularly no matter which
project, my eyes are always open for when the tools don't fit the
requirements.

Say I need to have my source be portable to most platforms.
Performance is secondary. Do I waste time setting up all the
compilers? No, I just use g++.

Then the case will come along where x-platform + performance is
paramount. The best choice is the OS/HW vendor's compiler***. Then you
give up certain things on the C++ side (though this is slowly becoming
less of an issue in my experience) which you have to take into
account. You must set up buildbots on the non-developer compilers to
make sure things don't get too far out of hand before you know about
an issue. You have your automated tests run on all these platforms. So
you better make sure you do your research beforehand.

Of course this has been more the norm for me rather than the
exception. I understand most people are single platform developers and
might have different experiences.

*** You've performance tested g++ vs the vendor supplied one right?

3) Decide on which third party libraries you need
4) Learn about 1-3
5) Integrate 2 into 1 (and build 2-3 for 0 for the platform(s) you are
on)
6) Write some code

None of these relate to the contentious claim in the original post.

The points to which I was responding

>>Firstly, you are constrained by edit-compile-link-run cycles
the conceptually small change requires too large
of a ripple of collateral changes so that the program continues to

Anyway, if you want to do a good job, ime, you cannot just half-ass
the non-coding part of the process for C++ (thats been my main
experience so correct me if you can't half-ass that part of the
process for Java either).

</rant>

[u.int.32.t]

On Feb 25, 8:00 pm, "u.int.32.t" <[e-mail]:

Anyway, if you want to do a good job, ime, you cannot just half-ass
the non-coding part of the process for C++ (thats been my main
experience so correct me if you can't half-ass that part of the
process for Java either).

That should be "non-coding but still coding-related"

[Ian Collins]

u.int.32.t wrote:

On Feb 25, 3:18 pm, Ian Collins <[e-mail]:

>>u.int.32.t wrote:

>>>On Feb 22, 1:00 pm, Noah Roberts <[e-mail]:

>>>>Utter and total nonsense.

>>>A bit harsh.

Not at all.

Ok, well change a "core" header. Watch the ripples. No matter what you
say, every project will have one. Even if its just for
declspec(dllexport/import). Not everyone has read "Large Scale C++
Software Design".

Maybe so, but if I'm struck with such a project, I just throw more
hardware at it to parallelise the build. For my own projects, I take
more care.

What is declspec(dllexport/import)?

>

>>>To do a C++ project properly I usually need to do the
following:

>>>0) Decide on toolset(s) for my platform(s)
1) Decide on a build system which supports my platform(s)
2) Decide on a unit testing framework

For each project? Stick to one for all.

You seem to be advocating using one hammer for all nails.

I was referring to the testing framework.

--
Ian Collins.

[u.int.32.t]

On Feb 25, 9:38 pm, Ian Collins <[e-mail]:

u.int.32.t wrote:

Ok, well change a "core" header. Watch the ripples. No matter what you
say, every project will have one. Even if its just for
declspec(dllexport/import). Not everyone has read "Large Scale C++
Software Design".

Maybe so, but if I'm struck with such a project, I just throw more
hardware at it to parallelise the build. For my own projects, I take
more care.

Me too :)

What is declspec(dllexport/import)?

Basically a method of declaring the export (or import) of certain
symbols in your source code.

You seem to be advocating using one hammer for all nails.

I was referring to the testing framework.

lol! I use boost test.