Need assistance, where to start?

Thetargos · #1 9th November 2007, 07:47 PM

Hello all.

I'm usually more of a lurker of this forum than an actual poster, and even though I do have some (very basic) knowledge of C/C++, and can actually read (and most of the time, understand) some code, I am no coder. So I come to you for help.

A bit of background.

I'm a physician, and even though I own my own office for my practice, I've gotten fed up by these "on-line medical file" systems that are available commercially, they cost a LOT of money and often times don't do what I want them to do. They get the job done, though, alas 'just' done. To add insult to injury there are no commercial products for Linux nor many Open Source alternatives (that I could find) which could adequate to my needs, and since I'm a 'do-it-yourself' kind of man, I've decided to take matters into my own hands.

My problem.

One slight problem, though: I realize I know very little about coding, even though I know much of the C language, I don't actually use it much, outside some simple programs I've done to facilitate things a bit, nothing fancy outside of a single .c file with ~1000 lines of code, and there's a LOT I don't know/understand about coding.

One thing I've noticed about many programs is that the style of coding many programmers use in Linux seem to be like the OS itself: Modular. Not pouring everything into a very large .c file, but rather to split their code into .h header files, and other, smaller .c files, then integrate everything into a main.c file. I understand the general idea and why are .h header files used, and even I kind of understand how to make them and why are they important, what I have much trouble with is how do you actually use functions, methods and routines you may have written into another .c file from any given .c file or the main.c file? (I don't know if I made much sense there), in other words, how do you reference said pieces of code from one file to another? I know of the extern keyword, but how do you actually use it? (I never did, as I've never understood how to use it, and the documentation I've got wasn't too thorough on it)

I've got some C documentation in form of books (two of them) but they are fairly basic. What are the best resources/tutorials for learning C/C++ focusing on Linux? I pretty much have all the software requirements met (I've had to build a lot of stuff from source lately) for starting out (again) on coding, I also have some good references for autoconf and automake, as well as pkgconfig. I also have some good documentation on GTK+ (which is what I'd like to use for the time being) . Any pointers would be very much appreciated.

markkuk · #2 10th November 2007, 10:25 AM

Quote:

Originally Posted by Thetargos

what I have much trouble with is how do you actually use functions, methods and routines you may have written into another .c file from any given .c file or the main.c file? (I don't know if I made much sense there), in other words, how do you reference said pieces of code from one file to another?

You declare the function prototype in a header file, then you #include that header file in any .c source files where you want to use the function. Functions are called the same way no matter if they are defined in the same source file or in some external file. The "extern" keyword is normally used only for global variables (that should be avoided in well-structured programs), not functions.

pete_1967 · #3 10th November 2007, 11:16 AM

If you want dead-tree reading:

For learning C: C Primer Plus by Stephen Prata and The C Programming Language by Brian W. Kernighan and Dennis Ritchie
For C++: Beginning ANSI C++ by Ivor Horton and The C++ Standard Library by Nicolai Josuttis, for reference The C++ Programming Language: Language Library and Design Tutorial by Bjarne Stroustrup
For GCC: The Definitive Guide to GCC by William von Hagen
For GTK+: Foundations of GTK+ Development by Andrew Krause
and for wxWidgets: Cross-Platform GUI Programming With wxWidgets by Julian Smart and Kevin Hock

Thetargos · #4 10th November 2007, 07:00 PM

Quote:

Originally Posted by markkuk

You declare the function prototype in a header file, then you #include that header file in any .c source files where you want to use the function. Functions are called the same way no matter if they are defined in the same source file or in some external file. The "extern" keyword is normally used only for global variables (that should be avoided in well-structured programs), not functions.

OK, so what you are saying is that it would be best to generate your won API (function prototype definitions in header files, use those in any source file). My question would be why then split the source in many different .c files which one or many will generate in turn different .o object files, to finally be linked in a binary (.so library, .la library, .a library or executable). What's the advantage of splitting functions like that at the source level. I understand why it is good to have a binary and other libraries for some routines. Please bare with me on this, as this is my first attempt at a complex project.

Thetargos · #5 10th November 2007, 07:11 PM

Quote:

Originally Posted by markkuk

You declare the function prototype in a header file, then you #include that header file in any .c source files where you want to use the function. Functions are called the same way no matter if they are defined in the same source file or in some external file. The "extern" keyword is normally used only for global variables (that should be avoided in well-structured programs), not functions.

OK, so what you are saying is that it would be best to generate your won API (function prototype definitions in header files, use those in any source file). My question would be why then split the source in many different .c files which one or many will generate in turn different .o object files, to finally be linked in a binary (.so library, .la library, .a library or executable). What's the advantage of splitting functions like that at the source level. I understand why it is good to have a binary and other libraries for some routines. Please bare with me on this, as this is my first attempt at a complex project.

skoona · #6 12th November 2007, 12:34 AM

Thetargos,

It seems your about to embark on writing your own application. I am offering to help you get started and possibly finish. I have no real reason choose a medical application over any other type - I just like to help when and where I can. So if you want to write one and need project help, stake your claim by creating a sourceforge project and soliciting help to write this application; or you can do this off-line until it matures.

James,

Partial Answer:
1. First I write out a general outline of the applications primary purpose and its outputs (paper or results screens).
2. Next I create a basic directory tree for the application.
* ~HOME/devSpace/project-name
* ~HOME/devSpace/project-name/src
* ~HOME/devSpace/project-name/pixmaps
* ~HOME/devSpace/project-name/configs
* ~HOME/devSpace/project-name/doc
* ~HOME/devSpace/project-name/include
* ~HOME/devSpace/project-name/logs
3. Then I create seperate source files and headers for each major gouping. ./src
* project.h -- main header
* project-gui.c -- user interface & signals
* project-utils.c|h -- coding utility routines; often conversions, record pack/unpacking, logging
* project-net.c|h -- network handler routines if needed
* project-database.c|h -- data access routines
* project-core.c|h -- primary functions for the applications
* project-widget-A.c|h -- one or maore special widgets or gobjects created for this app
4. The general ideal for each source grouping is to have a few functions be declared as 'extern' and most of the remaining files be 'static' ly defined as local use only. The assumption is that that files functions do one whole thing, and that the extern functions are there to request that service; so func_*new(), *set-param(), *set-control-value(), *run() ,*destroy(). All the other routines help implement those top level routines.
5. I usually start developing the application without 'autoconf tools' first, using just a simple makefile. When I am far enough along that I have added routines to every sourcefile, or ruled out certain source files, I switch to using an 'autoconf' script.
6. I personally start the app by drawing (pencil & paper) what I think the gui might look like. Then I create it (the gui) to the fullest extent possible. When I get to the point where i can say "this funciton here". I create an empty shell of that function inline to my gui code, in the header for that group, and as a template in the group file.
7. With the GUI in place I would add the other functions as needed to complete each of the goals of the applications; one at a time. repeat until done.
8. From the GUI source file to the other group files - the functions being called should be define with the extern attribute; any internal function that that routine calls should normally be defined as static.
9. Functions defined in the other source files should have function prototypes with the extern attribute declared in their header file. The top level module or gui.c should include each header file as needed.

Books and examples are a good way to learn this; However, the best way to learn is to do it and write one for yourself.

skoona · #7 12th November 2007, 12:46 AM

Quote:

Originally Posted by Thetargos

(A).My question would be why then split the source in many different .c files which one or many will generate in turn different .o object files, to finally be linked in a binary (.so library, .la library, .a library or executable).
(B). What's the advantage of splitting functions like that at the source level. I understand why it is good to have a binary and other libraries for some routines.

A. If you group related functions in one source file it is sometime easier to work with the source code. Remember you will have to page through all that code to make changes and add new routines. Four ten page files may be easier to navigate than one forty page file.

B. Creating an executable or a library: Most projects focus on creating an executable first. If your applications core function could be used by other programs/projects then creating a library (i.e. *.so, *.la...) is the way you package your core functions so they can be shared. Lots of reasons to include a library, wait until you know exactly why you need one before attempting to plan or create one. i.e Ignore it until you can't.

Dies · #8 12th November 2007, 12:56 AM

<Don't mind me.... just tagging this thread>

I'm sure skoona's posts will come in handy.

Thetargos · #9 12th November 2007, 07:25 PM

Wow! Skoona, THANKS a lot, man! I'm still lost reading your post, but will get to work ASAP. I've really gotten fed up with these Windows-only applications. First, I think, I have to outline what do I want the application to actually do, and how to do it... I was thinking on using Glade to "mock up" the GUI elements, then reviewing the code to see if I need any special widgets (I still have yet to learn how to actually create custom GTK widgets

). Thanks a lot for the suggestions.

skoona · #10 12th November 2007, 09:43 PM

"... actually do...", yes first write it down. Most projects fail right here on this step. Do not describe the world, do not try to be all things to all people. Go for one single thing for now, when thats done go back and define/code the next thing.

If you are not already a Glade user, please don't start now. I code GTK directly, this lets me maintain control of all aspects of the application. Glade imposes its own contraints and coding rules -rules that have no relevance to the application problem your trying to solve.

I think its pretty early for custom GTK widget to be a concern,; However there is a ton of documentation and examples available on how to make a Custom GTK widget. Search sourceforge.net for 'glinegraph' a small x/y linegraph widget example. GTK's own widget are also available to copy/study/reuse - get the source for GTK and look it over.

Everybody has a view on which developers tools are best. You have to pick one and start using it now. Personally I use eclipse with the cdt project plugin as my development IDE. Use whatever you want; no ide is neccasarily better than another, etc, etc...

Documentation: the executable programs 'devhelp' and 'gtk-demo' are great starter tools to have open when doing learning to code gtk. They should already be loaded on you Fedora systems.

Ok, ready when you are! Go try something, so we can help.

Thetargos · #11 13th November 2007, 04:05 AM

Skoona, thanks a LOT. I have limited experience with both, coding GTK directly and using Glade, you are right about Glade imposing a coding style and that it has a lot of constraints (which could be circumvented, but would also be needless work). I thought of using it merely as a tool to mock things up and "see" how something might work. I though of actually manually doing the GTK coding, since I've got (albeit limited) already experience with it at the code level (following the official tutorial, that is).

I've got quite a bit of stuff to write down so I can have a clearer picture of what I want. I already know what in general terms, I want to do, BUT I need to brake it down into smaller pieces and, like you said, start doing things as if it were LEGO (i.e one piece at a time).

About an IDE, back when I started to try and learn (just for kicks) GTK and C, I started using Anjuta, then the project sort of died and I believe it was then picked up again by some voluteers. I liked the program quite a bit (you could see the rough edges, and stuff that the author left for a later time, but they never became true). I think I'll give Eclipse a try, I've also used KDevelop (reminds me way too much of Visual Studio) and plain old VIM.

As far as auto-tools go, I've got good documentation already in hand, so I'll go back to that whenever I'm ready to mess with them (Linux Programming Unleashed). Right now I need to further shape up this project I've got in my hands

As far as custom GTK widgets go, I'll most certainly need them down the road, but like you said, I'd better start doing one thing at a time. Thanks a LOT again for your interest and help, Skoona.

skoona · #12 13th November 2007, 04:28 AM

Thetargos,

If you have experience with Anjuta, use it. Its a fine tool. Also, if your just using Glade as a mockup tool - that works too for mockups. Open Presentation, or gimp, is also a good GTK GUI mockup tool.

Let me know if I can help. Private messages are ok, as are instant messages. I'm on EST time.

Thetargos · #13 13th November 2007, 07:40 AM

Again, thanks a LOT. I'm on CST, and I'll prolly take you up on that PM/IM

However, FIRST, I have to write down all I've got in my head so to have a better idea of WHERE to actually start, and build the mock up. I'd use GIMP/Inkscape/gLabels for the mock up, but Glade has the advantage that it is an "interactive" mock up, as I can actually "build it" and see how it might "feel". Thank you for your advice. Since I've not used Anjuta for a while (and even though the latest stable version is in the repos), I might just give Eclipse a whirl, just for kicks. Still I'd better make up my mind in time for the "real" development. I'm not sure how well does Anjuta support "project management" which I know (or heard of, anyway) Eclipse does.

skoona · #14 13th November 2007, 11:43 AM

Anjuta starts out better then eclispe as far a autoconf tools go; however, eclispe recently added autoconf support and I have not had a chance to try it. So if your going the eclispe route, we will both find out how good it is.

Mocks up. send me a picture(gimp or scanned from paper) and I will send you back a gtk source file that matches. Or for that matter and Glade layout. What ever is easier for you. I'm thinking this will help you get started faster if you see how one interation of your design is coded.

my email is 'skoona at verizon.net'

Thetargos · #15 13th November 2007, 04:27 PM

Thanks a ton, man! I'll get to do it today, maybe by tomorrow I'll have something as a mock up that I can send.