So what is it? is the 100 a char or an int? Yes, it IS an int and it is being assigned to a char without a (char) on the basis of your earlier argument about "safety" and "footguns" I must assume that you always insert the (char) in such cases, if not why not?
That's actually a good question. Yes, sometimes I write explicit cast, sometimes not. The reason not to is when it is obvious what is going to happen anyway (I assume the reader knows the basics of the C standard, but don't assume they know every detail by heart). Such case is assigning uint8_t to uint32_t: it is obvious that the input range [0..255] maps to output range [0..255] and extra bits get filled with zeroes.
On the other hand, maybe I want to emphasize the fact extra bits are generated. Not to compiler, but human reader. Then why not add the explicit cast.
Or, when I convert a float to integer, let's say:
double asdf = 123.4;
int val = asdf + 0.5; // round up and truncate after decimal point
One can emphasize the conversion by writing:
int val = (int)(asdf + 0.5);
But, you can just write
int val = asdf + 0.5;
because the implicit conversion does the same.
But explicit makes sense, because the same thing could be used in a more complex expression, where adding the cast does make the difference:
double something_else = (double)(int)(asdf+0.5) * qwerty;
Remember, programming is not only about making compiler happy, but to convey the meaning to human readers, too.
char X;
Data Y;
X = (char)0;
Y = (Data){0};
People get surprisingly defensive about it—perhaps it's Stockholm Syndrome?—but C simply isn't a well-designed language. The fact that the other popular alternatives are more complex and worse (C++? really?) doesn't change that. The fact that you know its edge cases well enough to get by (but probably not well enough to avoid a myriad sources of bugs and security vulnerabilities unique to the language) doesn't change it either.
If being explicit about the type is so helpful then why do we not see this on every assignment:
The problem with yourself is, because you don't read, you never learn.
Yes, everything does indicate that.
Now there's nothing wrong with not having read everything; we all start out as beginners. Nor is there anything wrong with going through some of the same thought processes as people have done in the past.
But not knowing the literature, not bothering to read things people suggest would advance his understanding and thinking, and still expecting other people to "discuss" and "explain" things is bad form.Likely not, I don't usually play these games for too long, it's getting near to the point of getting nothing out of it.
I, and some others, decided that a while ago. The only reason I bother to look at this thread is that some of the peripheral things mentioned by other people are interesting.
But, hey, go knock yourself out
What exactly have I written that you regard as untrue?
...
If being explicit about the type is so helpful then why do we not see this on every assignment:
The problem with yourself is, because you don't read, you never learn.
Yes, everything does indicate that.
Now there's nothing wrong with not having read everything; we all start out as beginners. Nor is there anything wrong with going through some of the same thought processes as people have done in the past.
But not knowing the literature, not bothering to read things people suggest would advance his understanding and thinking, and still expecting other people to "discuss" and "explain" things is bad form.Likely not, I don't usually play these games for too long, it's getting near to the point of getting nothing out of it.
I, and some others, decided that a while ago. The only reason I bother to look at this thread is that some of the peripheral things mentioned by other people are interesting.
But, hey, go knock yourself out
What exactly have I written that you regard as untrue?
...
Thereby indicating you didn't read what I wrote.
QED.
Code: [Select]char X;
Data Y;
X = (char)0;
Y = (Data){0};
If I am allowed to omit the (char) then logically I should also be allowed to omit the (Data),
Code: [Select]char X;
Data Y;
X = (char)0;
Y = (Data){0};
If I am allowed to omit the (char) then logically I should also be allowed to omit the (Data),
The expression Y={0} were already syntactically wrong, because {0} is not a valid expression according to the language definition.
A philosophy of C is that each expression has its own intrinsic type which does not depend on the context in which the expression is used. Therefore {0} cannot be a valid expression, because no unique type can be deduced from {0} alone. OTOH, the integer literal expression 0 has an intrinsic type (which is int).
EDIT:
Note that (Data){0} is NOT a cast expression, but a compund literal. The (Data) is part of the literal.
OTOH, (char)0 is a cast expression (unary cast operator) which converts the integer literal 0 to type char.
MyStructure datum = {0};
short X = 0;
short Y; Y = 0;
If being explicit about the type is so helpful then why do we not see this on every assignment:
The problem with yourself is, because you don't read, you never learn.
Yes, everything does indicate that.
Now there's nothing wrong with not having read everything; we all start out as beginners. Nor is there anything wrong with going through some of the same thought processes as people have done in the past.
But not knowing the literature, not bothering to read things people suggest would advance his understanding and thinking, and still expecting other people to "discuss" and "explain" things is bad form.Likely not, I don't usually play these games for too long, it's getting near to the point of getting nothing out of it.
I, and some others, decided that a while ago. The only reason I bother to look at this thread is that some of the peripheral things mentioned by other people are interesting.
But, hey, go knock yourself out
What exactly have I written that you regard as untrue?
...
Thereby indicating you didn't read what I wrote.
QED.
Nor will I be reading anything else you write.
Well this also contains an invalid expression then too surely?Code: [Select]MyStructure datum = {0};
proc initialize (count)
{
arg count bin(8,2); // fixed point binary, 6.2 format
dcl register_mask bin(24,8);
dcl temporary dec(15,3); // fixed point decimal, 12.3 format
count = 110011.01B;
temporary = 23 000 000 000.25;
register_mask = 2F03 D7F8.2:H;
// Or equivalently
register mask = 10 1111 0000 0011 1101 0111 1111 1000.00100000:b;
}
QuoteIf being explicit about the type is so helpful then why do we not see this on every assignment:The problem with yourself is...this is going to be a looong threadLikely not, I don't usually play these games for too long, it's getting near to the point of getting nothing out of it.
Well this also contains an invalid expression then too surely?Code: [Select]MyStructure datum = {0};
In conjunction with the declaration of datum, the ={0} is an initialization, and {0} is still not an expression, but an initializer-list enclosed in braces.
See https://en.cppreference.com/w/c/language/initialization
Well this also contains an invalid expression then too surely?Code: [Select]MyStructure datum = {0};
In conjunction with the declaration of datum, the ={0} is an initialization, and {0} is still not an expression, but an initializer-list enclosed in braces.
See https://en.cppreference.com/w/c/language/initialization
Yes, what you say is likely absolutely the case, that doesn't justify the design though, in the case of initializing a declaration, populating the lvalue is what happens and there's no need I can see for distinguishing between an lvalue used when we declare vs an lvalue used as the source expression of an assignment.
What I can "do to" the memory associated with some variable shouldn't differ between declaring it and assigning to it, IMHO anyway.
typedef struct { int x; } Data;
int f()
{
return {0}.x;
}
typedef struct { int x; } Data;
int f()
{
return (Data){0}.x;
}
OTOH, with a properly typed compound literal (which is a valid expression) it works as expected, and f() returns 0:Code: [Select]typedef struct { int x; } Data;
int f()
{
return (Data){0}.x;
}
OTOH, with a properly typed compound literal (which is a valid expression) it works as expected, and f() returns 0:Code: [Select]typedef struct { int x; } Data;
int f()
{
return (Data){0}.x;
}
Exactly. You can come up with more examples like this - the point is, the grammar and syntax is logical and repeatable.
There already is one "exception" to this logic, namely initializer list being a different animal from compound literal, and not needing a type.
One could argue C should add more of same type of exceptions, like the "in case of assignment to a struct type, compound literal is assumed to have the type of assignment target, unless otherwise explicitly typed". OK, then what? Now we have introduced more rules to the language, and what did we achieve? We saved a few keystrokes, hid the type from view, and you STILL need to write the type in all other forms of expressions.
Such thinking is very superficial. Again, the number of keystrokes needed is unimportant. Having to type something explicitly is a "problem" only for total beginners, who think majority of time spent in programming is hitting the keys. And any of this has absolutely no fundamental effect on the language design. More fundamental is the fact that these expressions have a type which is known at compile time, to both the programmer and the compiler.
proc initialize (count)
arg count bin(8,2) // fixed point binary, 6.2 format
dcl register_mask bin(24,8)
dcl temporary dec(15,3) // fixed point decimal, 12.3 format
count = 110011.01B
temporary = 23 000 000 000.25
register_mask = 2F03 D7F8.2:H
// Or equivalently
register mask = 10 1111 0000 0011 1101 0111 1111 1000.00100000:b
end
proc initialize (count)
if (a = 23)
a = 0
end
if (a = 55)
a = 10
end
if (a > 1024)
a = 0
call reset(100)
end
if (a < 2048)
a = 50
call restart(0)
else
a = 1024
end
while (state = READY)
call refresh_display(250)
state = get_state()
end
end
Such thinking is very superficial. Again, the number of keystrokes needed is unimportant. Having to type something explicitly is a "problem" only for total beginners, who think majority of time spent in programming is hitting the keys.
if(a == b)
c = 10
end
if(a == b)
{
c = 10;
}
Code: [Select]if(a == b)
c = 10
end
Is basically just as much typing asCode: [Select]if(a == b)
{
c = 10;
}
I myself like the braces. Wish they had used them in verilog in the same way instead of the begin and end... statements. But that comes down to what one is used to.
line:
while (myLine = readLine())
:
if (...) next line;
:
if (...) last line;
:
end while line
I like "end" better, if only because it makes for tidier syntax for signalling what is is you are ending, in a way that the compiler can check (i.e. not just a comment).
........
On the "end" statement, either the "while" or the label can be omitted: "end", "end while", "end line".
If (a = b) Then
c = 10
End If
the problem with it is it doenst support pointer and true OOP.. if Basic can do whatever C can, i think i've left C behind too long time ago...Code: [Select]If (a = b) Then
c = 10
End If
Code: [Select]if(a == b)
c = 10
end
Is basically just as much typing asCode: [Select]if(a == b)
{
c = 10;
}
I myself like the braces. Wish they had used them in verilog in the same way instead of the begin and end... statements. But that comes down to what one is used to.
And frankly this is all cosmetics, nothing to do with improving functionality of a programming language. So I agree with SiliconWizard that it is futile.
Code: [Select]If (a = b) Then
c = 10
End If
That hurts my (somewhat pedantic and logical) eye because the same operator (=) is used for two different purposes. I don't mind using = as comparison operator, but then something else is needed for assignment, such as :=, or, borrowing from mathematics, "let c = 10".
If (a = b)
c = 10
end
If (a = b)
c <= 10
end
Code: [Select]If (a = b) Then
c = 10
End IfThat hurts my (somewhat pedantic and logical) eye because the same operator (=) is used for two different purposes. I don't mind using = as comparison operator, but then something else is needed for assignment, such as :=, or, borrowing from mathematics, "let c = 10".
I understand you, but allowing and assignment to also be an expression is illegal, meaningless in many programming languages.