You can write slow, clunky, unstable, hideous code in any language. An experienced programmer will do neither. In any language. This is definately true, but C++ takes the cake for it's horrid grammar. understandardized: if anything, there are now more standards in effect for C++ than there are for C. In concept. No C++ compiler actually meets the standard, which is what I was referring to. You may be mixing this up with the .NET runtime library. but that's C# (and AFAIK also "Managed C++", but I'm not sure). This is however not true for native C++. Once you compile and link a (native) C++ program it is no different from a C program. Writing C code in a .cpp file does not count as C++. C++ depends on non-portable libraries such as malloc, and produces inflated code which cannot be use on some devices due to memory restrictions. Primary example of a popular platform C++ could not be used on is the N64. It didn't have a C++ runtime, so all the games were written in C, as are all developer examples. People will argue to their blue in the face over this, but I've personally seen where it can't be used so I disagree.

This should never work, and never actually be done, unless there is a meaningful and well-defined conversion between these types! THAT'S WHAT CASTING DOES. No matter how skilled you are, there will always be a case in which you need to perform a type cast. For example, when working with memory-mapped hardware:

volatile unsigned int *frameBuffer = (unsigned int *)0x80100000;

There's no workaround or way to avoid this. The framebuffer is at 0x80100000. That's an integer, the frameBuffer is a pointer. You need to cast! This is just one of the most ridiculous arguments I've every heard :omg:

but some compilers can target multiple architectures at once, meaning the size of those can change. GCC itself includes identifiers like _IntN_Type_ as well, so it's not like it's like it's an abstract idea. I just think there should be a clearer declaration of types rather then having a header define them based on ones which are not always the same. I'm not gonna debate this one much though, because it's not really a pressing issue unless you're working with older toolchains. Would just be a perk.

Encapsulation. You aren't aware of it, but you're quite an ignorant person. There isn't even a clear definition for what encapsulation is. To encapsulate is just to contain, there's no definition of it which dictates which privileges those encapsulated classes may have. Hell,

struct {
struct {
float x;
} sub;
} main;

can be considered encapsulation. Ah, perhaps you've never done real software development, which involves more than one person and more than one business entity. Access modifiers allow you to change the internals of your classes without the risk of breaking user code over which you have no control. ...in exchange for breaking the entire project when the privileges of a member need to be changed, and thus requiring every member of your team to obtain a clean build of the project. btw, I'd appreciate it if we acted like adults and refrained from called each other stupid.

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 type

try building your project with -Werror and this is a recipe for disaster.

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.

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.

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:

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.

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 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.

HMODULE hMod = LoadLibrary("mydll.dll"); // load library
if (hMod) {
void (*)() myfn = (void (*)())GetProcAddress(hMod, "myfn"); // initialize pointer to myfn function inside dll
if (myfn) myfn(); // call it if it exists
FreeLibrary(hMod); // free the library
}

EDIT: Wasn't exactly sure what you're asking...

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.

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.

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.

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.

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