C Specification Ideas
-
Nonzero Index Origin
Array indices are currently always zero (0). The stated reason is so that the generated code doesn't have to do a subtraction during index calculation. In other words, it is for the convenience of the compiler/computer. This is 2013, and this concept should be purged. If I have an array of things that don't start at zero, I should be able to get the compiler to do the index heavy lifting instead of imposing this on the error prone programmer. A corresponding lower bound and upper bound index indicator would be helpful as well. You should be able to specify:int primelist[2:103] = {0};
for (int i = primelist.lower_bound(); i <= primelist.upper_bound(); ++i)
{
primelist[i] = ...;
}This just might fix a number of "off by one" errors too.
-- Harvey
H.Brydon wrote:
Array indices are currently always zero (0)....This is 2013, and this concept should be purged.
Heresy! Get the torches and pitchforks! Seriously, it doesn't matter much if array indexes start at 0 or 1, as long as it is consistent, if there is confusion terrible bugs can ensue. But that's not what you're talking about, you want to specify an arbitrary index offset, which is a different thing. That is not an argument against the convention of zero-index arrays. If you want to specify an arbitrary starting index, why not just implement your own library for that? Like dynamic arrays, it doesn't have to be a part of the language, you are free to implement it at a higher level. No need to monkey with the language itself. You seem to be wanting to connect the semantic meaning of the data with the data structure in memory. It doesn't really work that way, those are different things. It doesn't matter what the data represents when you are working at the array level, you are just working with an offset of an address in memory. Working with memory is a compiler/OS problem, working with data structures at the semantic level is the programmer's problem.
-
Call me old-fashioned or purist, but I do not see the need of adding more features to C. The beauty of the language is related to its simplicity, as the most common assembly language replacement available. Furthermore, many of the wishes and wants are found in C++ - so why not go there?
NAANsoft wrote:
Call me old-fashioned or purist, but I do not see the need of adding more features to C. The beauty of the language is related to its simplicity, as the most common assembly language replacement available.
This, a thousand times over. The whole point of C is that it is a simple language that is very powerful due to being such a low-level language. There is no need to turn it into a higher-level language when, as you say, C++ already did that. I've always been under the impression that C programmers built libraries for the high-level features they wanted, instead of expecting the language to provide syntactic sugar. C is a beautiful thing, it is unique and has its place as being both low-level and productive, feature-bloat would ruin it.
-
jschell wrote:
I can't recall seeing that. I can't really recall seeing even one.
To illustrate. Once you create a constructor, how do you handle failure. Exceptions. Well, exceptions cause another host of issues and edge cases, so the standard has to be adjusted to accommodate that. Another example is that if you have a vector and the vector needs to be resized, for performance reasons you need move semantics. Then there are the issues with rvalues, temporary objects, NULL and so forth.
jschell wrote:
Hard to say what "all" means of course but if there are a significant number then that is likely a no/poor design problem
"all the static classes" meant all of the classes which were static, nothing more, nothing less. The point is that static classes are sometimes required, but are procedural code. Likewise, many classes are really nothing more than procedural calls (something may be a data member instead of a parameter, but there is nothing object oriented about it--classes are essentially being used as namespaces.)
jschell wrote:
Some things that annoy me are
Shellfish annoy me--okay make my tongue swell--but I was speaking of something specific.
Joe Woodbury wrote:
Well, exceptions cause another host of issues and edge cases, so the standard has to be adjusted to accommodate that.
What new "feature" was added to an existing standard to deal with that 'problem'?
Joe Woodbury wrote:
for performance reasons you need move semantics.
Maybe I don't understand what you are saying but far as I can recall that had to do with library functionality and not a language "feature". So exactly which "feature" did you have in mind. Might be interesting to contrast that with the definitely new "feature" of C for anonymous structures.
Joe Woodbury wrote:
The point is that static classes are sometimes required, but are procedural code
Which means nothing. As I already said OO isn't an absolute. It is not and never was supposed to be an absolute. And all non-trivial business applications deal with any number of problems which do not lend themselves do complete solutions in one paradigm. Web apps that use SQL are an excellent example of that.
Joe Woodbury wrote:
but I was speaking of something specific.
And I was specific about problems that seem to exist every where and which have significant and often measurable costs.
-
Ghosuwa Wogomon wrote:
Blocks in Expressions
I have no idea what you mean. Could you elaborate?
Ghosuwa Wogomon wrote:
Unify Function Types
No. Any application that can be called from within a batch file must return a value. You could argue that a float or double value might also be feasible, but void is not, and void* doesn't even make sense. On a sidenote, what do you mean by "necessity of a cast" in that context? :confused: 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.
In the C standard, only [] and () can be used in expressions. GCC features an extension that allows blocks of code to be used in expressions like:
({ int i; for (i = 0; i < 5; i++); i; })
-
(I accidentally hit "Post Message prematurely" - so here's the rest of my posting:)
Ghosuwa Wogomon wrote:
Embedded Functions
Care to elaborate for non-GCC users?
Ghosuwa Wogomon wrote:
Simpler Lambda
I'm not sure it can be any simpler without creating ambiguities or restricting this functionality. I'm sure the standardization committee spent a lot of time to make the syntax as simple and concise as reasonably possible.
Ghosuwa Wogomon wrote:
Struct Declaration
I agree it would be nice if you could specify default values for member variables without having to write those into a constructor, or in fact every constructor that you define. Then again, whis would be yet another breaking of the information hiding principle: it's bad enough that you have to expose your data structure within the class definition for everyone to see. Personally, before adding this initialization feature, C/C++ should allow the separation of the class data (member variables) from the class API (member functions). Once that is accomplished adding default values to member declarations shouldn't be a problem.
Ghosuwa Wogomon wrote:
Typedef Initialization
No: for simple types this would create too much confusion as people who use the original type or the typedef'd name would expect different behaviour. For structured types it would already be covered by your previous suggestion.
Ghosuwa Wogomon wrote:
Pointer Declaration
I can't think of any context where that would be useful. If I want to use a constant, I use a constant, not a pointer to a constant.
Ghosuwa Wogomon wrote:
Default Integer Declarations
Many compilers already provide these. But I agree it would be nice if they were standardized to start with.
Ghosuwa Wogomon wrote:
Non-Integer Value in Enumerations [...] Typed Enumerations
Included with C++11. You can now define enumerations of any type.
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.
-
Just a few little things: - binary format specifier in
printfformat strings (i.e.printf("%03b", 3);saying011). - array/struct initializers in place of variables, allowing expressions likeWeight= { 1, 2, 5, 7 }[i];- token pasting operator ## even outside macro definitions, like:#define Prefix Test
Prefix##Data= 0;- built-in min and max operators, they are so useful !
a= (i /\ j /\ k) \/ 3;
X\/= Y;-
<math>functionsifloorandiceilreturning integer instead of floating-point.All but the second idea sound great to me :D I especially love the third, that would be a perfect way to declare namespaces in C! :thumbsup:
-
NAANsoft wrote:
Call me old-fashioned or purist, but I do not see the need of adding more features to C. The beauty of the language is related to its simplicity, as the most common assembly language replacement available.
This, a thousand times over. The whole point of C is that it is a simple language that is very powerful due to being such a low-level language. There is no need to turn it into a higher-level language when, as you say, C++ already did that. I've always been under the impression that C programmers built libraries for the high-level features they wanted, instead of expecting the language to provide syntactic sugar. C is a beautiful thing, it is unique and has its place as being both low-level and productive, feature-bloat would ruin it.
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:
Blocks in Expressions
I have no idea what you mean. Could you elaborate?
Ghosuwa Wogomon wrote:
Unify Function Types
No. Any application that can be called from within a batch file must return a value. You could argue that a float or double value might also be feasible, but void is not, and void* doesn't even make sense. On a sidenote, what do you mean by "necessity of a cast" in that context? :confused: 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.
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.
-
Ghosuwa Wogomon wrote:
Blocks in Expressions
I have no idea what you mean. Could you elaborate?
Ghosuwa Wogomon wrote:
Unify Function Types
No. Any application that can be called from within a batch file must return a value. You could argue that a float or double value might also be feasible, but void is not, and void* doesn't even make sense. On a sidenote, what do you mean by "necessity of a cast" in that context? :confused: 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.
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.
-
true, but there are special cases. take for example the mips architecture where there are 16, 32, and 64-bit versions. depending on your target, the size of the integers can change. I'd much rather prefer the compiler itself telling me what it's doing than an automatically generated header.
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.
-
That's generally my exact same opinion. I pretty much only use classes for the sake of organization, and don't understand the reasoning behind stuff like access modifiers. What's the point in restricting your own code? It doesn't add any security, you're constantly changing it, and every change requires an entire clean rebuild of your project since all the other classes are built with the notion that such-n-such is private. Some people defend it by saying it serves as a reminder to the developers, but that's what comments are for, and if a developer doesn't know whether or not he or she should use a certain variable, maybe he or she shouldn't be working on it in the first place. Most of my smaller projects are straight-up procedural, but my larger projects tend to use structs and function pointers mainly for the sake of namespacing.
"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.
-
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.