C Specification Ideas
-
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.
-
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 ;)