C Specification Ideas
-
No, it had a specifier "OPTION ORIGIN 0" or some such thing that was global to the execution unit. You couldn't specify it on one variable but not another I used VB2 (bleah!) and I think VB4 or 5 or some such thing. Also VB6. Ptui. Now see what you've done. Gotta go sterilize my mind now with some alcohol or something stronger.
-- Harvey
:laugh: Always at your service. I always recommend an old whisky or rum.
Be excellent to each other. And... PARTY ON, DUDES! Abraham Lincoln
-
Joe Woodbury wrote:
One thing that cracks me up about C++11 (and C#) is how many of the new features are there to fix old features
I can't recall seeing that. I can't really recall seeing even one.
Joe Woodbury wrote:
okay, really annoys me--is how often procedural code is tied up into classes and an object hierarchy
Some things that annoy me are - no project management - poor project management - the inability to differentiate between project management and task management. - no requirements - poor requirements - no architecture - poor architecture - no design - poor design - no process control - poor process control - substituting one process control methodology for another to 'fix' Of course none of that has anything to do with poor implementations. But then those, like your example, are rather trivial in terms of those other problems. Not to mention of course that good process control fixes implementation problems.
Joe Woodbury wrote:
When I pointed out all the static classes with static members in some of our C# code, they shrugged it off
Hard to say what "all" means of course but if there are a significant number then that is likely a no/poor design problem (see above.) Or a process control problem (see above.) If there are only a few cases then it might very will be appropriate since OO is not an absolute.
jschell wrote:
Some things that annoy me are
- Absence of execution unit concepts (requiring compiler "extensions" such as dll export, name mangling details, ...) - Poor/poorly specified memory model - Inadequate handling of multiple processors (but it is getting better) - Overloaded terms (static, auto, ...) I have more...
-- Harvey
-
Joe Woodbury wrote:
One thing that cracks me up about C++11 (and C#) is how many of the new features are there to fix old features
I can't recall seeing that. I can't really recall seeing even one.
Joe Woodbury wrote:
okay, really annoys me--is how often procedural code is tied up into classes and an object hierarchy
Some things that annoy me are - no project management - poor project management - the inability to differentiate between project management and task management. - no requirements - poor requirements - no architecture - poor architecture - no design - poor design - no process control - poor process control - substituting one process control methodology for another to 'fix' Of course none of that has anything to do with poor implementations. But then those, like your example, are rather trivial in terms of those other problems. Not to mention of course that good process control fixes implementation problems.
Joe Woodbury wrote:
When I pointed out all the static classes with static members in some of our C# code, they shrugged it off
Hard to say what "all" means of course but if there are a significant number then that is likely a no/poor design problem (see above.) Or a process control problem (see above.) If there are only a few cases then it might very will be appropriate since OO is not an absolute.
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.
-
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
Why not post this on the CodeProject C/C++/MFC forum ?
“Human beings do not live in the objective world alone, nor alone in the world of social activity as ordinarily understood, but are very much at the mercy of the particular language which has become the medium of expression for their society. It is quite an illusion to imagine that one adjusts to reality essentially without the use of language and that language is merely an incidental means of solving specific problems of communication or reflection." Edward Sapir, 1929
-
Why not post this on the CodeProject C/C++/MFC forum ?
“Human beings do not live in the objective world alone, nor alone in the world of social activity as ordinarily understood, but are very much at the mercy of the particular language which has become the medium of expression for their society. It is quite an illusion to imagine that one adjusts to reality essentially without the use of language and that language is merely an incidental means of solving specific problems of communication or reflection." Edward Sapir, 1929
I was lookin for one, but the discussion lounge was the closest thing to it I could find...This site is really awkward to navigate... The article editor is a little glitchy too. Really having to abuse the remove tags button.
-
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
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.
-
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 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.
-
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
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. -
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.YvesDaoust wrote:
- built-in min and max operators, they are so useful !
a= (i /\ j /\ k) \/ 3;
X\/= Y;I am assuming that your sample is meant to be semantically equivalent to something like
#define min(a, b) = ((a) < (b) ? (a) : (b))
#define max(a, b) = ((a) > (b) ? (a) : (b))
a = min(max(i, max(j, k)), 3);
x = min(x, y);Are you aware that the
\character was added to ASCII for use in\/and/\operators to represent 'or' and 'and' in languages like ALGOL (and ALGOL derived languages such as C). The||and&&symbols were used in later versions of C. See, for example, en.wikipedia.org/wiki/Backslash -
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
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?
-
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.