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
As far as I know, it is almost true that any code that can be represented in the LLVM intermediate language, can also be represented in C, with two important exceptions:
Exceptions. (No pun intended.)
Signed integer arithmetic with well-defined behavior on overflow.
Is there anything else that can be represented in LLVM but not in C?
In addition to exception handling, other big features are garbage collection and out-of-the-box coroutines. Going to a lower level, there are trampoline intrinsics, patch points for JITs, and direct support for Obj-C ARC Runtime intrinsics.
C is Turing complete, so all of these things can be introduced to C with libraries and so on, but I put them as they are part of the LLVM language.
Metadata for example, including LLVM's branch-weight and debugloc metadata.
Except that they can if you're willing to be tortuous enough about the C you write. I think that's general: IF you're willing to write really tortuous, unidiomatic C, THEN you can write anything. So I vote to close this as unclear.
EDIT: Most things probably are expressible in C given enough discipline, verbosity and preprocessing directives, but I wonder about aliasing.
Related
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 4 years ago.
Improve this question
Why does the C language have an enum type but not a range type as Pascal does?
In Pascal we write this: type index = 1...100; or like this:
type letter = 'a'...'z';.
The designers of the C language implemented a very simple language whose features were only those that could be (for the most part) directly translated into to one or a handful of machine-code instructions. Anything that could not be done easily by the CPU had to be provided by a function call.
This makes the compiler very easy to write and also ensures that it is easier to see where performance problems might be.
Implementing a range takes several machine code instructions. Also, if it is used as a type qualifier it means that range checking has to be added to all arithmetic operations which requires further machine code instructions.
There are a lot of other constructs that are supported by other languages that are not supported in C except through function calls (dynamic memory allocation, string manipulation, maps, etc).
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 5 years ago.
Improve this question
I am trying to learn about integer representations in c and I am having a lot of difficulty understand the fact that some operations are undefined meaning they are inconsistent among systems. I find a lot of sources claiming to teach about how these things work sometimes slip in things that are specific to the architecture they are coding for.
When I am coding I intend never to rely on undefined behaviors that happen to work a certain way on most processors.
What is the definitive truth of what happens in c (across all systems) when things like truncation, extension, comparison are done and when unsigned and signed types are included in casting and arithmetic. Which of these operations have a defined behavior across all systems?
The definitive truth is the C standard. Links to versions of it are in this answer.
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 7 years ago.
Improve this question
In an argument with a friend, I made the remark that it is impossible to write, in any language besides C, a program that is faster than all variants in C, that do the same thing. My argument was based on an affirmative answer to the question below. Is it true?
If we think of "compiling" as a map from [C programs] to [assembly programs], then is this map surjective?
Caveat: Of course, you can include assembly in C programs, but pretend that isn't possible (makes for a more interesting question!).
The answer to the question If we think of "compiling" as a map from [C programs] to [assembly programs], then is this map surjective? is obviously NO.
It can be proven trivially:
* There could be assembly language instructions that the compiler will not generate, such as int 10, halt, jmp *eax, iret, sub esp,esp...
* You might be fiddling with registers in assembly that the C compiler never touches, such as segment registers.
There is just a world of creativity in assembly that the C language cannot express.
Regarding the other question, I'm not sure what you mean by
it is impossible to write, in any language besides C, a program that is faster than all variants in C, that do the same thing.
If you mean that a skilled programmer can always write a C program that will be faster at a given task than any other program written in any language, I think you probably wrong too, because the compiler itself is a fixed variable that is imperfect.
Imagine for example that the C compiler is very dumb and generates unoptimized code. It is obvious that an assembly program can be written that will beat the best C variation at the given task: all that is needed is to optimize the unoptimized code. Since the C compiler is imperfect, you can always find a task for which even the best C variation can be further optimized.
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 7 years ago.
Improve this question
When I compile programs in Ada, I typically notice a longer compile time for code of similar length and of similar content to programs written in C or C++.
While it is true that it comes down to the compiler and system to determine compile time the Ada compilation generally takes longer. Is this process radically different than the compile/link process of C or C++. Does it consist of different stages?
What about the Ada compilation process makes the compilation take longer than ?
It is all about the amount of time and effort put into making the compiler fast.
Compilers that have a broader scope tend to have more money to invest in making fast; however, sometimes there are other elements at stake. For example, the details of a compiler might include static type checking, various "extra" correctness checks, and other items (programming contract compliance, code quality, etc) that might adjust the compile time.
Ada tends to have had less money thrown at its compiler, and it is likely a slightly more complex language to parse than C. Both of these factors lend themselves to making it likely that its compiler will be slower.
Note that speed of compilation has little to do with the "quality" of the language. While C might have a larger footprint, Ada has made its mark on the programming world in other ways.
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 8 years ago.
Improve this question
What are the key differences between Ruby and C?
They are almost totally different.
Ruby
Strong, dynamic typing
Purely object oriented
Automatic garbage collection and no pointers
Interpreted (or JIT compilation with JRuby/IronRuby)
Reflective
Supports functional programming (closures, coroutines, etc.)
No preprocessor or macros
C
Weak, static typing
Procedural (not object oriented)
Not garbage collected and has pointers
Compiled
No reflection
Does not support functional programming
Has a preprocessor and supports macros
To Ruby From C and C++
Why do you ask? Do you have a specific project or goals in mind?
In addition to what others have already mentioned; I'd also say that some key differences to keep in mind is that the C family is much more portable....or rather, much easier to distribute the finished software. C programs will also be much faster than Ruby...whether that is important or not depends on what you are building (well, that's ALWAYS important, but it isn't a make or break proposition for a lot of programs).
Ruby is just simply a beautiful language to work with (do not underestimate the importance of a language that works with you); developing programs is much quicker in Ruby than C ( C is a compiled language, so that is to be expected )...Ruby is also a pretty simple language to learn; most people consider C to be fairly tough for newbies to pick up.
-- edit --
wow, just saw this was a 3 year old thread....my bad