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
that's because the value isn't an index, it's an offset. when you say
int mylist[3] = {1, 2, 3};
int i = mylist[1];You're saying to set 'i' to the value at the address of 'mylist' + sizeof(int) * 1.
-
that's because the value isn't an index, it's an offset. when you say
int mylist[3] = {1, 2, 3};
int i = mylist[1];You're saying to set 'i' to the value at the address of 'mylist' + sizeof(int) * 1.
Ghosuwa Wogomon wrote:
You're saying to set 'i' to the value at the address of 'mylist' + sizeof(int) * 1.
So have it set 'i' to the value at the address of 'mylist' + sizeof(int) * (1 - lowerbound()), which can be easily optimized by the compiler to 'mylist' + sizeof(int) * 1 for the special case of zero lower bound.
-- Harvey
-
ah hellz nah...lol over the past 2 or 3 years I've done decided I want nothing to do with C++ anymore. that's why when I was posting my ideas I wanted to stray away from anything that effects the keywords or punctuation of the language. I've kinda become an anti-oo guy who likes to do oo things. It's actually really amazing what you can do in C if you know how to use it properly, but many people are just lazy or completely underrate the language.
To be clear, I generally don't like C++11. I find it ugly and that it furthers the illusion that you are writing efficient code. My solution is to do C with classes; basically writing C using C++. One thing that cracks me up about C++11 (and C#) is how many of the new features are there to fix old features--it becomes all rather circular. (I also think C++, C# and Java were primarily invented because of an irrational fear of pointers.) (Edit: Another thing that cracks me up--okay, really annoys me--is how often procedural code is tied up into classes and an object hierarchy. One day I observed that a certain module of ours had a singleton factory which produced exactly one instance of a class and that the whole thing could be rewritten using procedural code with a half dozen globals and in the process made absurdly simple, solving several bugs. Moreover, the use of STL and Boost was major overkill [among other things shared_ptr was being passed around when a const* would be sufficient.] Needless to say, the other developers recoiled in horror. Apparently globals are evil and everything must have a class! [When I pointed out all the static classes with static members in some of our C# code, they shrugged it off.])
-
To be clear, I generally don't like C++11. I find it ugly and that it furthers the illusion that you are writing efficient code. My solution is to do C with classes; basically writing C using C++. One thing that cracks me up about C++11 (and C#) is how many of the new features are there to fix old features--it becomes all rather circular. (I also think C++, C# and Java were primarily invented because of an irrational fear of pointers.) (Edit: Another thing that cracks me up--okay, really annoys me--is how often procedural code is tied up into classes and an object hierarchy. One day I observed that a certain module of ours had a singleton factory which produced exactly one instance of a class and that the whole thing could be rewritten using procedural code with a half dozen globals and in the process made absurdly simple, solving several bugs. Moreover, the use of STL and Boost was major overkill [among other things shared_ptr was being passed around when a const* would be sufficient.] Needless to say, the other developers recoiled in horror. Apparently globals are evil and everything must have a class! [When I pointed out all the static classes with static members in some of our C# code, they shrugged it off.])
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.
-
Ghosuwa Wogomon wrote:
You're saying to set 'i' to the value at the address of 'mylist' + sizeof(int) * 1.
So have it set 'i' to the value at the address of 'mylist' + sizeof(int) * (1 - lowerbound()), which can be easily optimized by the compiler to 'mylist' + sizeof(int) * 1 for the special case of zero lower bound.
-- Harvey
I think you're misunderstanding the concept a little... There are no arrays in C. The term 'arrays' used in C is simply to abstract the idea of pointers.
const char *test = "derp";
int *i = (int *)0x80010000;
float vector[] = { 1.2f, 3.4f, 5.6f };
void *pmyobj = &myobj;All the above are the same thing, pointers. 'test' is a pointer to the string "derp" in ram, 'i' is a pointer to the ram address 0x80010000, vector is a pointer to a stream of 3 floating point value in ram, and 'pmyobj' is a pointer to the object 'myobj' in ram. There is no upper or lower boundary of any of these, so 'test[9000]', 'i[9000]', 'vector[9000]', and 'pmyobj[9000]' are all perfectly valid. They're just pointing to their address + sizeof(self) * 9000.
-
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
So you're saying that VB got it right all that time. Have an upvote for daring to say that in this VB hostile environment. :-D
Be excellent to each other. And... PARTY ON, DUDES! Abraham Lincoln
-
So you're saying that VB got it right all that time. Have an upvote for daring to say that in this VB hostile environment. :-D
Be excellent to each other. And... PARTY ON, DUDES! Abraham Lincoln
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
-
To be clear, I generally don't like C++11. I find it ugly and that it furthers the illusion that you are writing efficient code. My solution is to do C with classes; basically writing C using C++. One thing that cracks me up about C++11 (and C#) is how many of the new features are there to fix old features--it becomes all rather circular. (I also think C++, C# and Java were primarily invented because of an irrational fear of pointers.) (Edit: Another thing that cracks me up--okay, really annoys me--is how often procedural code is tied up into classes and an object hierarchy. One day I observed that a certain module of ours had a singleton factory which produced exactly one instance of a class and that the whole thing could be rewritten using procedural code with a half dozen globals and in the process made absurdly simple, solving several bugs. Moreover, the use of STL and Boost was major overkill [among other things shared_ptr was being passed around when a const* would be sufficient.] Needless to say, the other developers recoiled in horror. Apparently globals are evil and everything must have a class! [When I pointed out all the static classes with static members in some of our C# code, they shrugged it off.])
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.
-
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
That's actually how VB worked before it became .net if I recall it correctly.
Be excellent to each other. And... PARTY ON, DUDES! Abraham Lincoln
-
That's actually how VB worked before it became .net if I recall it correctly.
Be excellent to each other. And... PARTY ON, DUDES! Abraham Lincoln
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
-
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?