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
There are a lot of answers and quotations about "Compiled vs. Interpreted" and I do understand the differences between them.
When it comes to C, I am not sure: Is C a compiled or an Interpreted language, or both? And, if both I will really thankful if you add a bit of explanation.
A programming language is simply a textual representation of abstract principles. It is not compiled or interpreted - it is just text.
A compiler will take the language and translate it into machine language (assembly code), which can easily be translated into machine instructions (most systems use a binary encoding, but there are some "fuzzy" systems as well).
An interpreter will take the language and translate it into some byte-code interpretation that can be easily translated into a binary encoding on supported platforms.
The difference between the two is when that change occurs. A compiler typically will convert the text to machine language and package it into a binary file before the user runs the program (e.g. when the programmer is compiling it). An interpreter will typically do that conversion when the user is running the program. There are trade-offs for both approaches.
The whole point here is that the language itself is not compiled nor interpreted; it is just a textual standard. The implementation details of turning that text into machine instructions is where the compilation or interpretation choice is made.
It's typically compiled, although there is of course nothing preventing people from implementing interpreters.
It's generally wrong to classify languages as either/or; what is the language going to do? It's just a spec on paper, it can't prevent people from implementing it as either a compiler or an interpreter, or some combination/hybrid approach.
There are languages which are designed to make compilation easy, by giving the user only features that directly map to machine instructions, such as arithmetic, pointer manipulation, function calls (and indirect function calls which give you virtual dispatch). Interpretation of these is generally also easy, but particularly poor performance. C is one of these.
Other languages are designed for interpretation. These often have dynamic typing, lazy dispatch, dynamic (not lexical) scope of closures, reflection, dynamic codegen, and other features that make compilation incredibly difficult. Of course difficult is not the same as impossible, and some of these languages do end up with compilers as a result of Herculean efforts.
Related
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 3 years ago.
Improve this question
I know very little about what makes a language "fast", but it stands to reason for me that a language designed for extreme minimalism would also be extremely fast, right?
C is far closer to English than BrainFuck, and the compiler size for BrainFuck is remarkably small at 1024 bytes, almost nothing compared to the Tiny C Compiler, which is sized at around 100 KB.
However, all the websites online treat C as the fastest language bar bytecode or assembly.
(Clarity edit to take question off hold)
If I made the same program in C and BrainFuck (which, for example, calculated the first 100 numbers of the fibonacci sequence) , which one will complete the task faster at runtime? Which one would compile faster?
Yes and no. There are language features that will make a language slower (in some cases garbage collection, dynamic types only known at runtime, …) and others that will make it more complex but allow the compiler more freedom.
Case in point: the constexpr keyword of C++ is somewhat complex to implement, but allows the programmer to tell the compiler "This function application has to be replaceable by its result". In extreme cases, this allows the compiler to replace costly function calls (e.g. a fast fourier transform) with a constant result without any runtime cost.
Compiled C code is very fast, because it has almost no features that don't map down directly to assembler and it has almost half a century of compiler optimizations.
It depends on the ability of the compiler.
A compiler converts a source file into an executable. There are four phases (for a C) program to become an executable:
Pre-processing
Compilation
Assembly
Linking
An abstract syntax tree (AST) is usually created. The AST is often used to generate an intermediate representation (IR), sometimes called an intermediate language, for the code generation.
This intermediate language is actually compiled to machine code and it does not matter, from which high level language (in this sense brainfuck a high level language) you got this from.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I have a collection of files written in a language 'A' that need to be translated into corresponding files of a language 'B'.
I want to create a program/parser that can automate this task (probably rather a toolchain than a single program). However,
I am struggling to find a suitable choice for the programs of my toolchain.
Language A is embedded software code, i.e. low-level language. It is 90% standard C-Code and 10% "custom" Code, i.e.
the files also contain small segments that cannot be understood by a standard C compiler. The 90% C-Code is not any random C-construct that is possible in C (this would be hard to parse concerning semantics), but follows certain recurring expressions, actions and patterns. And it always follows these patterns in the (more or less) same way. It does mostly perform write operations to the memory, and does not include complex structures such as C-struct or enum etc..
Example of regular low-level C-Code in language A:
#define MYMACRO 0x123
uint32_t regAddr;
regAddr = MYMACRO;
*(uint32_t*)(regAddr) = 0xdeadbeef;
Example for "custom code" in language A:
custom_printf("hello world! Cpu number: %d \n", cpu_nr);
Language B is a 100% custom language. This transformation is necessary, in order to work with the file in another tool for debugging purposes. Translation of the example above would look roughly like this:
definemacro MYMACRO 0x123
define_local_int regAddr
localint.set regAddr = MYMACRO
data.write regAddr 0xdeadbeef
Note: I am well aware that Stackoverflow is not meant to be a site for open discussions about "which tool do you prefer?". But I think this question
is rather one like "I need at least ONE meaningful toolset that gets the job done", i.e. there are probably not so many sensible options for discussion anyway.
These were my considerations and approaches so far:
Performance is NOT relevant for my toolchain. It only should be easy to implement and adapt to changes.
First approach: As language A is mostly C-Code, I first thought of the pycparser Python Plugin, which provides a C-parser that parses C-Code
into an AST (Abstract Syntax Tree). My plan was to read in the language-A files, and then write a Python program that creates
language-B files out of the AST. However, I found it difficult to adapt/teach the pycparser plugin in order to fully support the 10% custom properties of language A.
Second approach: Using 'general-purpose parser generators' such as Yacc/Bison or ANTLR. Here however, I am
not sure which of the tools suits my needs (Yacc/Bison with LALR parser or ANTLR with LL parser) and how to set up an appropriate
toolchain that includes such a parser and then processes (e.g. with Python) the data structure that the generated parser creates in order to create the custom language B. It would also be helpful if the parser generator of choice provides an existing C-language definition that can easily adapted for the 10% custom C-language part.
I should also mention that I have never worked with general-purpose parsers before.
Could anybody please give me some advice about a meaningful set of tools for this task?
Edit:
I apologize if this seems as a vague question, I tried to put it as precisely as I could.
I added an example for languages A and B to make the composition of the languages more clear, and in order to show that language A follows certain recurring patterns that can be easily understood concerning semantics.
If this edit does not improve the clarity and broadness, I will repost on programmers as was suggested.
Edit2:
Alright, as the topic clearly still seems to be deplaced here, I herewith withdraw the question. I already received some valuable input from the first few posters, which enouraged me to make further experiments with the general purpose parser generators.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
People always say that C is more efficient than any other high level language.I don't understand why. I know assembly is efficient because it has a close relation to machine language .
But C and C++ or ruby,lets say,they are all going to be 'translated' into machine language,right? By more efficient,does it mean the machine code is better,or it takes less time to be 'translated' into machine code? What if there is some compiler or interpreter that can produce faster,also result in better machine code?
I know assembly is efficient because it has a close relation to machine language.
No, it does not. it has a 1.1 relation - it is a written representation of exact machine code commands. It is a mnemonic language - basically replacing byte codes with another representation. All higher langauges miss that.
But c and c++ or ruby,let say,they are all gonna be 'translated' into machine
language,right?
Yes, but the question is when and how efficient. low level languages - and C is one - allow less advanced constructs and are thus closer to assembler and easier for the compiler to optimize.
By more efficient,does it mean the machine code is better,or it takes less time to be
'translated' into machine code?
Outside of just in time compiled languages or interpreters NOONE cares about how much time it takes to translate. C is statically translated, once, then executed.
What if there is some compiler or interpreter that can produce faster,with better machine
code?
Then the statement is not true. Funny enough, that is not really the case - it is not that easy to make a super efficient compiler for higher languages. Basically you keep asking why a super sports car is so fast & state it would not be considered to so fast anymore when every Fiat Panda would have more horsepower - but sadly they don't have and never will have.
There are a lot of different issues at play here, so a full answer would be very long.
Some high-level languages are higher-level than others. C is not very high-level.
Different languages make different trade-offs. Some languages focus on ease of development, programmer productivity, preventing common errors, automation etc.
Others focus on speed/efficiency. C is one of the latter, partly due to its age and history.
Given the same level of effort, a C program is not necessarily faster than the equivalent in another languages, especially on modern multi-core systems. However, C exposes more possibilities for low-level optimisations, if you have the time to write them. The downside is that these optimisations are error-prone, and getting them wrong normally crashes your program completely.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
In programming language discussions we hear terms such as low-level, middle-level, and high-level. How are these determined? Would C be considered a middle-level language?
Low-, high-, blah-level is all just vague terminology with no deterministic factor behind it. Traditionally, low-level languages refer to machine code and assembly, and high-level refers to everything else. More recently, we have "very high level" used for scripting languages (anything interpreted rather than compiled). I have never heard "middle" used for anything.
That said, you will hear lots of argument on whether C or C++ are low-level or high-level languages, as some people prefer to think of C/C++ as low-level now given their relative position to other languages (25 years ago this would be unheard of). It is largely meaningless unless you agree on a definition of low-level or high-level. So you could easily come up with a definition of "middle-level" and then use that to determine whether C counts as middle-level or not.
I found this to be the reason for such a bias between high level and low level classification.
C is often called a middle-level
computer language as it is a
combination of the elements of
high-level languages with the
functionalism of assembly language.
High Level language :
A high-level programming language is
one that's more user-friendly, to some
extent platform-independent, and
abstract from low-level computer
processor operations such as memory
accesses.
Low Level Language :
A low-level programming language is a
one that is more machine specific, and
from computer processor operations
such as memory accesses is directly
dependent.
courtesy : http://www.cfanatic.com/showthread.php?s=cfa39a622e72217cce1fb9118a90fd79&t=130
If you look at it from a function point perspective, it would be middle to low level.
http://www.qsm.com/resources/function-point-languages-table/index.html
Though the terminology is quite vague, I consider C to be a mid-to-low-level language. You have very low-level features (manual memory access, pointer arithmetics) and very few abstractions - It's almost literally converted to assembly. As Wikipedia states C++ is a typical mid-level language, since you have the low-level access of C combined with abstractions like object orientation, templates and even some functional programming.
Middle-level language is used because you can go really low, doing assembly, but it also contains elements or abstractions of higher-level languages
but i agree with danben..there's no deterministic factor behind it...
My old C books from before C++ was around talk about C as a middle-level language. But that was before Java, .NET, Ruby, Python, etc were around. I'd say the (vague) boundaries have shifted somewhat as the high-level languages like Ruby/Python became so much more advanced.
C is only one step above Assembly, but above C you have C++, then Java/.net, then Ruby/Python. So I'd say C is now a lower or lower-mid level language since you can quite easily map it to asm/machine code. I'd say C++ is a mid-level language, Java/C# mid-high, Ruby/Python high.
C is often called portable assembly by people who can program in assembly. Now, ask the same group of people if C is too much or too little abstraction away from assembly and you'll see rotten fruit start to fly (well, perhaps good fruit too, depending on what's available).
The 'level' to which you refer is simply the amount of abstraction between you and a compiled heap of ones and zeros. Some may say math is nicely abstracted in C while strings are just wretched to deal with.
In essence, it really depends on what you are using C to do. I don't feel that it can be classified as a whole.
I think C should still be classed as a high level language. Compared to assembly it really is high level.
It has loops for one which makes a huge difference rather than trying to roll your own with jump statements.
Try writing assembly on an 8 bit microcontroller and then jump to using C. You'll soon realise just how far apart they are.
Edit: Since when has there been such a thing as a mid level language anyway? Mid level compared to what?
From the usage point of view, in contrast to C++, C provides less language syntax, semantics and facilities. C is a lower level language than C++.
while from function point of view, if a language can provide powerful functions under the help of remarkable infrastructure, such as Windows SDK C API, I think it really can be called a "high level" language.
Scripting languages provide another usage of programming language: interpreted rather than compiled. While its function is somewhat limited.
therefore, you need it, you use it. the better achieved, the higher level you enjoyed!
C is a high-level language in the sense that there's very little one-to-one correspondence between a line of C code and the equivalent machine code. Compared to languages like C++ or Java, C provides very few abstractions; beyond byte streams, arrays, and pointers (which, yes, are abstractions), there isn't a whole lot in the C toolkit.
It seems like languages are divided by generation.
These generations are widely considered to be (with the definitions having greater variance the higher you get):
Machine Languages.
Assembly languages (which is just a human readable version of Machine Languages)
Structured languages (FORTRAN, COBOL, C, C++, C#, Java, Python, etc...)
Languages used to build applications in a specific area (PL/SQL, R, FoxPro, etc...)
Languages that work within specific constraints rather than algorithms. These are usually used in AI. (Prolog, etc...)
Having said all that, the fourth generation is sometimes said to include object-oriented languages.
I'll answer with another question: is C++ a high-level language?
It isn't: The language itself gives you classes, operator overloading, and templates. That's just syntactic sugar around structs, functions, and macros. As an example, Lightblue BREW is a zero-overhead bridge between BREW (object-oriented C) and C++ because BREW happens to be binary-compatible with C++!
Cfront was the original "compiler" for C++: it preprocessed it into C. The original compilers for Objective-C was also just preprocessors.
It is: You can write code which uses "high-level" features (memory management, garbage collection, lambda expressions, ...) without worrying about "low level" details (forgetting to free). There are plenty of C++ libraries out there (e.g. Boost).
It's far more useful to classify a language by the features it has instead of giving it a high-level-ness number. Take, for example, unpacking a .bmp ("DIB") header:
C: Easy. Just use a struct. You might have to worry about endianness, packing, and portability to odd architectures.
C++: Use a struct. If you're clever, the structs can also handle endianness and packing in a mostly portable way.
Java: You have to calculate offsets into the header. If it's a byte array, you have to do masking and bitshifting yourself. (If it's a nio buffer, you just set the endianness.)
REALbasic: It's a MemoryBlock. You have to calculate offsets into the header yourself. You might have to worry about endianness, depending on whether you use a MemoryBlock extension plugin.
Python: Just import struct. None of the fields have names though, so you have to keep track of what order they're in, so it's marginally bette than calculating offsets.
There, an easy problem where C++ seems to be the highest-level language and C comes second.
I'll also note that the existence of "low level" features does not make a language low-level. In C#, you can write "unmanaged" code and use pointer arithmetic. In Python, you can import ctypes to call C or C++ functions and import objc to call Objective-C, losing all type-safety (I do this when I'd otherwise write a quick test program, because it's much easier than repeated compiling and running).
Besides, pointer arithmetic need not be low-level. Pointers are usually implemented as memory addresses, and C++ references are usually implemented as pointers, but there's no reason why you can't change the underlying implementation to make pointers bounds-checked, or even type-checked.
I think it is up to the user how he is using it.A high level language is that which provide abstraction and low level language is that which uses resources provided by OS(System call).In that way if a programmer is using system call to perform some task then c is a low level programming language,and if the same programmer use bash commands or other function which give view of programming then c is a high level language.So C is both high and low level programming language .
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Coming from a OO background (C#/java) I'm looking for resources to learn how to design pure C programs well.
Whilst i'm familiar with the syntax of C, and i can write small programs, i'm unsure of the approach to take for larger applications, and what techniques to employ. Anything you guys can recommend.
EDIT: I'm happy to completly abandon OO for the purposes of programming in C, my interest is in learning how to structure a program without OO, I want to learn about good ways of designing programs in procedural languages such as C.
This posting has a list of UNIX books which includes most of the classic C/Unix works. For C programming on Windows, Petzold's Programming Windows is probably the best start.
For C program design, some of the UNIX programming books will tell you snippets but I'm not aware of a 'C program architecture' book.
If you're used to java, some tips for C programming are:
Make use of stack. Often when you call a procedure you will want to have variables allocated in the caller's stack frame and pass pointers to them into the procedure you want to call. This will be substantially faster than dynamically allocating memory with malloc() and much less error-prone. Do this wherever appropriate.
C doesn't do garbage collection, so dynamically allocating data items is more fiddly and you have to keep track of them to make sure they get freed. Variables allocated on the stack (see 1) are more 'idiomatic' where they are applicable. Plus, you don't have to free them - this is a bonus for local variables.
Apropos of (2), consider an architecture where your functions return a status or error code and pass data in and out using the stack as per (1).
Get to know what setjmp() and longjmp() do. They can be quite useful for generic error handler mechanisms in lieu of structured exception handling functionality.
C does not support exceptions. See (3).
Lint is your friend. Splint is even friendlier.
Learn what the preprocessor does and what you shouldn't do with it even if you can.
Learn the ins and outs of endian-ness, word alignment, pointer arithmetic and other low-level architectural arcana. Contrary to popular opinion these are not rocket science. If you're feeling keen, try dabbling in assembly language and get a working knowledge of that. It will do much for your understanding of what's going on in your C program.
C has no concept of module scope, so plan your use of includes, prototype declarations, and use of extern and static to make private scopes and import identifiers.
GUI programming in C is tedious on all platforms.
Apropos of (10) learn the C API of at least one scripting language such as Tcl, Lua or Python. In many cases, the best use of C is as a core high-performance engine on an application that is substantially written in something else.
The equivalent of a constructor is an initializing function where you pass in a pointer to the item you want set up. Often you can see this in the form of a call to the function that looks like setup_foo(&my_foo). It's better to separate allocation from initialising, as you can use this function to initialise an item you have allocated on the stack. A similar principle applies to destructors.
Most people find Hungarian notation about as readable as written Hungarian. The exception to this is native Hungarian speakers, who typically find Hungarian notation about as legible as Cuneiform.. Unfortunately, Hungarian notation is widely encountered in Windows software and the entire Win32 API uses it, with the expected effects on the legibility of software written on this platform.
C/Unix books, even really good ones like the ones written by the late W Richard Stevens tend to be available secondhand quite cheaply through Amazon marketplace. In no particular order, get a copy of K&R, Stevens APUE and UNP 1 & 2, the Dragon book, Rochkind, Programming Pearls, Petzold and Richter (if working on Windows) and any of the other classic C/Unix works. Read, scribble on them with a pencil and generally interact with the books.
There are many, many good C/Unix programming resources on the web.
Read and understand the Ten Commandments of C Programming and some of the meta-discussion as to the why's and wherefores behind the commandments. This is showing its age to a certain extent, although most of it is still relevant and obscure compilers are still quite common in the embedded systems world.
Lex and Yacc are your friend if you want to write parsers.
As Navicore points out below (+1), Hanson's 'C Interfaces and Implementations' is a run-down on interface/implementation design for modular architecture with a bunch of examples. I have actually heard of this book and heard good things about it, although I can't claim to have read it. Aside from the C idioms that I've described above, this concept is arguably the core of good procedural design. In fact, other procedural languages such as Modula-2 actually make this concept explicit in their design. This might be the closest thing to a 'C Program Architecture' book in print.
Read the C FAQ.
My concerns going from OO back to C were addressed in David Hanson's "C Interfaces and Implementations".
C Interfaces and Implementations
Seriously, its approach made a huge difference in avoiding accidentally building the large ball of yarn that many non-oo systems wind up as.
Here's some interesting responses from a different question regarding OO programming in C. I made a post about some C code I worked with which basically impelmented object orientation stopping just short by not including virtual methods.
If I were doing C coding, I would use this technique to define 'objects'.
I find keeping Design Patterns in mind is always helpful, and can be implemented in most languages.
Here's a nice PDF discussing object oriented C programming.
While it is written as a somewhat language-agnostic text, Code Complete provides a lot of good guidance on code structure and organization, along with construction practices.