C Specification Ideas
-
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:
and stdint isn't really much of a fix considering it does stupid stuff like
typedef short int16_t;
which may not always be the case.
Apparently it is the case on whatever platform that specific implementation of stdint is intended for.
-
Ghosuwa Wogomon wrote:
and stdint isn't really much of a fix considering it does stupid stuff like
typedef short int16_t;
which may not always be the case.
Apparently it is the case on whatever platform that specific implementation of stdint is intended for.
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.
-
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
If you want to ruin the language, just use C++11.
-
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
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
-
If you want to ruin the language, just use C++11.
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.
-
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.