## Coding: Fleeting Thoughts

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

Flumble
Yes Man
Posts: 2019
Joined: Sun Aug 05, 2012 9:35 pm UTC

### Re: Coding: Fleeting Thoughts

What if the dialog can't be opened? What if the dialog is forcibly removed or handed over to another program or simply detached from the program?
I'm tellin' ya, there's definitely a scenario for which the boolean won't be a boolean. Based on a total of 4-hours of experience with window toolkits.

commodorejohn
Posts: 1093
Joined: Thu Dec 10, 2009 6:21 pm UTC
Location: Placerville, CA
Contact:

### Re: Coding: Fleeting Thoughts

In which case it would behoove you to, you know, use something other than a Boolean. This is why enums exist.
"'Legacy code' often differs from its suggested alternative by actually working and scaling."
- Bjarne Stroustrup
www.commodorejohn.com - in case you were wondering, which you probably weren't.

ucim
Posts: 6406
Joined: Fri Sep 28, 2012 3:23 pm UTC

### Re: Coding: Fleeting Thoughts

commodorejohn wrote:In which case it would behoove you to, you know, use something other than a Boolean. This is why enums exist.
If I take this as a pattern, then when would I ever use a boolean? The syntactic sugar of
if(result)...
as opposed to
if(result===TRUE)...
would be lost, but otherwise..."result has to be TRUE or FALSE"... is usually best followed by "unless there's a problem"... which all too often is followed by "in which case we pretend it didn't happen and keep going."

Jose
Order of the Sillies, Honoris Causam - bestowed by charlie_grumbles on NP 859 * OTTscar winner: Wordsmith - bestowed by yappobiscuts and the OTT on NP 1832 * Ecclesiastical Calendar of the Order of the Holy Contradiction * Please help addams if you can. She needs all of us.

commodorejohn
Posts: 1093
Joined: Thu Dec 10, 2009 6:21 pm UTC
Location: Placerville, CA
Contact:

### Re: Coding: Fleeting Thoughts

Oh, I don't think so. Certainly there's times where you need to check for "yes/no/error condition" and that's when you should use an enum of some sort, but I'd hardly say that leaves you with no use cases for Boolean variables (unless you're going completely ape with defensive error-checking on every operation, in which case you really ought to stop and rethink your error-handling strategy.)
"'Legacy code' often differs from its suggested alternative by actually working and scaling."
- Bjarne Stroustrup
www.commodorejohn.com - in case you were wondering, which you probably weren't.

ucim
Posts: 6406
Joined: Fri Sep 28, 2012 3:23 pm UTC

### Re: Coding: Fleeting Thoughts

What do I do if my error-handling strategy has a bug?

(besides work for Micorosft?)

Jose
Order of the Sillies, Honoris Causam - bestowed by charlie_grumbles on NP 859 * OTTscar winner: Wordsmith - bestowed by yappobiscuts and the OTT on NP 1832 * Ecclesiastical Calendar of the Order of the Holy Contradiction * Please help addams if you can. She needs all of us.

commodorejohn
Posts: 1093
Joined: Thu Dec 10, 2009 6:21 pm UTC
Location: Placerville, CA
Contact:

### Re: Coding: Fleeting Thoughts

Um, fix it?

(Honestly, I can't tell at this point how far into farce we've gotten. Do you persist in making it "exception handlers all the way down," or do you just reason that if things are that boned then you can't rely on the software at all and it needs to be fixed before being ready for use?)
"'Legacy code' often differs from its suggested alternative by actually working and scaling."
- Bjarne Stroustrup
www.commodorejohn.com - in case you were wondering, which you probably weren't.

ucim
Posts: 6406
Joined: Fri Sep 28, 2012 3:23 pm UTC

### Re: Coding: Fleeting Thoughts

commodorejohn wrote:Honestly, I can't tell at this point how far into farce we've gotten.
It's more that I get suspicious when "what if {this} happens?" garners a response of "that will never happen", but I'm not sure where to stop. If you open a file, you should check to see if the file is actually open before writing to it. If you write to a file, you should check to see that the write was successful before you continue. If you open a jpeg, you should make sure that it's really a jpeg before you open it. If a buffer is allocated, you should check that the buffer actually exists (and is writable) before using it. And so on. Otherwise, you could write to the bit bucket or, release a worm.

If a function is supposed to return a positive integer, do you ensure that it's nonzero before dividing by it? If this division is mission-critical? If you don't have the source code of the function? If the source of the positive integer could be a buffer? If somebody might rewrite the function in the future?

Every error-handling piece of code is a place to introduce more bugs opportunities for unexpected behavior.

So, how paranoid should one be? (see again Flumble's Boolean issue)

Jose
Order of the Sillies, Honoris Causam - bestowed by charlie_grumbles on NP 859 * OTTscar winner: Wordsmith - bestowed by yappobiscuts and the OTT on NP 1832 * Ecclesiastical Calendar of the Order of the Holy Contradiction * Please help addams if you can. She needs all of us.

commodorejohn
Posts: 1093
Joined: Thu Dec 10, 2009 6:21 pm UTC
Location: Placerville, CA
Contact:

### Re: Coding: Fleeting Thoughts

Yeah, but...I mean, you have to stop somewhere, or you'll spend the rest of your life writing nothing but an endless stack of error-handlers. If you can't feel reasonably certain that certain conditions are a given, you should either implement a reasonably comprehensive test to shake out any problems before using that code in production, or maybe just stop using computers for that purpose.
"'Legacy code' often differs from its suggested alternative by actually working and scaling."
- Bjarne Stroustrup
www.commodorejohn.com - in case you were wondering, which you probably weren't.

ucim
Posts: 6406
Joined: Fri Sep 28, 2012 3:23 pm UTC

### Re: Coding: Fleeting Thoughts

I guess "reasonable certainty" is a Boolean.

Jose
Order of the Sillies, Honoris Causam - bestowed by charlie_grumbles on NP 859 * OTTscar winner: Wordsmith - bestowed by yappobiscuts and the OTT on NP 1832 * Ecclesiastical Calendar of the Order of the Holy Contradiction * Please help addams if you can. She needs all of us.

Flumble
Yes Man
Posts: 2019
Joined: Sun Aug 05, 2012 9:35 pm UTC

### Re: Coding: Fleeting Thoughts

It seems (I haven't seen the documentation, but there are no posts confirming that the dialog could do funky things) that in this case the type is simply wrong. When the dialog is closed, a boolean is returned and the control flow is restored —if anything would happen that would make a boolean return value invalid, the routine shouldn't be resumed and either a (documented!) exception should be thrown or the program should just crash with no survivors. So really, the dialog function should return its DialogResult unpacked —a simple 2-value type.

ucim wrote:If a function is supposed to return a positive integer, do you ensure that it's nonzero before dividing by it?

It's too bad that it's basically impossible to guarantee that an integer expression is positive. Or in general to prove properties of a type after some manipulations with run-time values.

Yakk
Poster with most posts but no title.
Posts: 11083
Joined: Sat Jan 27, 2007 7:27 pm UTC
Location: E pur si muove

### Re: Coding: Fleeting Thoughts

In theory, exceptions solve that problem.

Something is so wrong I cannot continue? Throw.

If and only if someone can solve or handle this problem, they catch the exception. If not, program terminates instead of doing nonsense.

However, checked exxeptions lead to insanity, and unchecked exceptions lead to random come-from code (you think goto is bad!). And exceptions get abused as separate return types. Expected acts like pseudo checked exceptions, and nullable is a subset of that...

I almost want a n-d programming language where all code paths are equal in importance...
One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision - BR

Last edited by JHVH on Fri Oct 23, 4004 BCE 6:17 pm, edited 6 times in total.

Flumble
Yes Man
Posts: 2019
Joined: Sun Aug 05, 2012 9:35 pm UTC

### Re: Coding: Fleeting Thoughts

Yakk wrote:However, checked exxeptions lead to insanity, and unchecked exceptions lead to random come-from code (you think goto is bad!).

Hmm, I wonder whether exception inference can solve the symptoms of checked exceptions. If type inference can transform the monstrosity that is Java into C++'s auto/Scala/Haskell, then surely exception inference can hide that complexity.
Every expression is just a monadic function (Right? Am I right?) that returns an exception sum type, while catching an exception is just removing a constructor from the sum type. Or maybe it's late and I'm just blabbering and misusing jargon.

Yakk wrote:I almost want a n-d programming language where all code paths are equal in importance...

Pick any.
But I guess what you really want is a genetic algorithm that produces binaries that will likely do what you want most of the time. The best part of using a GA is that, whenever a generated mail client deletes your whole inbox upon clicking "New Contact", you can punish the GA and generate a new mail client immediately. You don't spend any time on debugging!

Yakk
Poster with most posts but no title.
Posts: 11083
Joined: Sat Jan 27, 2007 7:27 pm UTC
Location: E pur si muove

### Re: Coding: Fleeting Thoughts

No, I mean n dimensional. Instead of linear. Code can flow in many directions at each point.
One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision - BR

Last edited by JHVH on Fri Oct 23, 4004 BCE 6:17 pm, edited 6 times in total.

You, sir, name?
Posts: 6983
Joined: Sun Apr 22, 2007 10:07 am UTC
Location: Chako Paul City
Contact:

### Re: Coding: Fleeting Thoughts

Wouldn't a directed graph be a better model for computational flows (and one it's sort of hard to affix the notion of dimension to)?
I edit my posts a lot and sometimes the words wrong order words appear in sentences get messed up.

EvanED
Posts: 4330
Joined: Mon Aug 07, 2006 6:28 am UTC
Contact:

### Re: Coding: Fleeting Thoughts

Flumble wrote:Hmm, I wonder whether exception inference can solve the symptoms of checked exceptions. If type inference can transform the monstrosity that is Java into C++'s auto/Scala/Haskell, then surely exception inference can hide that complexity.
Every expression is just a monadic function (Right? Am I right?) that returns an exception sum type, while catching an exception is just removing a constructor from the sum type. Or maybe it's late and I'm just blabbering and misusing jargon.
In limited situations this would work, but there are at least two big problems with this in general.

First is that it's a whole-program analysis. To figure out what exceptions a function can throw, you need to see the source of that function and the source of all functions it could transitively call. This means that a C++ compiler couldn't reason about it in the compiler itself, and would need to defer anything until link time. It means that something like a code editor can't examine a source file in isolation. You might not even have the complete program -- what if you have binary-only libraries, or use a shared-library that could change?

Second is indirect calls. To do this, you need to know what functions can be transitively called. But what functions are that if you have indirect calls? (I.e. calls through function pointers, virtual calls, etc.) Indirect call resolution is a difficult in many situations; in some, it's basically impossible. (In some, it actually is impossible; you might not even have the entire class hierarchy for example because of shared libraries!)

You can probably do pretty good, but it's far from clear that you could do well enough for it to be helpful for realistic programs.

Xenomortis
Not actually a special flower.
Posts: 1420
Joined: Thu Oct 11, 2012 8:47 am UTC

### Re: Coding: Fleeting Thoughts

Git (noun):
A tool for partially ordering text transformations, where the change you made yesterday comes after the change you made today.

ahammel
My Little Cabbage
Posts: 2135
Joined: Mon Jan 30, 2012 12:46 am UTC
Location: Vancouver BC
Contact:

### Re: Coding: Fleeting Thoughts

Speaking of how Java is terrible, Kotlin looks pretty promising if it lives up to the marketing hype.
He/Him/His/Alex
God damn these electric sex pants!

Xeio
Friends, Faidites, Countrymen
Posts: 5097
Joined: Wed Jul 25, 2007 11:12 am UTC
Location: C:\Users\Xeio\
Contact:

### Re: Coding: Fleeting Thoughts

I can't decide if I have a deep misuderstanding of how web requests work, or if this request can never work.

Like, the only way I could see it working is if "base" points to a path on the server... right? Which makes it sort of useless, for, you know, uploading data to a server. Passing a local file path to a web server isn't actually going to magically upload data from the local machine... right? I haven't gone mad, have I?

You, sir, name?
Posts: 6983
Joined: Sun Apr 22, 2007 10:07 am UTC
Location: Chako Paul City
Contact:

### Re: Coding: Fleeting Thoughts

Well, it's a POST request, right? They can have files as part of the request's form data.

Any support for file uploads in any web API I've encountered has been driven by an onion of terrible hacks. I'd be surprised to find this API was any different.
I edit my posts a lot and sometimes the words wrong order words appear in sentences get messed up.

Xeio
Friends, Faidites, Countrymen
Posts: 5097
Joined: Wed Jul 25, 2007 11:12 am UTC
Location: C:\Users\Xeio\
Contact:

### Re: Coding: Fleeting Thoughts

Ok, sure, maybe if they had that documented somewhere I would totally believe that.

But even if I assume it's undocumented, then why is the parameter for file path even there? The path doesn't mean anything in the application, once the file is uploaded I don't/can't know where it lives (it's abstracted away, probably in a database or something, who knows).

It's doubly suspicious that the CLI command takes the same parameters, because I've used the CLI version and it uploads fine where base=local path.

Flumble
Yes Man
Posts: 2019
Joined: Sun Aug 05, 2012 9:35 pm UTC

### Re: Coding: Fleeting Thoughts

ahammel wrote:Speaking of how Java is terrible, Kotlin looks pretty promising if it lives up to the marketing hype.

Judging by its comparison to Scala, it would've been better if the kotlin organization had invested their efforts in Scala.

EvanED wrote:First is that it's a whole-program analysis. To figure out what exceptions a function can throw, you need to see the source of that function and the source of all functions it could transitively call. This means that a C++ compiler couldn't reason about it in the compiler itself, and would need to defer anything until link time. It means that something like a code editor can't examine a source file in isolation. You might not even have the complete program -- what if you have binary-only libraries, or use a shared-library that could change?

Second is indirect calls. To do this, you need to know what functions can be transitively called. But what functions are that if you have indirect calls? (I.e. calls through function pointers, virtual calls, etc.) Indirect call resolution is a difficult in many situations; in some, it's basically impossible. (In some, it actually is impossible; you might not even have the entire class hierarchy for example because of shared libraries!)

You can probably do pretty good, but it's far from clear that you could do well enough for it to be helpful for realistic programs.

When linking to a compiled entity, you already need to find out or specificy its type, no? When adding exception inference to a language, the exception type will just have to be specified alongside the normal type. Or when it isn't, it must get the most generic exception type.
Regarding indirect calls or other stuff that isn't nicely typed: let's refrain from trying to add exception inference in such languages.

Ooh look, Haskell has a library for exceptions.

Xeio
Friends, Faidites, Countrymen
Posts: 5097
Joined: Wed Jul 25, 2007 11:12 am UTC
Location: C:\Users\Xeio\
Contact:

### Re: Coding: Fleeting Thoughts

I did think of one scenario for the upload... maybe they're assuming access to a file share or something.

Doesn't work for what I need if that's the case though since I don't have a network share to use that's accessible by the server, oh well.

korona
Posts: 495
Joined: Sun Jul 04, 2010 8:40 pm UTC

### Re: Coding: Fleeting Thoughts

Xenomortis wrote:Git (noun):
A tool for partially ordering text transformations, where the change you made yesterday comes after the change you made today.

make: The GNU utility for topological sorting.

Posts: 3072
Joined: Mon Oct 22, 2007 5:28 pm UTC
Location: Beaming you up

### Re: Coding: Fleeting Thoughts

Flumble wrote:
ahammel wrote:Speaking of how Java is terrible, Kotlin looks pretty promising if it lives up to the marketing hype.

Judging by its comparison to Scala, it would've been better if the kotlin organization had invested their efforts in Scala. :?

When linking to a compiled entity, you already need to find out or specificy its type, no? When adding exception inference to a language, the exception type will just have to be specified alongside the normal type. Or when it isn't, it must get the most generic exception type.
Regarding indirect calls or other stuff that isn't nicely typed: let's refrain from trying to add exception inference in such languages.

Ooh look, Haskell has a library for exceptions.

You might like extensible-effects which is much like what you describe. The association between types and the exceptions they can encode is done via the Member type class. You can have an instance like IO which admits any exception type, or on the other end Maybe which only admits Exc (). If you use an invalid exception, instance resolution prevents compilation.

In particular, take a look at runExc which takes an exceptional action and yields an action with that exception matched out.
<quintopia> You're not crazy. you're the goddamn headprogrammingspock!
<Cheese> I love you

EvanED
Posts: 4330
Joined: Mon Aug 07, 2006 6:28 am UTC
Contact:

### Re: Coding: Fleeting Thoughts

Flumble wrote:When linking to a compiled entity, you already need to find out or specificy its type, no? When adding exception inference to a language, the exception type will just have to be specified alongside the normal type.
If you have to "specify" it, then it's not inferred.

Or when it isn't, it must get the most generic exception type.
Or if you do this, then I suspect it ceases to be useful.

Regarding indirect calls or other stuff that isn't nicely typed: let's refrain from trying to add exception inference in such languages.
I'm... actually not sure I can name any production language that doesn't have indirect calls. Does Pascal? Ada?

ahammel
My Little Cabbage
Posts: 2135
Joined: Mon Jan 30, 2012 12:46 am UTC
Location: Vancouver BC
Contact:

### Re: Coding: Fleeting Thoughts

Flumble wrote:
ahammel wrote:Speaking of how Java is terrible, Kotlin looks pretty promising if it lives up to the marketing hype.

Judging by its comparison to Scala, it would've been better if the kotlin organization had invested their efforts in Scala.

The killer feature of Kotlin for me is the interop story. Presumably they felt that it couldn't be kluged on to Scala.

They were also pretty unhappy with Scala's compile times, I believe.
He/Him/His/Alex
God damn these electric sex pants!

DaveInsurgent
Posts: 207
Joined: Thu May 19, 2011 4:28 pm UTC
Location: Waterloo, Ontario

### Re: Coding: Fleeting Thoughts

Xeio wrote:Ok, sure, maybe if they had that documented somewhere I would totally believe that.

But even if I assume it's undocumented, then why is the parameter for file path even there? The path doesn't mean anything in the application, once the file is uploaded I don't/can't know where it lives (it's abstracted away, probably in a database or something, who knows).

It's doubly suspicious that the CLI command takes the same parameters, because I've used the CLI version and it uploads fine where base=local path.

Is there any chance they're running a process locally on the requesting machine, so that requests to the "server" really just result in one-or-more transformed requests back to the originating machine (i.e "get me these files from /c/foo")

Flumble
Yes Man
Posts: 2019
Joined: Sun Aug 05, 2012 9:35 pm UTC

### Re: Coding: Fleeting Thoughts

You can safely disregard this post. I've gone with option 5.
[/edit]

Hmm, I have a stochastic DP with approximately 10^9 states and some 10^2 transitions per state. What would be the recommended course of action?
• Battle with Haskell to teach it to memoize subproblem results
• Battle with Java/Python/C to get it to correctly address the state space and to keep the code somewhat intelligible
• Battle with OpenCL (there is no specific hardness to opencl, everything is hard)
• Use a language that is designed for stochastic programming (which?)
• Give up
• Simplify the SDP if possible

FYI, the function currently looks like this (for some decision set D, cost function C_n, distributions X_n and Y_n, constant e):
f_n(a,b,c) = max_{d \in D} \sum_x \sum_y P(X_n=x) P(Y_n=y) [C_n + f_{n+1}(a+x,b+x-d,c+y+d-e)]
Actually, my goal is to calculate one decision d given an n and a (regardless of b and c), but I don't know how to get that value without destroying the state information b and c.
Last edited by Flumble on Thu Jun 30, 2016 2:47 pm UTC, edited 1 time in total.

Wildcard
Candlestick!
Posts: 253
Joined: Wed Jul 02, 2008 12:42 am UTC
Location: Outside of the box

### Re: Coding: Fleeting Thoughts

David Conrad wrote:It's perfectly safe to write PHP if you're an expert and know how to avoid all the foot guns in the same way it's perfectly safe to walk in a minefield if you know where to put your feet.

I enjoyed this quote.
There's no such thing as a funny sig.

Xeio
Friends, Faidites, Countrymen
Posts: 5097
Joined: Wed Jul 25, 2007 11:12 am UTC
Location: C:\Users\Xeio\
Contact:

### Re: Coding: Fleeting Thoughts

DaveInsurgent wrote:Is there any chance they're running a process locally on the requesting machine, so that requests to the "server" really just result in one-or-more transformed requests back to the originating machine (i.e "get me these files from /c/foo")
Nope. There are some features they have related to file uploads which would require an install of a service, but this API isn't one of them as far as I know (most of those features are automated once configured as well, such as auto-pickup from a drop directory).

EvanED
Posts: 4330
Joined: Mon Aug 07, 2006 6:28 am UTC
Contact:

### Re: Coding: Fleeting Thoughts

How terrible is this?

Code: Select all

struct Something{    set<int> stuff;    int representative;        Something(set<int> const & s)        : stuff((assert(!s.empty()), s))        , representative(*s.begin())    {}};
?

Would it be worth it to write something like:

Code: Select all

template <typename Container>Container const &ident_if_nonempty(Container const & c) {    assert(!c.empty());    return c;}struct Something{    set<int> stuff;    int representative;        Something(set<int> const & s)        : stuff(ident_if_non_empty(s))        , representative(*s.begin())    {}};
?

(Maybe since I just wrote it, I should just use it... but still. Also, don't say "why aren't you using forwarding references" or I'll be sad. Also that wouldn't materially effect my answer. Also, I'm don't know if standard assert can be used as an expression; we have our own assert that can, so that also isn't relevant.)

Edit:, oh looks like s can be empty anyway. Go me. Still, I guess I'll leave this because I'm curious what people think.

Yakk
Poster with most posts but no title.
Posts: 11083
Joined: Sat Jan 27, 2007 7:27 pm UTC
Location: E pur si muove

### Re: Coding: Fleeting Thoughts

First, take set by value.

Second, mustbe_nonempty(sts::move(s), 0), which checks, asserts and populates. The branch to toss the zero in is less likely crash than dereferencing an empty set's begin. Or better, throw if empty. Or better, make code robust against empty.
One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision - BR

Last edited by JHVH on Fri Oct 23, 4004 BCE 6:17 pm, edited 6 times in total.

Tub
Posts: 382
Joined: Wed Jul 27, 2011 3:13 pm UTC

### Re: Coding: Fleeting Thoughts

I don't know why you're adding the check to the initialization of stuff. stuff can be empty without problems. The representative is the problem. Unless some information was lost in simplification/anonymization of the code, that's where the check belongs.

So either

Code: Select all

[...]   Something(set<int> const & s)        : stuff(s)        , representative((assert(!s.empty()), *s.begin()))    {}[...]

or

Code: Select all

template <typename Container>Container::value_type get_representative(Container const & c) {    assert(!c.empty());    return *c.begin();}[...]    Something(set<int> const & s)        : stuff(s)        , representative(get_representative(s))    {}

I'm not particularly fond of the construct of (assert(..), expression), because it's nontrivial to parse or understand. Also, because I'd have to dig into the standard or headers to figure out if it'll still compile with NDEBUG set. Also, because it seems like you really want to throw an exception instead of an assertion, unless you can guarantee that Something will not be initialized with user data. Still, you gain nothing from using an assert over an exception - after all, if this was performance critical that you need to remove the check from production code, why aren't you using forward references?

Xeio
Friends, Faidites, Countrymen
Posts: 5097
Joined: Wed Jul 25, 2007 11:12 am UTC
Location: C:\Users\Xeio\
Contact:

### Re: Coding: Fleeting Thoughts

On the one hand, await is amazing, on the other hand writing stuff like this I'm not sure if I'm "Doing it right". Especially recursive awaiting to build a tree seems... I dunno, weird and probably not optimal.

Code: Select all

var resources = await DownloadData<List<Resource>>(relativeUrl);//GetResourcesTree is the recursive callvar childRequests = resources.Select(resource => new {Resource = resource, Task = GetResourcesTree(resource.Id)}).ToList();            await Task.WhenAll(childRequests.Select(c => c.Task));foreach (var childRequest in childRequests){    childRequest.Resource.ChildResources.AddRange(childRequest.Task.Result);}

On the other hand, I get asynchronous UI code without extra work in the UI portion...

EvanED
Posts: 4330
Joined: Mon Aug 07, 2006 6:28 am UTC
Contact:

### Re: Coding: Fleeting Thoughts

Tub wrote:I don't know why you're adding the check to the initialization of stuff. stuff can be empty without problems. The representative is the problem. Unless some information was lost in simplification/anonymization of the code, that's where the check belongs.
It's interesting you say that; when I was originally writing it, I first put it on the representative but decided I wanted it on stuff instead. My thinking was the following. The constraint is that stuff is non-empty. And just because the reason for that is that we need a representative, that's still a constraint on stuff. And potentially that constraint would still be meaningful even we didn't have representative, if we wanted to guarantee that stuff was non-empty for other reasons (or even if we expected everything coming in to be non-empty.)

I still stand by that reasoning as being reasonable and a decent enough reason to put the constraint there; but that said, the fact your get_representative function is much more natural than my ident_if_nonempty function I think clearly speaks for that solution. (Actually I'm a bit surprised I didn't think of that; I feel like I've written that function before.)

Tub wrote:I'm not particularly fond of the construct of (assert(..), expression), because it's nontrivial to parse or understand. Also, because I'd have to dig into the standard or headers to figure out if it'll still compile with NDEBUG set.
The readability was what I was mostly concerned about. I agree it's funky. The comment about NDEBUG I'm not so swayed by; I don't think that's something that readers need to be concerned with much. If it's there, presumably it complies, so you don't need to spend cycles figuring that out. (That's not 100% true of course... but it's probably true.) That'd be mostly true for the writer, and I happened to know without looking up that our version of assert can be used in an expression context in both settings. (It expands to 0, or maybe (void)0, with NDEBUG.)

Also, because it seems like you really want to throw an exception instead of an assertion, unless you can guarantee that Something will not be initialized with user data. Still, you gain nothing from using an assert over an exception - after all, if this was performance critical that you need to remove the check from production code, why aren't you using forward references?
So first, no user input would reach this; an assertion really is appropriate here. As for why no exception anyway, first, I'm unconvinced that throwing instead of asserting is particularly meaningful. Assertions are supposed to indicate "wow something's buggered up here!", and it's usually hard to recover from something like that. Second, -fno-exceptions (and, re. forwarding references, an implicit -std=c++03), make Evan a sad panda.

Xanthir
My HERO!!!
Posts: 5311
Joined: Tue Feb 20, 2007 12:49 am UTC
Contact:

### Re: Coding: Fleeting Thoughts

Xeio wrote:On the one hand, await is amazing, on the other hand writing stuff like this I'm not sure if I'm "Doing it right". Especially recursive awaiting to build a tree seems... I dunno, weird and probably not optimal.

There's nothing wrong with recursively awaiting in principle, but often it'll be the wrong thing to do. Is the information at each level really dependent on the previous computation being finished before it can start? If not, you should refactor to get the skeleton together synchronously, then await all the Tasks together.

I can't tell from your snippet whether this is the case; it depends on whether getting the child resources depends on whatever is async about getting the parent resource.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

Yakk
Poster with most posts but no title.
Posts: 11083
Joined: Sat Jan 27, 2007 7:27 pm UTC
Location: E pur si muove

### Re: Coding: Fleeting Thoughts

Evan, if you are asserting you do not dereference null, in release you may as well shut down cleanly with exit or throw instead of barging on (or explicitly stack dump before exit), barring situatins where the null check is too expensive (which is rare but does exist).
One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision - BR

Last edited by JHVH on Fri Oct 23, 4004 BCE 6:17 pm, edited 6 times in total.

korona
Posts: 495
Joined: Sun Jul 04, 2010 8:40 pm UTC

### Re: Coding: Fleeting Thoughts

FT: Is throwing from a signal handler allowed in C++?

Context: I have a program that may page fault sometimes (and is able to handle those faults gracefully). I can check if that will happen before I access memory but that is just a (non-negligible) waste of time in 99.999% of all cases. It would be much faster to just take the segfault, throw from it and catch the exception. I also control the standard library so "library function foo is not async-signal-safe" is not a problem here because I can just make them signal safe.

Xanthir
My HERO!!!
Posts: 5311
Joined: Tue Feb 20, 2007 12:49 am UTC
Contact:

### Re: Coding: Fleeting Thoughts

I'm nowhere near experienced in this kind of thing, but I think that systems tend to have a double-fault handler, and even a triple-fault (which is usually just a system crash, as your double-fault handler should *not* be faulting).
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

ahammel
My Little Cabbage
Posts: 2135
Joined: Mon Jan 30, 2012 12:46 am UTC
Location: Vancouver BC
Contact:

### Re: Coding: Fleeting Thoughts

Hmm, this linter requires a nightly build of Rust. Guess I'll just build one from source.

*14 hours pass*

Fuckin' netbooks.
He/Him/His/Alex
God damn these electric sex pants!