C Specification Ideas
-
Not at all. What I am suggesting is that the index origin should be a variable setting, not a code-wide compiler setting. When writing code, the programmer should be allowed to specify the index origin on a variable. The example I gave used an index origin of 2 for a list of primes. FWIW, Pascal is a language which is looked down upon by C++ (C?) programmers as an inferior language but it has this feature. ...Actually Pascal requires you to specify the origin, even if it is zero (which pushes it too far for me). And yeah, VB sucks.
-- Harvey
-
"What's the point in restricting your own code? " Encapsulation. You aren't aware of it, but you're quite an ignorant person. "Some people defend it by saying it serves as a reminder to the developers" These people are also ignorant and clueless. "Most of my smaller projects are straight-up procedural, but my larger projects" Ah, perhaps you've never done real software development, which involves more than one person and more than one business entity. Access modifiers allow you to change the internals of your classes without the risk of breaking user code over which you have no control.
Encapsulation. You aren't aware of it, but you're quite an ignorant person. There isn't even a clear definition for what encapsulation is. To encapsulate is just to contain, there's no definition of it which dictates which privileges those encapsulated classes may have. Hell,
struct {
struct {
float x;
} sub;
} main;can be considered encapsulation. Ah, perhaps you've never done real software development, which involves more than one person and more than one business entity. Access modifiers allow you to change the internals of your classes without the risk of breaking user code over which you have no control. ...in exchange for breaking the entire project when the privileges of a member need to be changed, and thus requiring every member of your team to obtain a clean build of the project. btw, I'd appreciate it if we acted like adults and refrained from called each other stupid.
-
Some of your ideas are sensible, but not this one ... it's stupid to say that typedef short int16_t is stupid. stdint.h in a conforming implementation is always right; if short isn't 16 bits then int16_t won't be defined as short. Requiring that all these types be language keywords is a very bad idea. The C standards committee sensibly said that including stdint.h is required so that they wouldn't force bloat on every C implementation. An implementation is free to have the compiler to use its own internal knowledge to define the symbols whenever it see "#include " in the source, but requiring that compilers generate these symbols itself is clueless.
but some compilers can target multiple architectures at once, meaning the size of those can change. GCC itself includes identifiers like _IntN_Type_ as well, so it's not like it's like it's an abstract idea. I just think there should be a clearer declaration of types rather then having a header define them based on ones which are not always the same. I'm not gonna debate this one much though, because it's not really a pressing issue unless you're working with older toolchains. Would just be a perk.
-
Blocks in Expressions
int numPotatoes = ({ int i; for (i = 0; i < 5; i++); i});
The above would set 'numPotatoes' to 5, because you're executing a block of instructions and returning the result of the last instruction as an expression. On a sidenote, what do you mean by "necessity of a cast" in that context? In 20+ years of C/C++ programming I've never seen a single case of a cast that was actually necessary, except when working with a badly designed library API (such as MFC). Convenient, maybe - but never necessary. If you've never seen a case where a cast was necessary in C, then there's no way in hell you've been a C programmer for 20+ years. The over-necessity for type casting is one of the most notorious problems in C, and always has been. Primary example, logical shifting.
int32_t i = -2;
i >>= 1;
if (i == 0x7FFFFFFF) {
printf("did a logical shift\n");
} else if (i == -1) {
printf("did an arithmetic shift\n");
}the above would do an arithmetic shift. to do a logical shift, it's required that you cast 'i' to an unsigned integer. EDIT: More examples if you need them.
int (*myfn1)();
int myfn2();
int *myfn3;char *str1;
const char *str2 = "derp";int i, *j;
unsigned int k;str1 = str2; // throws warning for discard of const qualifier
myfn1 = myfn2; // } throws warning on some compilers and older
myfn1 = myfn3; // } versions of the GCC
i = j; // throws warning for integer from pointer without cast
j = i; // throws warning for pointer from integer without cast
if (i == j); // throws warning for comparison between pointer and integer
if (i == k); // throws warning for signed/unsigned mismatch
i >>= 1; // always an arithmetic shift, even if you need logical
int l[] = { NULL; } // throws 2 warnings; integer from pointer without case
// near initialization for l[0]
uint64_t m = i << 32; // throws warning, left shift count >= width of typetry building your project with -Werror and this is a recipe for disaster.
All of these are cases of bad programming, or simply errors that shouldn't compile! In short, you are trying to compare or assign variables of different types. This should never work, and never actually be done, unless there is a meaningful and well-defined conversion between these types! One of the main features that distinguishes C from many other procedural languages, is type-safety. By using type casts you are undermining that feature. Read up on wikipedia, why type safety[^] is so important!
-
before my reply, just wanted to state I saw you using the term 'C/C++'. my ideas were for C in particular. Embedded Functions
void MyFn() {
void MyEmbeddedFn() {
}
}Simpler Lambda I'm pretty sure I supplied an example of a simpler usage, something like
int (*)(int arg) {
return arg + 1;
}(5);Something like this wouldn't be hard to implement either. Typedef Initialization I kinda agree here. To be honest, I was mostly thinking of artificial classes through structs when I tossed this idea on the table. There's no real clean way of doing it, but it would be useful. Pointer Declaration It's particularly useful for namespacing. If you could declare pointers, you could initialize structures such that all members could be accessed via '->', which lessens confusion. For example, in my game engine I use structs to define namespaces so I do stuff like
int main(int argc, char *argv[]) {
if (!Engine->Init()) return 0;
while (Engine->IsRunning()) {
if (!Engine->IsPaused()) {
Scene->Current->Update();
}
}
Engine->Term();
return 0;
}since you can't declare pointers, I usually end up having an unused variable. like
struct {} _Engine, *Engine = &_Engine;
it's not a dire issue, but it would be really nice to be able to optionally cut out the middle-man.
Embedded Functions: Ok, that's what I know as "local functions". I know Pascal supports these, and never understood why C doesn't. Would be useful. Pointer Declaration: That only makes sense in case of a singleton or global variable. (If you can have more than one instance of a structure, you must be clear which one the pointer points to) Since either should be used sparingly, I would assume there should only be few applicable cases in any program. In any case, if such a feature were added, it should imply that the instance that pointer points to is unique, and no other copies of that object may exist. I'm not sure that such an implication makes sense in C; but it might in C++.
-
"What's the point in restricting your own code? " Encapsulation. You aren't aware of it, but you're quite an ignorant person. "Some people defend it by saying it serves as a reminder to the developers" These people are also ignorant and clueless. "Most of my smaller projects are straight-up procedural, but my larger projects" Ah, perhaps you've never done real software development, which involves more than one person and more than one business entity. Access modifiers allow you to change the internals of your classes without the risk of breaking user code over which you have no control.
I think he's a Macaulay Culkin coder - code alone. In a very small, one man project do whatever you want. The rest of us are in the real world.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
None of those features would turn C into a higher-level language, they're just simple syntax changes to make things which are already possible to do in C easier to do. Not trying to be rude, but I hate when people say C++ is a viable replacement for C. It's not. It's slow, clunky, overrated, understandardized, unstable, hideous, and there are many devices where it cannot be used because the target device does not have a C++ runtime.
Ghosuwa Wogomon wrote:
It's slow, clunky, overrated, understandardized, unstable, hideous
You can write slow, clunky, unstable, hideous code in any language. An experienced programmer will do neither. In any language. understandardized: if anything, there are now more standards in effect for C++ than there are for C. overrated: This is a meta-argument dependent on the correctness of your other statements. No point discussing it.
Ghosuwa Wogomon wrote:
and there are many devices where it cannot be used because the target device does not have a C++ runtime.
You may be mixing this up with the .NET runtime library. but that's C# (and AFAIK also "Managed C++", but I'm not sure). This is however not true for native C++. Once you compile and link a (native) C++ program it is no different from a C program.
-
All of these are cases of bad programming, or simply errors that shouldn't compile! In short, you are trying to compare or assign variables of different types. This should never work, and never actually be done, unless there is a meaningful and well-defined conversion between these types! One of the main features that distinguishes C from many other procedural languages, is type-safety. By using type casts you are undermining that feature. Read up on wikipedia, why type safety[^] is so important!
This should never work, and never actually be done, unless there is a meaningful and well-defined conversion between these types! THAT'S WHAT CASTING DOES. No matter how skilled you are, there will always be a case in which you need to perform a type cast. For example, when working with memory-mapped hardware:
volatile unsigned int *frameBuffer = (unsigned int *)0x80100000;
There's no workaround or way to avoid this. The framebuffer is at 0x80100000. That's an integer, the frameBuffer is a pointer. You need to cast! This is just one of the most ridiculous arguments I've every heard :omg:
-
Ghosuwa Wogomon wrote:
It's slow, clunky, overrated, understandardized, unstable, hideous
You can write slow, clunky, unstable, hideous code in any language. An experienced programmer will do neither. In any language. understandardized: if anything, there are now more standards in effect for C++ than there are for C. overrated: This is a meta-argument dependent on the correctness of your other statements. No point discussing it.
Ghosuwa Wogomon wrote:
and there are many devices where it cannot be used because the target device does not have a C++ runtime.
You may be mixing this up with the .NET runtime library. but that's C# (and AFAIK also "Managed C++", but I'm not sure). This is however not true for native C++. Once you compile and link a (native) C++ program it is no different from a C program.
You can write slow, clunky, unstable, hideous code in any language. An experienced programmer will do neither. In any language. This is definately true, but C++ takes the cake for it's horrid grammar. understandardized: if anything, there are now more standards in effect for C++ than there are for C. In concept. No C++ compiler actually meets the standard, which is what I was referring to. You may be mixing this up with the .NET runtime library. but that's C# (and AFAIK also "Managed C++", but I'm not sure). This is however not true for native C++. Once you compile and link a (native) C++ program it is no different from a C program. Writing C code in a .cpp file does not count as C++. C++ depends on non-portable libraries such as malloc, and produces inflated code which cannot be use on some devices due to memory restrictions. Primary example of a popular platform C++ could not be used on is the N64. It didn't have a C++ runtime, so all the games were written in C, as are all developer examples. People will argue to their blue in the face over this, but I've personally seen where it can't be used so I disagree.
-
This should never work, and never actually be done, unless there is a meaningful and well-defined conversion between these types! THAT'S WHAT CASTING DOES. No matter how skilled you are, there will always be a case in which you need to perform a type cast. For example, when working with memory-mapped hardware:
volatile unsigned int *frameBuffer = (unsigned int *)0x80100000;
There's no workaround or way to avoid this. The framebuffer is at 0x80100000. That's an integer, the frameBuffer is a pointer. You need to cast! This is just one of the most ridiculous arguments I've every heard :omg:
Ghosuwa Wogomon wrote:
unless there is a meaningful and well-defined conversion between these types!
THAT'S WHAT CASTING DOES.Umm, no. Casting does not automatically infer meaning or well-definition. Not in most cases I've seen in code. There are very few exceptions - see below.
Ghosuwa Wogomon wrote:
volatile unsigned int *frameBuffer = (unsigned int *)0x80100000;
Yes I agree. This is the one case where a type cast is required and meaningful: if the source you get a variable or value from does not provide the (correct) type information, then you must provide it. You typically get this whenever you interface hardware as in the above case. It may also happen when interacting with a badly designed library API. In the latter case, the correct solution would be to fix the API so it doesn't require casting. But of course, if it is not your library, then this is not an option. Even if it is your library, it may not be practical: by changing the API you may be breaking other applications that use the library. When I said above casting is never "really" needed, the word "really" implied "in theory" with regard to the latter case. And I did not consider low level hardware programming.
-
You can write slow, clunky, unstable, hideous code in any language. An experienced programmer will do neither. In any language. This is definately true, but C++ takes the cake for it's horrid grammar. understandardized: if anything, there are now more standards in effect for C++ than there are for C. In concept. No C++ compiler actually meets the standard, which is what I was referring to. You may be mixing this up with the .NET runtime library. but that's C# (and AFAIK also "Managed C++", but I'm not sure). This is however not true for native C++. Once you compile and link a (native) C++ program it is no different from a C program. Writing C code in a .cpp file does not count as C++. C++ depends on non-portable libraries such as malloc, and produces inflated code which cannot be use on some devices due to memory restrictions. Primary example of a popular platform C++ could not be used on is the N64. It didn't have a C++ runtime, so all the games were written in C, as are all developer examples. People will argue to their blue in the face over this, but I've personally seen where it can't be used so I disagree.
Ghosuwa Wogomon wrote:
C++ depends on non-portable libraries such as malloc
malloc is used in C as well. If you mean new/delete, the release version of these functions are not much different. Now, the DEBUG versions may be an entirely different matter.
Ghosuwa Wogomon wrote:
Primary example of a popular platform C++ could not be used on is the N64.
From the site What is SN64? - Nintendo 64 Tech[^]:
Quote:
Our compiler is the popular and highly-rated GNU 'gcc' compiler, providing C and C++ compilation with an incredible array of optimizations. The compiler output is then processed by our blazing custom C-assembler,
Considering the fact the N64 was released 1996, and the first widely available C++ compilers were released only around 1990 (with rather poor or non-existant support of advanced features like templates), it is more than understandable that developers stuck to C instead in this case and at that time! But, the alternative C++ was available. Just to be clear: if you write a program for the same purpose in C or in C++, the latter will most likely be larger, and you are right to consider this a disadvantage. But if the program grows over a certain size, or you keep adding features over the course of several years, you're much better off with the C++ program. It all depends on the kind and size of programs you write.
-
Encapsulation. You aren't aware of it, but you're quite an ignorant person. There isn't even a clear definition for what encapsulation is. To encapsulate is just to contain, there's no definition of it which dictates which privileges those encapsulated classes may have. Hell,
struct {
struct {
float x;
} sub;
} main;can be considered encapsulation. Ah, perhaps you've never done real software development, which involves more than one person and more than one business entity. Access modifiers allow you to change the internals of your classes without the risk of breaking user code over which you have no control. ...in exchange for breaking the entire project when the privileges of a member need to be changed, and thus requiring every member of your team to obtain a clean build of the project. btw, I'd appreciate it if we acted like adults and refrained from called each other stupid.
FYI: http://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29[^] You are both right ;)
-
As someone who's preferred programming language is C and works with it every day, I wanted to share some ideas for things I believe should be standardized or added to the specification. Obviously, my word means nothing and I don't expect any of my suggestions to be taken into consideration, but this I'd love some feedback. Firstly, just wanna say that out of these ideas, there's no requests for new keywords or operators. C is C, and trying to glue other language features to it isn't just in my opinion. These ideas are meant to be subtle alterations to the rules to make life easier for developers that shouldn't change the behavior of existing software. Blocks in Expressions This is already being done by GCC, and it's very useful. Unify Function Types The function 'void main()' should be of type 'void (*)()', and there should be no necessity for a cast. Embedded Functions This is already being done by GCC and is useful in preventing function name duplication or creating private functions that need to be used multiple times, but don't need to be globally visible. Simpler Lambda I think it would be pretty sweet to be able to declare lambda functions like
int i = int (*)(int a, int b) { return a + b; }(2, 3);
I also think you should be able to declare them like this outside of functions as long as it's not executed. Struct Declaration It's annoying sometimes having to type out all the fields of a struct twice. Would love to be able to just do
struct mystruct {
int i = 5;
};or
typedef struct {
int i = 5;
} mystruct;which leads me to... Typedef Initialization If 'eyes' should always be 2 by default, wouldn't it be nice to just do
typedef int eyes = 2;
and then all instances of eyes would be 2 by default? This is a poor example, but supposing you had a 20+ member struct, it'd be nice not having to memcpy every time you create a new one. Pointer Declaration This is something I'd really love to have. Instead of having to do
int _i = 5, *i = &_i;
it would be nice to be able to do something like
int *i = (int (*))5;
or getting a pointer to a constant with & operator. Default Integer Declarations I think the compiler should have built-in declarations for _Int8, _Int16, _Int32_, _Int64, _Half, _Single, and _Double. Okay, I said
I have always wished the standards committee would entertain this format of an 'if' statement:
if ( 0 <= x <= 99 )
where the two comparison operators can only be 'less than' or 'less than or equal to'. This reads as "if x is in the range 0 to 99 inclusive".
-
Encapsulation. You aren't aware of it, but you're quite an ignorant person. There isn't even a clear definition for what encapsulation is. To encapsulate is just to contain, there's no definition of it which dictates which privileges those encapsulated classes may have. Hell,
struct {
struct {
float x;
} sub;
} main;can be considered encapsulation. Ah, perhaps you've never done real software development, which involves more than one person and more than one business entity. Access modifiers allow you to change the internals of your classes without the risk of breaking user code over which you have no control. ...in exchange for breaking the entire project when the privileges of a member need to be changed, and thus requiring every member of your team to obtain a clean build of the project. btw, I'd appreciate it if we acted like adults and refrained from called each other stupid.
Encapsulation. You aren't aware of it, but you're quite an ignorant person. There isn't even a clear definition for what encapsulation is. Like I said, you're quite an ignorant person ... the concept of encapsulation is well understood in CS. ...in exchange for breaking the entire project when the privileges of a member need to be changed, and thus requiring every member of your team to obtain a clean build of the project. This is nonsense ... changing unencapsulated internals is far more likely to have wide-ranging impacts. And changing access modifiers does not require everyone to do a clean build, even in C++. And such a requirement is a minor effect at worst. I'd appreciate it if we acted like adults This sort of plea is quite immature ... as is your entire silly response and your original silly comment ... the entire professional programming community uses access modifiers, for very good reasons. and refrained from called each other stupid I didn't call anyone stupid; you have misread or misinterpreted. I did call you ignorant, and I stand by that.
-
but some compilers can target multiple architectures at once, meaning the size of those can change. GCC itself includes identifiers like _IntN_Type_ as well, so it's not like it's like it's an abstract idea. I just think there should be a clearer declaration of types rather then having a header define them based on ones which are not always the same. I'm not gonna debate this one much though, because it's not really a pressing issue unless you're working with older toolchains. Would just be a perk.