|
It is/was trash. I really had in my brain that returns "index - 1" 
|
|
|
|
|
In
0x01AA wrote: // Here some code which calculates "index + 1"
, are there side effects that need to be accounted for?
|
|
|
|
|
No, it was really just my mental derangement that made me think this returns (index-1)
|
|
|
|
|
There is a forum for code like that: The Weird and The Wonderful[^]
But hey! We all do it ... so don't knock yourself. I once spent three days designing an application in C#, until I realized you can't inherit from static classes and it was all useless.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Can't inherit enums either. 
|
|
|
|
|
I've never wanted to, but I can understand why you can't.
I can understand why you can't for static classes as well, once I thought about it. 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Yeah, but unfortunately when someone says, "I wish I could write X", the typical response is, "you can't because blah blah vtable blah".
But I don't care about what the current language/compiler/implementation can't do and _why_ it can't do it. I want a better language and compiler which _can_.
A language which _does_ allow inheriting static classes? Sure.
A language which _does_ allow multiple-inheritance? Sure.
It's like saying, "I want to travel 100MPH", and having someone respond, "you can't because horses can't run that fast" -- I know they can't, therefore the solution will _not_ involve horses, duh!
If C# can't do it, then give me language which can.
I know I am unqualified to define and implement such a language.
I really grow tired of C# and .net -- they're ancient, designed by committee, were rushed to market, and we need something better.
|
|
|
|
|
(regarding inheriting enums)OriginalGriff wrote: I've never wanted to, but I can understand why you can't.
I can't understand why C# didn't get a proper first class enum data type. After all, Pascal has had it since 1970. It was even into the design of Algol 60 ('60' refers to the year 1960), but the deadline for publication of the standard was considered absolute, and there were a few details still to be worked out - so it was dropped from the published standard. Nic Wirth didn't invent the enum concept, he knew it from the Algol discussions ten years earlier, 62 years ago (although C# first appeared "only" 40 years after Algol 60, 30 years after Pascal).
Today's C# enum is very close to using #define to name integer literals in K&R C. It has its own keyword, and a syntax for simpler naming of consecutive integer values, but that's about it. I think of enums as integer literal names - that's what they are in C#. Not a type, as in Pascal.
|
|
|
|
|
Same in C++ until enum class got added, which I have yet to use because a static_cast must be used to convert one of its enumerators to an int, which is often what you want to do. At least Pascal has succ and pred, or is it prev?
|
|
|
|
|
I wasn't involved in the design, but it's probably because enum is a basic type: an integer on steroids if you like.
Which makes it a value type rather than reference, and those are implicitly sealed so they can't be inherited. That may be for performance reasons - inheritance checking each time you used a number could get seriously burdensome.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Surely, but so what? A new (better) language could be defined which does allow it.
There appear to have been a whole lot of bad decisions made in the design of .net -- the whole concept of, "this is a value type , this is a reference type", doesn't serve the developer. A whole bunch of classes are sealed or have non-virtual members for no good reason.
Far too much ivory-towering must gone on with too little defenestration of the culprits.
Very likely, they concentrated too much on attracting VB developers.
|
|
|
|
|
At least it wasn't four days!
|
|
|
|
|
There is that ... Always Look on the Bright Side of Life[^]
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
David O'Neil wrote: Favorite 3 course video extravaganza: Life of Brian, The Meaning of Life, and The Blues Brothers.
I think I'd want to throw Blade Runner and Pulp Fiction in there? Maybe Chariots of Fire as well?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Loved Blade Runner! Hated 2049 - So boring!!!!!!!!!!!!!!!!!!!! Pulp Fiction - Great, but I think I'd go with his Kill Bill trilogy first - Fantasticer! (But they are both great!)
I'll have to check out Chariots of Fire - never seen it that I remember. Also need to watch Close Encounters, now that you fail to mention it.
|
|
|
|
|
I just spent a half hour tracking down a weird bug... I had left out an else... 
...
}
{
...
|
|
|
|
|
The compiler usually give you a warning about "Empty statement" (which in my case is usually intended and explained in a comment).
It shouldn't be much more difficult to give a warning: "Redundant braces". That would have caught errors like this.
Sure this comes in two levels: If there is no variable declarations or other scope-limited constructions within the block, the braces are truly redundant. With block local variables and the like, they may be intended even if the block is not associated with a control statement. I very rarely see code doing that; I think the number of "false positives" would be quite low. (And there could be an option to control it.)
|
|
|
|
|
Yeah, dunno, not a fan of warnings myself.
What would you expect for this?
# if EnableValidationOfX
if ( X > 0 )
# endif
{
... Do something potentially dangerous with X
}
|
|
|
|
|
For my preferred coding style, there would be no problem, as I put the opening brace at the line of the statement using the block, i.e. at the end of the if statement. That would be require the closing brace to be commented out as well - and the compiler would tell you, if you forgot to.
Assuming your bracing style with separate brace lines, you could of course do the same: Move the # endif down one line and add a # to the closing brace line. Whichever solution you choose, I dislike it: I assume that the block between the braces is indented. This is misleading when the 'if (X>0)' is not compiled.
However, I would never disable validation of X, and most certainly not by an #if directive. I would have made EnableValidationOfX a variable, so that it can be enabled without recompiling, in the binary environment where you experience a problem with invalid X values.
If you insist on the #if, and refuse to include the braces in the conditional compilation, I would prefer that the compiler gives a warning if you compile with EnableValidationOfX is false. If this coding style is common to you, you should probably disable the "Redundant braces" warning altogether.
There is another construct where I guess that lots of others disagree: In a switch(), I like to indent the statements in each case from the case label. I also frown when I see an indent/undent with no brace: Braces and indents go hand in hand. So I like to add braces around the lines of each case. But C class languages do not require case to be a block (also, a single statement is not defined to be a block), so the braces are redundant. If we got the compiler to warn about redundant braces, I would want it to have options to allow my coding style of making each case alternative a block. (But I guess a lot of you would scream at my use of redundant braces in switch() statements!)
One thing I like about lint is that you can insert a lint comment that disables a check for this line only. If you occasionally, but not very often, use constructs like the one above, a similar mechanism for suppressing the warning at this occasion as a special case, would be very nice. It would also serve as a documentation to other programmers to explain that the braces are indeed intended.
|
|
|
|
|
trønderen wrote: each case from the case label.
trønderen wrote: Braces and indents go hand in hand
Uh, huh, I agree...
switch ( foo )
{
case bar :
{
...
break ;
}
...
}
|
|
|
|
|
The suits just said ship it anyway. 
>64
Some days the dragon wins. Suck it up.
|
|
|
|
|
I honestly don't understand the point of this post. Is it a joke?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
No, it is not a joke.
My code was return(index--) and whyever in my brain it was equivalent with return(index - 1) 
|
|
|
|
|
If you want index-1, you can use this
return (--index);
The way you did it, index was decremented after the return (a "postfix decrement"). You want it to be decremented before it's returned (a "prefix decrement .
Prefix Increment and Decrement Operators | Microsoft Docs[^]
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
