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).
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
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.
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
My professor recommended I do my senior capstone in D. What can it be used for? What makes it good? He compared it to C/C++ and said it's better. Why?
This post just makes D less attractive to work with:
Why isn't D picking up?
Compared to C and C++, it is safer, meaning that it cannot create the same sorts of segmentation faults by accessing uninitialized or disallowed memory. It also wouldn't allow misunderstanding object types like C/C++ casts can do with pointers and explicit memory allocation and deallocation. This makes the language "cleaner" feeling in some sense.
Prior to C++ standard version 2008, D also supported better delegation. Nowadays C++ is pretty close to D delegation capabilities by providing perfect forwarding.
D delegation: http://www.docwiki.net/view.php?pageid=97
C++ perfect forwarding: https://www.justsoftwaresolutions.co.uk/cplusplus/rvalue_references_and_perfect_forwarding.html
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 8 years ago.
Improve this question
This is a slightly subjective answer, but how large do you think a structure should be before you start using pointers to it in other structures or function calls rather than the structure by-value?
Depends on the compiler and architecture.
C and C++ define the size of the types they use, and how functions are written, but they don't define how they are implemented.
This is means the standard itself doesn't define how the structurs are passed, just that they are in essence copied.
The compiler might decide to do something else entirely, like not copying the struct at all if there's a default copy constructor , and the variable isn't used.
But after saying all that, most common-sense compiler implementations would store the struct in a register if it fits. So depends on the architecture, make sure the structure fits in a register.
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
A byte has 8-bits. Can it be larger in another system? Give an example.
Also, how many different types of calls such as writeint,writedec,writestring,writechar are there in assembly language.
Thanks.
Not any more. There was a time, yes, when there were systems without a fundamental 8-bit byte.
System where 1 byte != 8 bit?
how many different types of call such as writeint,writedec,writestring,writechar are there in assembly language
This question makes no sense. Assembly language is just a means of writing code that translates directly to machine instructions. call is just one of these instructions - it jumps to some other section of code, with the intent of returning to the place where the call was made.
The things you're referring to sound more like library routines - in which case there are any number of them, depending on the programming environment.