Is there any way to follow the bottom-up approach in C?

Question

Usually, the C language uses a top-down approach, and C++ uses a bottom-up approach. Is it necessary to follow these approaches? Can I follow a bottom-up approach in C? If so... how?

Answer 1

You can program objectivly with C if you like, make alot of functions and pointers to said functions with alot of structs and unions.

What do you mean with top-down and bottom-up approach?

Answer 2

There's no reason why you should limit yourself to top-down or bottom-up in either language.

In practice you combine different approaches, e.g.:

• bottom-up if there are clear small parts that can be developed and tested separately
• top-down if you have a good overview of the global structure but you don't know all the details yet

When combining all the different approaches, also look at other good practices, like design patterns.

Answer 3

If it's even true, this is a statement about C and C++ programmers, not a statement about the languages.

It may be the case that C++ programmers are more likely to think about their programs as collections of small, reusable components. They would then tend towards bottom-up design.

It may be the case that C programmers are more likely to think about their programs as one monumental task, which they subdivide into smaller, easier tasks. They would then tend towards top-down design.

Or there may be no such trend. Neither language obstructs either approach. For example, suppose I want to write some code that analyses some data and prints a report. Here's a top-down approach in C:

# first version of the code (doesn't compile)
raw_data = read_the_data();
processed_data = perform_the_analysis(raw_data);
report = prepare_report(processed_data);
puts(report);

For a bottom-up C approach, I might first write some very general, re-usable code that parses the stored data format, because I know I'm going to want to load data. Likewise I'd write some code that operates on the parsed form of the data in various ways that are generally useful given the nature of the data. Then I'd write code that uses these tools to analyse the data as required in my particular app, write code that builds the report I want, then pull it all together.

In C++ I'd do much the same, in both cases, except that I wouldn't be designing data structures and functions that operate on them, I'd be designing classes that encapsulate data together with relevant essential operations on that data, and then non-member functions that work with the classes.

You can end up with fairly similar code either way. One area where it makes a bigger difference is testing - if you build bottom-up, then as soon as you've written any code at all, you've written something that works, that you can usefully test. It's possible to test a top-down framework without any of the components implemented, with suitable fake components, but I'm often not confident how realistic that test is.

I'm not aware that C++ programmers are any more or less anxious than C programmers to have something concrete ASAP. The trade-off you're making is thinking about the big picture vs. thinking about something that you can implement right now in a reasonable chunk of work, and how to get the two to meet. Also thinking about solving the problem you have at hand, vs. thinking about how, in general, to solve problems involving the things that your problem involves. Those aren't really language issues.

Answer 4

These terms usually refer to design rather than coding. Once you gave created your design, you can start at the bottom, top, or in the middle if you choose, or in a team, do it all concurrently. The choice of implementation direction itself should not effect the nature of the code.

Bottom-up would involve defining elements that may be useful in composing a final application; this is typically what you would do if creating domain specific library code; you would encapsulate all the domain specific knowledge in the library, but any particular application may use only part of it. This is productive if you are likely to implement multiple projects utilising the domain, or even market the library itself as a product, but is less so for one-off usage since you may end up designing and implementing components that you never use.

Often even with a top-down design, you would want to implement bottom-up, so that the higher level components have all they need in place to allow immediate integration testing using components already unit tested. This simply means implementing components with no undefined dependencies first, then the components that depend on those and so-on. To do this you still need a top-to-bottom design in order to know what to implement. In a top-down implementation approach on the other hand, you can concurrently design top-down. In practice on a large project you are likely to design and implement in vertical slices (incremental development), doing top-down or bottom-up (or both) iteratively.

Perhaps you could think of the approaches this way: Bottom-up is like buying a tool kit, including tools you may never use or even know how to use. Top-down is like buying the tools as you need them; its cost effective, but the tools may be very specialised, and you are only ever equipped to do work similar to previous jobs until you invest in new tools; so new work takes longer.