|
Dessert Rose posted:Re: nullable values in C#: That's an awfully verbose way of saying code:
|
#
?
Oct 10, 2013 01:04
|
|
|
|
| # ? May 14, 2024 02:24 |
|
|
We really want to load/reload our comboboxes.code:
|
|
#
?
Oct 10, 2013 01:23
|
|
|
Here's some code I just wrote that I'm ashamed of. The idea is, I have a variadic template that I'm using in a few places. I need to write a function which takes as parameters a number of strings equal to the number of types I'm passing to this variadic template. As near as I can tell, expanding a parameter pack while ignoring its actual expansion is not trivial. C++ code:
|
|
#
?
Oct 10, 2013 01:57
|
|
|
Munkeymon posted:I know? I meant that because of someone's poor choice of reserved character, constructing a URI with an IP6 address that contains a zone identifier is now just that much more annoying because you have to remember to escape the % with %25 so now your Windows zone identifier looks even more like line noise: [url]http://fe80::abcd%251/ This doesn't make sense and the URL is invalid, for IPv6 you must wrap in square brackets: http://[fe80::abcd%1]/ But then you'd be stupid to use link-local URLs as they're unique to each host, the use case is incredibly small to actually put one in a webpage.
|
|
#
?
Oct 10, 2013 02:05
|
|
[/url]
|
ShoulderDaemon posted:Here's some code I just wrote that I'm ashamed of. Trivially better: C++ code:
|
|
#
?
Oct 10, 2013 02:05
|
|
|
Plorkyeran posted:Trivially better: Thanks, my code is now less ugly! Plorkyeran posted:set_dataType_names is a pretty horrifying name. The actual name in the code is newEventType, and it takes a few other parameters; I just wanted to make the usecase in the code sample somewhat more comprehensible.
|
|
#
?
Oct 10, 2013 02:11
|
|
|
Smugdog Millionaire posted:I don't see the problem with the way "nullable" value types were added. Do you have a preferred alternative implementation? one which isn't restricted to value types it's extremely irritating to not be able to have eg Nullable<System.Object>
|
|
#
?
Oct 10, 2013 04:15
|
|
|
Gul Banana posted:one which isn't restricted to value types But that's pointless. System.Object is already nullable. System.Int32 is not.
|
|
#
?
Oct 10, 2013 05:16
|
|
|
pokeyman posted:But that's pointless. System.Object is already nullable. System.Int32 is not. I don't know that it's necessarily pointless, a reference type is, at its core, in some way a (pointer) value type as well, after all, and so you might make the distinction of a valid (non-null) reference to a null object and a null reference value not referring to any object at all  In more seriousness though, it seems like a kind of pointless limitation, though. In, say, Caml there's nothing stopping you from making a foo option option value, for example. Is there a reason for the existence of this limitation?
|
|
#
?
Oct 10, 2013 05:30
|
|
|
PrBacterio posted:I don't know that it's necessarily pointless, a reference type is, at its core, in some way a (pointer) value type as well, after all, and so you might make the distinction of a valid (non-null) reference to a null object and a null reference value not referring to any object at all An unrestricted option type and banning nulls sounds awesome to me. But my impression of C# is that it's designed by people who wouldn't go halfway on that. Plus, I think Nullable joined the language in 2.0? So nulls already existed prior to Nullable, and they needed to make it work.
|
|
#
?
Oct 10, 2013 05:41
|
|
|
pokeyman posted:An unrestricted option type and banning nulls sounds awesome to me. But my impression of C# is that it's designed by people who wouldn't go halfway on that. Plus, I think Nullable joined the language in 2.0? So nulls already existed prior to Nullable, and they needed to make it work.
|
|
#
?
Oct 10, 2013 05:46
|
|
|
essentially I'd like to be able to write this void DoSomething<T>(Nullable<T> optionalParameter) { if(optionalParameter.HasValue) //etc else //etc, able to use .Value on this path //or: optionalParameter.someCombinator //such as GetOrElse, SelectMany.. } no reason that couldn't be unified for ref and value types.
|
|
#
?
Oct 10, 2013 05:58
|
|
|
biznatchio posted:That's an awfully verbose way of saying I've actually never seen this, but thankfully I haven't dealt with too many nullables yet.
|
|
#
?
Oct 10, 2013 06:23
|
|
|
PrBacterio posted:Only I wasn't even talking about banning nulls, there's no reason why you couldn't have an unrestricted option type even in the face of already existing null references is what I was trying to get at, and that they (apparently) explicitly put in this restriction therefore seems strange to me. Having read a bit about the design of C# and who designed it, it doesn't seem strange to me. That's all I'm trying to say  (And it was a lucky guess that Caml doesn't do nulls.)
|
|
#
?
Oct 10, 2013 08:08
|
|
|
biznatchio posted:That's an awfully verbose way of saying Scaevolus posted:"if (x ?? false)" more obviously indicates that you're dealing with a nullable type.
|
|
#
?
Oct 10, 2013 08:10
|
|
|
Eric Lippert, one of the designers of C#, has mentioned on many occasions that he regrets that Nullable<T> can only be applied to value types, as opposed to all types. He has also confirmed that the reason is basically that the features -- i.e. 1. Nullable types and 2. The distinction between reference types and value types -- entered the language in the wrong order. From a theoretical point of view the biggest problem is that it prevents the Nullable<T> type from being truly monadic, since you can't have a Nullable<Nullable<T>>. This series of posts touches on it: http://ericlippert.com/category/monads/
|
|
#
?
Oct 10, 2013 09:49
|
|
|
On a slightly different note, I've said it before but when I first saw that a message to nil in Objective-C does nothing and returns zero I thought it was the dumbest thing ever. Now I realize that's the way all languages should work. 99.9% of the time when some reference is null, I just want to ignore it and/or skip that section of code. It is extremely rare that I want to throw an exception, assert, crash, etc. Yet in most languages, I have to constantly litter my code with if (dicks != null) { dicks.butts(); } If you aren't going to do that, then all references should be non-Nullable unless they are Nullable<T>. At least then I would know.
|
|
#
?
Oct 10, 2013 17:12
|
|
|
Ender.uNF posted:On a slightly different note, I've said it before but when I first saw that a message to nil in Objective-C does nothing and returns zero I thought it was the dumbest thing ever. Now I realize that's the way all languages should work. 99.9% of the time when some reference is null, I just want to ignore it and/or skip that section of code. It is extremely rare that I want to throw an exception, assert, crash, etc. The return value is only *usually* 0. If you call something that returns a struct by value that's larger than a register, the contents of it are undefined!
|
|
#
?
Oct 10, 2013 17:17
|
|
|
That behavior has occasionally bitten me in that my ObjC code merrily continues along without me realizing all those async operations I just fired off were no-ops because my connection was nil. I do agree that in general it makes for cleaner code though. There have been more times then not where I've realized I can remove some guard check because nil will just degrade to the right thing.
|
|
#
?
Oct 10, 2013 17:25
|
|
|
php:<?
while(strstr($field_value,"TABLE.")){
$new_field_value = $new_field ="";
$field_explode = explode(" ",$field_value);
foreach($field_explode as $words){
$new_field = trim($words);
if(strstr($words,"TABLE.")){
$new_field = str_replace("TABLE.","",$new_field);
$buffer_field = $new_field;
$new_field = create_field($new_field,$variations,$library[$new_field],$level,$overwrite_table);
//echo "field: $buffer_field-->$new_field<br>\n";
if(strstr($new_field,"global_dynamic_vars") && isset($global_dynamic_vars[$buffer_field])) {
$new_field = "'".$global_dynamic_vars[$buffer_field]."'";
}
if(empty($new_field)) {
$new_field = "DO NOT DISPLAY";
}
}
if($testing++ > 100000) break;
$new_field_value .= "$new_field ";
}
$field_value =$new_field_value;
}
?>
|
|
#
?
Oct 10, 2013 18:11
|
|
|
MrMoo posted:This doesn't make sense and the URL is invalid, for IPv6 you must wrap in square brackets: Huh, I hadn't seen that before, but I don't see anything in RFC 3986 that would allow for a zone identifier in an IP6 literal unless I'm reading the BNF wrong. E: I guess the URI parser could jsut be written to assume that square brackets means it's an IP literal and therefore some other code's problem, but still. Munkeymon fucked around with this message at 18:54 on Oct 10, 2013 |
|
#
?
Oct 10, 2013 18:50
|
|
|
OK, am I insane for thinking that C include files should include any dependencies in them? For some reason it got into the head of a few programmers here that forcing users to do this: #include "someheaders_dependency.h" #include "someheader.h" is more right than just putting the dependency in in the header, which leads to me chasing down dependencies over the past hour and winding up with a list of 30 or so headers included because I need info about a single struct type that's apparently at the bottom of the dependency tree. They gave me a reason once but I forgot it. Probably because I thought it was total bs, but is there really any valid reason to do this?
|
|
#
?
Oct 10, 2013 20:07
|
|
|
Dessert Rose posted:I mean, all the dirty parts are hidden from me, so I don't really care about the oddities, but it has some leaky bits (like the fact that a nullable type is never truly null) They're null in contexts where it's possible for them to actually be null, i.e. when they get boxed to a reference type: http://dotnetpad.net/ViewPaste/qHZgIkLGOU21OHPOCxDThQ Gul Banana posted:it's extremely irritating to not be able to have eg Nullable<System.Object> This has never irritated me 
|
|
#
?
Oct 10, 2013 20:20
|
|
|
SintaxError posted:OK, am I insane for thinking that C include files should include any dependencies in them? It sounds like total bs to me. I hate it when people write headers that aren't self-contained.
|
|
#
?
Oct 10, 2013 20:35
|
|
|
SintaxError posted:They gave me a reason once but I forgot it. Probably because I thought it was total bs, but is there really any valid reason to do this? There's some coding standards that say you shouldn't use #include in header files to protect yourself against a case where some header file doesn't have the proper include guards in it. But if you are working somewhere that enforces this dumb rule you should quit and go somewhere else.
|
|
#
?
Oct 10, 2013 20:41
|
|
|
SintaxError posted:OK, am I insane for thinking that C include files should include any dependencies in them? It's a yet another dumb thing that was popularized by Rob Pike for a reason that was quasi valid 25 years ago: Rob Pike posted:Simple rule: include files should never include include files. If instead they state (in comments or implicitly) what files they need to have included first, the problem of deciding which files to include is pushed to the user (programmer) but in a way that's easy to handle and that, by construction, avoids multiple inclusions. Multiple inclusions are a bane of systems programming. It's not rare to have files included five or more times to compile a single C source file. The Unix /usr/include/sys stuff is terrible this way.
|
|
#
?
Oct 10, 2013 20:56
|
|
|
Otto Skorzeny posted:It's a yet another dumb thing that was popularized by Rob Pike for a reason that was quasi valid 25 years ago: Lexing? Expensive? Yeah maybe it was in a different time, pretty sure compilers spend most of their time doing optimizations these days. Also, compilers understanding include guards and not needlessly re-reading includes.
|
|
#
?
Oct 10, 2013 21:02
|
|
|
Java code:
|
|
#
?
Oct 10, 2013 21:02
|
|
|
nielsm posted:Lexing? Expensive? Yeah maybe it was in a different time, pretty sure compilers spend most of their time doing optimizations these days. Also, compilers understanding include guards and not needlessly re-reading includes. And yet it's still super slow. I want modules, dammit.
|
|
#
?
Oct 10, 2013 21:30
|
|
|
I present to you a PHP-like EDSL in C++, the future of "fast, robust, secure and easy to scale" web development. Start with lib/core.h and lib/core.cpp. And if you've ever seen MediaWiki skins, this should be pretty familiar (it's somehow worse). I'm definitely buying a commercial license to secure my competitive advantage. 
|
|
#
?
Oct 10, 2013 21:59
|
|
|
One of the main goals of Go was to solve the problem of the C compiler taking forever to parse nested C header includes. I don't support the practice of forcing users to include all header dependencies, I think it's better to write a self contained header with guards and suffer the compilation slowdown, but your code probably compiles faster for the trouble you're enduring.
|
|
#
?
Oct 10, 2013 22:18
|
|
|
Compilers these days can detect when a header has include guards and skip it the second time without having to re-read it.
|
|
#
?
Oct 10, 2013 22:40
|
|
|
LOOK I AM A TURTLE posted:Eric Lippert, one of the designers of C#, has mentioned on many occasions that he regrets that Nullable<T> can only be applied to value types, as opposed to all types. He has also confirmed that the reason is basically that the features -- i.e. 1. Nullable types and 2. The distinction between reference types and value types -- entered the language in the wrong order. From a theoretical point of view the biggest problem is that it prevents the Nullable<T> type from being truly monadic, since you can't have a Nullable<Nullable<T>>. This series of posts touches on it: http://ericlippert.com/category/monads/ Good find, thanks. The money quote is in the second post: Eric Lippert posted:And even this is essentially an accident of history; it just so happened that when C# was first implemented it had always-nullable reference types, non-nullable value types, and no generic types at all. In a counterfactual world where the CLR had generic types from the get-go, it seems plausible that Nullable<T> could have been implemented to work on any type, and reference types would then be non-nullable by default. We could have a type system where Nullable<string> was the only legal way to represent "a string that can be null". Keep this in mind the next time you design a new type system!
|
|
#
?
Oct 10, 2013 22:42
|
|
|
Rothon posted:The return value is only *usually* 0. If you call something that returns a struct by value that's larger than a register, the contents of it are undefined! Isn't that only the case if you're abusing objc_msgSend with a struct return when you should be using objc_msgSend_stret? Also is that still true on arm64?
|
|
#
?
Oct 10, 2013 22:46
|
|
|
Suspicious Dish posted:And yet it's still super slow. I want modules, dammit. Coding horror: Rust lang has modules but it takes even longer to compile. 
|
|
#
?
Oct 11, 2013 14:41
|
|
|
Vanadium posted:Coding horror: Rust lang has modules but it takes even longer to compile. Rust compiler is slow because it is written in Rust which is missing a lot of optimizations. Give it time
|
|
#
?
Oct 11, 2013 14:51
|
|
|
Qwertycoatl posted:Compilers these days can detect when a header has include guards and skip it the second time without having to re-read it. Got any keywords I can use to search about this? Like, is it in the version of gcc I'm stuck on? (4.4.7) Does it need #pragma once?
|
|
#
?
Oct 11, 2013 16:09
|
|
|
So I get this on the skype chat with the team today: $CLIENT accedently deleted all of their servers on their server, Including all of our testing ones. 70+ VM's I should add that $CLIENT is a loving state government. 
|
|
#
?
Oct 11, 2013 16:11
|
|
|
2banks1swap.avi posted:So I get this on the skype chat with the team today:
|
|
#
?
Oct 11, 2013 16:21
|
|
|
|
| # ? May 14, 2024 02:24 |
|
|
Dren posted:Got any keywords I can use to search about this? Like, is it in the version of gcc I'm stuck on? (4.4.7) Does it need #pragma once? Yes and no (Chromium actually found that #pragma once was (trivially but statistically significantly) slower than include guards). It's not a remotely new optimization.
|
|
#
?
Oct 11, 2013 16:26
|
|