How do I generate a .cpp file from source code? [closed] - c

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I'm starting with C programming, and have written a program and am ready to compile. I've heard that mingw is a good choice, but the documentation for using it starts with a .cpp file and then turns that into a .exe. What I currently have is just the pure source (i.e. just text commands), how do I turn that into a .cpp? Thanks.

A cpp file is a C++ source file. Many tools (compilers, editors, etc.) can work with .c files or .cpp files.
A source file refers to the actual code you write. You know, stuff like
int main() {
printf("Hello, world!");
return 0;
}
That would be source code. 4 lines of it. So generally, you can't generate it. You have to write it. It sort of sounds like you wrote a .c file and are getting confused because you're using a tool whose example uses a .cpp file.
If the tool works with both C and C++, then use it with the .c file.
If it only works with C++... then you'll have to use something else.

If you have written code in a file like "xyz.txt" then simply rename it to "xyz.c". Also, you can take a file named like "xyz.c" create a copy of it and rename that copy to "xyz.cpp" and then modify "xyz.cpp" so that it can be compiled as C++ code.
In either case the "xyz.c" when compiled becomes "xyz.exe" and "xyz.cpp" will also become an "xyz.exe" load module, but not the same as the one generated from C code.
If you want load modules for a program written in C and the same program written in C++ then you will have to give them different names, like: "xyz.c" and "abd.cpp".
Hope this helps, and welcome to our world of programming!

Related

Why does the standard C library feature multiple header files instead of consolidating the contents into a single header? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 months ago.
Improve this question
Why does the standard C library need to feature multiple header files? Would it not be more user friendly to consolidate it into one header file?
I understand that it is unnecessary to include function prototypes / global variables that go unused, however, won't the compiler eventually remove all of these references if they're unused?
Maybe I'm underestimating the size of contents spanning all of the header files. But it seems like I'm always googling to figure out what header I need to #include.
Edit: The top comment references a size of 50MB which appears to be untrue. The C library is relatively concise compared to other language's standard libraries hence the question.
// sarcasm ON
Build your own #include "monster.h" that includes all you want from the collection.
People write obfuscated code all the time. But, you won't be popular with your cohort.
// sarcasm OFF
The real reason? C was developed when storage was barely beyond punch card technology. A multi-user system might have 1/2Mb of (magnetic) core memory and a cycle time that is now laughable.
Yet, reams of C code was developed (and the story of the popularity of UNIX well known.)
Although new standards could change the details (and C++ has), there is an ocean of code that might/would no longer be able to be compiled.
Look up "Legacy".
There are (too many) examples of code in the world where the usual collection of, say, stdio.h, stdlib.h, etc. have been "hidden" inside #include "myApp.h". Doing so forces the reader to hunt-down a second file to verify what the &^%&%& is going on.
Get used to it. If it was a bad practice, it would not have survived for ~50 years.
EDIT: It is for a similar reason that "functions" have been "grouped together" into different libraries. By extension, pooling those libraries might make things a tiny bit "less cluttered", but the process of linking may require a supercomputer to finish the job before knock-off time.
EDIT2: Brace yourself. Cleanly written C++ code often has a .h and a .cpp for every class used in the app. Sometimes "families" (hierarchies) might live together in a single pair of files, although that can lead to boo-boo's when the coder is having a bad day...

Why do I have to import both header and C file? [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
In my main function I call the functions declared in my header file. I have imported my header file in the main. However, the compiler gives a undefined reference to function. The implementation of the functions of the header file are in another C file. To compile and work my main, I have to import the C file.
My question is: Why do I have to import the C file in addition to the header file.
For example when I include stdlib.h does this file also have the implementations of its functions or just the declarations?
If your code does not work unless you #include a C file, you are not compiling it right. You should compile the two modules separately, with the main module including only the header for your other module. Then you should link these together.
On UNIX running gcc you can do compilation and linking with a single command:
gcc helper.c main.c
Note: If you are developing on UNIX, you should learn how to use makefiles to manage separate compilation. Here is a tutorial covering the use of makefiles for compiling C++ code.
You don't have to include header files (sometimes), but linking with object files is mandatory. Object file contains the body of functions you try to use and that's why they can't be called without it.
Read further to find out why headers are important and their history
'#include" just tells the compiler the interface of the file that you are using. (The declaration). #include will make your compiler happy.
In addition you have to have the actual implementation(the definition) which is typically in the *c file. This makes the linker happy.
If you include the stdlib.h - the right C runtime is included for you.

Create a program from another program? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm making an application that will create a working executable based on what the end-user inputs into the program.
For example:
if (make_annoying_sounds == true)
{
//Generates an executable that makes annoying beeping sounds
}
else
{
//Generates an executable that doesn't make annoying beeping sounds
}
Basically I want my program to generate/create another program. I've seen/used many programs that do this. I have searched all over the internet and can't find anything. All help is appreciated. (Create a program, from within my program).
Try using a basic system call to invoke a compiler after you've created the source file.
You can create the source file with just the utilities found in stdio.h
Security Note: The system function is known to be dangerous. When in doubt, call a function like exec to invoke the compiler. Although exec erases the currently running process, so you should use fork and then call exec if you want to keep doing stuff after the compilation has finished.
So you want to create a compiler? This question below contains a whole list of resources to help you get started.
Learning to write a compiler
You need to do the following:
Based on the user input, generate the code for the custom program.
Compile that code into an executable file.
Theorically, you could, depending on what the user inputs, make your C code generate C-code inside your if statements. However this would be quite difficult.
The best way I think is to make an independent C engine which will only implement functions that any of the generated program can execute (playing the sound given in parameter, for example). The program you are trying to code (not the engine, but the one with the if statements, let's call it the "master program") must generate code which implements the algorithm which will choose what function of the engine to call and when. This generated code should be written in a scripting language like lua, since in is easier to generate script code than C. Thus, the engine should be designed to be able to communicate with Lua scripts. When the user clicks on the final "generate program" button of the master program, the master program calls gcc to compile the engine and the Lua script to generate the program the user tried to create. This is long, but this is, I think, the right way to do it.

Linking files with LD [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 9 years ago.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Improve this question
I read this tutorial: http://www.osdever.net/tutorials/view/writing-a-simple-c-kernel
I tried linking the files using the likerscript that the tutorial provides. But LD gives me an error saying that it cannot read the file put out by nasm. Does anyone know what I am doing wrong?
If you executed the tutorial precisely as shown, then the problem is most likely here:
nasm -f aout kernel_start.asm -o ks.o
This produces an object file in the thoroughly obsolete a.out format. You're probably working through the tutorial on either a Windows or a Linux host system; the linkers that come with these systems expect object files in PECOFF and ELF format, respectively. There is probably another thing you can put after the -f in the above command that will make nasm produce the correct format.
Alternatively, learn to write AT&T assembly language instead. Then you can make an object file out of your .asm file with gcc -c just like the C source code, and you will automatically get the right format. The AT&T equivalent of the trivial startup file you have in that tutorial would be
.text
.globl start
start:
call k_main
cli
hlt
Take note also that I removed the leading underscore from the call instruction's argument. That underscore is only appropriate if the C code is compiled to an a.out-format object file, which (we suspect) it isn't.

Tips/resources for structuring C code? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Does anyone have tips/resources for how to, in the best way, structure your C code projects? (Different folders etc.) And how do you know when it's good to split code into separate files? And what is an example of a good Makefile?
My project is not that big, but I wanna start to structure my code at an early stage..
Structuring code needs some experience but mostly common sense.
For splitting code, you usually go for readability: conceptually coherent functions/datatypes should go in the same file. You can take c standard library as a good example. It is better to keep your data structure definitions and function declarations in separate headers. This allows you to use the data structures as part of a compilation unit even if you have not defined all the functions.
Files that provide similar functionality should go in the same directory. It is good to avoid deep directory structure (1 level deep is best) as that complicates building the project unnecessarily.
I think Makefiles are OK for small projects, but become unwieldy for bigger ones. For really serious work (if you want to distribute your code, create an installer etc) you may want to look at cmake, scons, etc.
Have a look at the GNU coding standards: http://www.gnu.org/prep/standards/standards.html
Look at the gnu make manual for a simple example Makefile. You can also pick up any opensource project and look at the Makefile. Browsing code repositories in sourceforge.net may be useful.
Read one of the many C coding standards available on the internet and follow one that looks reasonable for your requirements. A few links:
GNU Coding Standards
C Coding Standards at IRAM (pdf)
Indian Hill C Style and Coding Standards
The following books also contain effective guidelines on writing good C code:
The C Programming Language
The Practice of Programming
The Elements of Programming Style
This is sometimes overlooked, but security is an issue in big projects. Here's some advice about how to program securely.
Here is an idiom I like:
Declare structs in a header so that their size is known by client code. Then declare init and deinit functions to the following convention:
The first parameter is a struct foo*.
The return type is a struct foo*.
If they might fail, the last parameter is either int* (simplest), enum foo_error* (if there are several ways it can fail that the calling code might care about) or GError** (if you're writing GLib-style code).
foo_init() and foo_deinit() return NULL if the first parameter is NULL. They also return the first parameter.
Why do it this way? Calling code doesn't have to allocate heap space for the structure, it can go on the stack. If you are allocating it on the heap, though, the following works nicely:
struct foo* a_foo = foo_init(malloc(sizeof(*a_foo)));
if (a_foo == NULL) {
/* Ruh-oh, allocation failure... */
}
free(foo_deinit(a_foo));
Everything works nicely even if a_foo == NULL when foo_deinit is called.

Resources