Coding: Fleeting Thoughts

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

Moderators: phlip, Moderators General, Prelates

Triple Log
Posts: 33
Joined: Thu Jul 17, 2014 5:32 pm UTC

Re: Coding: Fleeting Thoughts

Postby Triple Log » Sun Jul 20, 2014 10:29 pm UTC

Xenomortis wrote:
Triple Log wrote:I like physics, math, and literature too. All things that take a lifetime to master.

Don't worry, and take your time; you've got a lifetime of it!

But only one.
Maybe 50 or 60 years from today. To master four topics with massive depth and breadth.

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

Re: Coding: Fleeting Thoughts

Postby Xenomortis » Sun Jul 20, 2014 10:53 pm UTC

If it takes 10 years to gain mastery of a field, you've got time to spare!
Image

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

Re: Coding: Fleeting Thoughts

Postby Yakk » Mon Jul 21, 2014 12:24 am UTC

Of programming, physics, math and literature, one of them will give you a good income even if you reach journeyman proficiency at this 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.

User avatar
Thesh
Made to Fuck Dinosaurs
Posts: 6598
Joined: Tue Jan 12, 2010 1:55 am UTC
Location: Colorado

Re: Coding: Fleeting Thoughts

Postby Thesh » Mon Jul 21, 2014 12:37 am UTC

If you don't sleep, you can master those topics in half the time... Assuming sleep deprivation doesn't hurt your ability to learn, and as someogre wjio hasntrt slpet in tew daujs i cna say it hadg affevtrd me.
Summum ius, summa iniuria.

Triple Log
Posts: 33
Joined: Thu Jul 17, 2014 5:32 pm UTC

Re: Coding: Fleeting Thoughts

Postby Triple Log » Mon Jul 21, 2014 1:00 am UTC

Thesh wrote:If you don't sleep, you can master those topics in half the time... Assuming sleep deprivation doesn't hurt your ability to learn, and as someogre wjio hasntrt slpet in tew daujs i cna say it hadg affevtrd me.

That looks like about 3 days of deprivation to me.
Going for the world record? You do realize the Guinness doesn't keep the sleep deprivation record anymore, right...

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

Re: Coding: Fleeting Thoughts

Postby Xenomortis » Mon Jul 21, 2014 3:41 pm UTC

I have spent far too long synchronising my .vimrc's and plugins across the different machines I use...
At least the merging part is done now; should be easier to maintain consistency now.
Image

Triple Log
Posts: 33
Joined: Thu Jul 17, 2014 5:32 pm UTC

Re: Coding: Fleeting Thoughts

Postby Triple Log » Mon Jul 21, 2014 5:52 pm UTC

Xenomortis wrote:I have spent far too long synchronising my .vimrc's and plugins across the different machines I use...
At least the merging part is done now; should be easier to maintain consistency now.

Did you do it manually? Script? Through Git(hub)?

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

Re: Coding: Fleeting Thoughts

Postby Xenomortis » Mon Jul 21, 2014 6:39 pm UTC

Github.
When I started using vim a few months ago, I copied my vimrc between work and home, but keeping track of plugins and remembering to do keep them up to date with each other got difficult.
Add in two laptops that also need to be synced up and... well yeah.

A couple of days later, three extra SSH keys tied to my account (two of which are purely for this purpose*), and some fiddling around at work and it's good enough.
But three distinct operating systems and three/four distinct environments? It's not perfect.


*This is actually another thing I've been wondering about.
At work, we use github for the open-source parts of our codebase. A number of people have linked their github accounts with their work emails.
I'm not sure I want to...
Image

letterX
Posts: 535
Joined: Fri Feb 22, 2008 4:00 am UTC
Location: Ithaca, NY

Re: Coding: Fleeting Thoughts

Postby letterX » Tue Jul 22, 2014 1:36 am UTC

For keeping packages synchronized between machines, have you considered Vundle? That should reduce your problem to keep your .vimrc synchronized between machines (since packages then are specified in your .vimrc with vundle). I haven't actually tried using it across machines, but I do use it for packages on my main development computer.

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

Re: Coding: Fleeting Thoughts

Postby Xenomortis » Tue Jul 22, 2014 8:55 am UTC

I went with pathogen and git submodules; didn't use a package manager originally so that's why I had to track down which packages I use across the different machines.

(And it turns out that xterm on my Debian laptop is better with colour schemes in terminal vim than the RedHat desktop at work...).
Image

User avatar
rath358
The bone of my bone
Posts: 945
Joined: Wed Jan 14, 2009 6:02 am UTC
Location: west Camberville

Re: Coding: Fleeting Thoughts

Postby rath358 » Wed Jul 23, 2014 2:32 pm UTC

In c++, you have the STL vector and list classes to provide extra functionality and safety and shit above the base array class.
I am just learning c#. This page lists a bunch of classes, but I don't see any advanced containers. Is there a standard library with such containers to use? Or is it standard practice to just code your own or something?
Also, is there a preferred reference site that is more readable and friendly than the msdn site? (like cplusplus.com, but for c#)

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

Re: Coding: Fleeting Thoughts

Postby Xenomortis » Wed Jul 23, 2014 2:34 pm UTC

In C#, basic arrays are bounds checked - an exception will be thrown if you try to access an element past the end of the array.
For dynamic containers (that you can change the size of), there's ArrayList and the generic List<T>.
Image

User avatar
rath358
The bone of my bone
Posts: 945
Joined: Wed Jan 14, 2009 6:02 am UTC
Location: west Camberville

Re: Coding: Fleeting Thoughts

Postby rath358 » Wed Jul 23, 2014 2:40 pm UTC

ohh, the things I want are under System.Collections, not System. Thanks!

speising
Posts: 2365
Joined: Mon Sep 03, 2012 4:54 pm UTC
Location: wien

Re: Coding: Fleeting Thoughts

Postby speising » Wed Jul 23, 2014 2:54 pm UTC

or rather, System.Collections.Generic. the untyped collections under System.Collections are not really recommended anymore.

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Coding: Fleeting Thoughts

Postby EvanED » Wed Jul 23, 2014 3:03 pm UTC

Wow... this is an insidious typo...

Code: Select all

>>> x = [
...     1,
...     2,
... ],
>>> x
([1, 2],)


Edit: "local delete, incoming delete upon merge"

Yes Subversion, that's a really big and important conflict you found. You must be very proud of yourself.

User avatar
Aaeriele
Posts: 2127
Joined: Tue Feb 23, 2010 3:30 am UTC
Location: San Francisco, CA

Re: Coding: Fleeting Thoughts

Postby Aaeriele » Thu Jul 24, 2014 5:53 am UTC

Xenomortis wrote:I went with pathogen and git submodules


This is my preferred solution as well.
Vaniver wrote:Harvard is a hedge fund that runs the most prestigious dating agency in the world, and incidentally employs famous scientists to do research.

afuzzyduck wrote:ITS MEANT TO BE FLUTTERSHY BUT I JUST SEE AAERIELE! CURSE YOU FORA!

troyp
Posts: 557
Joined: Thu May 22, 2008 9:20 pm UTC
Location: Lismore, NSW

Re: Coding: Fleeting Thoughts

Postby troyp » Thu Jul 24, 2014 7:06 am UTC

EvanED wrote:Wow... this is an insidious typo...

Code: Select all

>>> x = [
...     1,
...     2,
... ],
>>> x
([1, 2],)

That's the price of having destructuring binds look like beautiful multiple assignments, I guess. :-)

(Although they could always make parens mandatory for a 1-element tuple.)

User avatar
mosgi
Posts: 46
Joined: Thu Jul 17, 2014 8:19 pm UTC
Location: Somewhere in your past light cone

Re: Coding: Fleeting Thoughts

Postby mosgi » Thu Jul 24, 2014 9:02 pm UTC

FT: GPUs have really weird instruction sets. But damn are they fast!

The context for this is what I'm doing for my internship at the moment: translating a (reasonably small, but nontrivial) algorithm from Python into something which can actually run in mostly-real-time.

Other FT: I kinda want to write something for the IOCCC, but I'm not sure whether that will be seen as a good thing or a bad thing.
(they pronouns please)

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

Re: Coding: Fleeting Thoughts

Postby Xeio » Sun Jul 27, 2014 7:11 am UTC

It's weird that the first one won't compile but the second one will.

Code: Select all

dynamic foo = (string s) => s + "foo";

Code: Select all

dynamic foo = (Func<string, string>)((string s) => s + "foo");
Why do I need to cast lambda (or a method) to a delegate type before it can be assigned to a dynamic...?

User avatar
chridd
Has a vermicelli title
Posts: 846
Joined: Tue Aug 19, 2008 10:07 am UTC
Location: ...Earth, I guess?
Contact:

Re: Coding: Fleeting Thoughts

Postby chridd » Sun Jul 27, 2014 7:40 am UTC

Xeio wrote:It's weird that the first one won't compile but the second one will.

Code: Select all

dynamic foo = (string s) => s + "foo";

Code: Select all

dynamic foo = (Func<string, string>)((string s) => s + "foo");
Why do I need to cast lambda (or a method) to a delegate type before it can be assigned to a dynamic...?
http://msdn.microsoft.com/en-us/library/bb397687.aspx wrote:A lambda expression is an anonymous function that you can use to create delegates or expression tree types.
I'd guess that's because otherwise it doesn't know whether to create a delegate or an expression tree. Also, it looks like delegates with the same signature can have different runtime types—the end of http://msdn.microsoft.com/en-us/library/ms173172.aspx shows "delegate void Delegate1()" and "delegate void Delegate2()" as being different types at runtime (I don't know why they did it that way), so it would need to know which type to use.
~ chri d. d. /tʃɹɪ.di.di/ (Phonotactics, schmphonotactics) · she · Forum game scores
mittfh wrote:I wish this post was very quotable...

User avatar
Jplus
Posts: 1721
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: Coding: Fleeting Thoughts

Postby Jplus » Sun Jul 27, 2014 8:22 am UTC

Is this one of those cases where the compiler is just not trying hard enough to figure out what it should do? More precisely, can a dynamic be assigned only with a delegate or also with an expression tree?

This is my pet peeve from C++:

Code: Select all

class youcantcopyme {
public:
    youcantcopyme (const youcantcopyme &) = delete;
}

class buticanconstructwithyou {
public:
    buticanconstructwithyou (const youcantcopyme &) { /* ... */ }
}

int main ( ) {
    auto foo = youcantcopyme();
    auto bar = foo;  // ERROR, youcantcopyme is noncopyable
}

Argh. Even though there is exactly one type-checking signature for the expression "auto bar = foo;", the C++ standard forbids compilers to correctly deduce it.
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

User avatar
chridd
Has a vermicelli title
Posts: 846
Joined: Tue Aug 19, 2008 10:07 am UTC
Location: ...Earth, I guess?
Contact:

Re: Coding: Fleeting Thoughts

Postby chridd » Sun Jul 27, 2014 9:19 am UTC

Jplus wrote:Is this one of those cases where the compiler is just not trying hard enough to figure out what it should do? More precisely, can a dynamic be assigned only with a delegate or also with an expression tree?
(Note: I don't actually know C#, nor do I have a C# compiler to test stuff; this is just my attempt at understanding what I read on MSDN.)
Dynamic can hold anything; thus it could hold a delegate and it could hold an expression tree. (Or maybe it can just hold object types, but it looks like those are both object types.) It looks like the meaning of a lambda expression depends on the type of the variable it's being assigned to, and since a dynamic variable could hold any type, it doesn't know what sort of object to create.
(I would also assume that there isn't any automatic conversion among the possible types, so if the compiler chose the wrong type, there would be a runtime error. I don't know that for sure, though.)
~ chri d. d. /tʃɹɪ.di.di/ (Phonotactics, schmphonotactics) · she · Forum game scores
mittfh wrote:I wish this post was very quotable...

Breakfast
Posts: 117
Joined: Tue Jun 16, 2009 7:34 pm UTC
Location: Coming to a table near you

Re: Coding: Fleeting Thoughts

Postby Breakfast » Sun Jul 27, 2014 12:17 pm UTC

Xeio wrote:It's weird that the first one won't compile but the second one will.

Code: Select all

dynamic foo = (string s) => s + "foo";

Code: Select all

dynamic foo = (Func<string, string>)((string s) => s + "foo");
Why do I need to cast lambda (or a method) to a delegate type before it can be assigned to a dynamic...?


I'll give a definitive yes to what other people are saying. Under the covers dynamic is implemented as an object type with an attribute marking it as dynamic for the DLR. In the first expression the compiler can't figure out what you're trying to do but the second one makes it clear. You can actually use this technique with a dictionary of type <string, dynamic> to make something like a poor man's ExpandoObject or Bag (if C# didn't already have ExpandoObjects).

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

Re: Coding: Fleeting Thoughts

Postby Xeio » Sun Jul 27, 2014 3:20 pm UTC

chridd wrote:I'd guess that's because otherwise it doesn't know whether to create a delegate or an expression tree. Also, it looks like delegates with the same signature can have different runtime types—the end of http://msdn.microsoft.com/en-us/library/ms173172.aspx shows "delegate void Delegate1()" and "delegate void Delegate2()" as being different types at runtime (I don't know why they did it that way), so it would need to know which type to use.

It doesn't appear to be restricted to lambdas. I get a similarly vague (but different) error for the line

Code: Select all

dynamic baz = Method;
//But this works fine
dynamic bez = (Func<string, string>)Method;

Error for the lambda:
"Cannot convert lambda expression to type 'dynamic' because it is not a delegate type"
Error for the method:
"Cannot convert method group 'Method' to non-delegate type 'dynamic'.

EDIT: By the way, if you curious why I was thinking about this at all.

I thought I knew the solution, but couldn't get it to compile. Turns out the submitted solution is done (roughly) the same way as I was thinking but with the casts so it will compile.

User avatar
chridd
Has a vermicelli title
Posts: 846
Joined: Tue Aug 19, 2008 10:07 am UTC
Location: ...Earth, I guess?
Contact:

Re: Coding: Fleeting Thoughts

Postby chridd » Sun Jul 27, 2014 5:42 pm UTC

Xeio wrote:
chridd wrote:I'd guess that's because otherwise it doesn't know whether to create a delegate or an expression tree. Also, it looks like delegates with the same signature can have different runtime types—the end of http://msdn.microsoft.com/en-us/library/ms173172.aspx shows "delegate void Delegate1()" and "delegate void Delegate2()" as being different types at runtime (I don't know why they did it that way), so it would need to know which type to use.

It doesn't appear to be restricted to lambdas. I get a similarly vague (but different) error for the line

Code: Select all

dynamic baz = Method;
//But this works fine
dynamic bez = (Func<string, string>)Method;

Error for the lambda:
"Cannot convert lambda expression to type 'dynamic' because it is not a delegate type"
Error for the method:
"Cannot convert method group 'Method' to non-delegate type 'dynamic'.
Like I said, it looks like there can be different delegate types that are distinct at runtime but have the same signature, so it wouldn't know which type to use. (I don't know why; if I were designing the language, this wouldn't be the case.)

Does something like this give a runtime error if foo is called (assuming I got the syntax right)?

Code: Select all

delegate void D1();
delegate void D2();
static void m() {}
static void foo() {
    dynamic d1 = (D1)m;
    D2 d2 = d1;
}
~ chri d. d. /tʃɹɪ.di.di/ (Phonotactics, schmphonotactics) · she · Forum game scores
mittfh wrote:I wish this post was very quotable...

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Coding: Fleeting Thoughts

Postby EvanED » Sun Jul 27, 2014 8:34 pm UTC

Jplus wrote:This is my pet peeve from C++:
To be honest, I'd be surprised if it worked the way you want it to work. I would expect auto x = e; to result in x having the same type as e, and an error if it can't.

IMO, if you want a good example of where the language rules enforce compiler stupidity, the example to point to is typename.

Great Justice
Posts: 54
Joined: Sun Aug 15, 2010 5:28 am UTC

Re: Coding: Fleeting Thoughts

Postby Great Justice » Sun Jul 27, 2014 8:53 pm UTC

Yes, I'd say they made the right call. Imagine seeing that line in real code instead of a ten line example.
It's not that the compiler couldn't work it out, but that the reader has to have detailed knowlage of both classes. At least one side should be explicit.
Type inference is nice for writing, but can be abused and reduce readability.
It usually isn't Congress or the State that tries to abridge free expression or free speech, [...] actually, in the present situation, the main threat to expression comes from public opinion.
~Christopher Hitchens

User avatar
Jplus
Posts: 1721
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: Coding: Fleeting Thoughts

Postby Jplus » Sun Jul 27, 2014 9:04 pm UTC

EvanED wrote:
Jplus wrote:This is my pet peeve from C++:
To be honest, I'd be surprised if it worked the way you want it to work. I would expect auto x = e; to result in x having the same type as e, and an error if it can't.

I see your point. It's a big loss though; if it were the way I want, that would allow very elegant syntax for things like initializing weak pointers/references from unique ownership pointers/references. Now we simply can't have such a thing.
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

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

Re: Coding: Fleeting Thoughts

Postby korona » Sun Jul 27, 2014 9:54 pm UTC

I strongly agree with EvanED here: In the expression "auto x = e;" x should always have the type of e. There are billions of bad things that could happen otherwise. Suppose some header file declares a type T (even in another namespace!) with a constructor: "template<typename X> class T { T(unique_ptr<X> ptr); }" and then all "auto x = foo" with foo = some unique_ptr will compile to bad expressions. Also: What if there are two such classes? Does the code compile? Which class does it instantiate? What if you include some library in your code and see that it breaks all your existing code base because it introduces an implicit cast to a random type?

User avatar
Jplus
Posts: 1721
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: Coding: Fleeting Thoughts

Postby Jplus » Mon Jul 28, 2014 7:52 am UTC

korona wrote:Suppose some header file declares a type T (even in another namespace!) with a constructor: "template<typename X> class T { T(unique_ptr<X> ptr); }" and then all "auto x = foo" with foo = some unique_ptr will compile to bad expressions.
The possibility to abuse a feature has never been a reason to leave a feature out of C++. That's simply not the design philosophy of C++.
Also: What if there are two such classes? Does the code compile? Which class does it instantiate?
If your assignment statement is truly ambiguous of course you'll have to disambiguate, like always.
What if you include some library in your code and see that it breaks all your existing code base because it introduces an implicit cast to a random type?
Then it is a stupid library and you shouldn't use it. This is already a problem in C++ by the way, with implicit casts to bool and the like.
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Coding: Fleeting Thoughts

Postby EvanED » Mon Jul 28, 2014 2:08 pm UTC

Jplus wrote:
korona wrote:Suppose some header file declares a type T (even in another namespace!) with a constructor: "template<typename X> class T { T(unique_ptr<X> ptr); }" and then all "auto x = foo" with foo = some unique_ptr will compile to bad expressions.
The possibility to abuse a feature has never been a reason to leave a feature out of C++. That's simply not the design philosophy of C++.
I would say the problem here is not how easy it is to abuse, it's how easy it is to abuse without realizing you're abusing it (and it's not doing what you expect). auto already decreases explicitness by a fair margin; it seems like it'd be pretty easy to make mistakes related to that.
For your case, I'd much rather see the ability to write weak_ref<auto> x = e; if it's the weak_ref template that has the sole constructor that takes decltype(e).

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

Re: Coding: Fleeting Thoughts

Postby Yakk » Mon Jul 28, 2014 3:25 pm UTC

Jplus wrote:This is my pet peeve from C++:

Code: Select all

class youcantcopyme {
public:
    youcantcopyme (const youcantcopyme &) = delete;
}

class buticanconstructwithyou {
public:
    buticanconstructwithyou (const youcantcopyme &) { /* ... */ }
}

int main ( ) {
    auto foo = youcantcopyme();

This doesn't compile. The use of `=` implies a copy/move construction, which is then typically elided. Which you explicitly blocked (which implicitly blocks the move construction).

youcantcopyme foo{}; is probably what you mean.

Code: Select all

    auto bar = foo;  // ERROR, youcantcopyme is noncopyable
}

Argh. Even though there is exactly one type-checking signature for the expression "auto bar = foo;", the C++ standard forbids compilers to correctly deduce it.

There are zero type-checked signatures valid for that line. As "auto X = Y;" means "std::decay_t< decltype(Y) > X = Y;". It doesn't mean "find a type for X for which X=Y is valid".

Now, I'm all for improving the type deduction rules -- extended auto -- but it shouldn't be auto (directly).

In C++11, you can do such type deduction via creator methods imperfectly:

Code: Select all

   auto bar = create_something(foo);

where create_something is a function that takes a foo, then from its type deduces the type you want to construct from it, and returns that type. This requires said return value be move or copy constructable, unless you use it like:

Code: Select all

   auto&& bar = create_something(foo);

which simply puts restrictions on the non-explicit constructors used to make it.

I consider this sub optimal. A better solution would be some kind of type deduction operator:

Code: Select all

   auto[something] bar = foo;

where auto[something] means that

Code: Select all

    template<typename T> auto operator[something](T&&) { return blah; }

gets invoked. (auto[something] syntax is arbitrary -- the point is that you tell the programmer that this isn't just auto, and that "something" is the hook for what kind of magic type deduction is going to be occurring. auto<something>, something<auto>, whatever).

Such would allow:

Code: Select all

    auto[unique_ptr] foo( blah );

type syntax.

For a concrete use case

Code: Select all

   auto[std::function] f = []( int x )->bool { return x > 0; }

which many people seem to want.
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.

User avatar
Jplus
Posts: 1721
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: Coding: Fleeting Thoughts

Postby Jplus » Mon Jul 28, 2014 7:59 pm UTC

EvanED wrote:I would say the problem here is not how easy it is to abuse, it's how easy it is to abuse without realizing you're abusing it (and it's not doing what you expect). auto already decreases explicitness by a fair margin; it seems like it'd be pretty easy to make mistakes related to that.

So you are concerned about how easy it is to shoot yourself in the foot. It is a valid concern, but it has never been a priority in the C++ philosophy, either.

Yakk wrote:
Jplus wrote:

Code: Select all

    auto foo = youcantcopyme();

This doesn't compile. The use of `=` implies a copy/move construction, which is then typically elided. Which you explicitly blocked (which implicitly blocks the move construction).

youcantcopyme foo{}; is probably what you mean.

Oops, right.

As for the remainder of your post: I understand what you are saying and why changing this is nearly impossible given the current standard, but introducing a new keyword or syntax to signify improved type deduction is pretty much the opposite of what I would want. In my opinion type deduction should always take the entire expression function into account while not even requiring the auto keyword.
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

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

Re: Coding: Fleeting Thoughts

Postby Yakk » Mon Jul 28, 2014 8:34 pm UTC

Then I'll be explicit.

std::function<void(int)> can be constructed from **anything** by signature.

So auto f = x; will match std::function<void(int)> and std::function<int(char)> and std::function<void()> and...

You are requiring that **every single class have strict SFINAE constructors**, which is not the case. Or you are requiring that the auto deduction syntax compile the bodies of every overload of std::function (an infinite number, mind you) to determine if any of them can handle your type (who knows, maybe one can! The compiler does not).
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

Postby korona » Mon Jul 28, 2014 11:04 pm UTC

Jplus wrote:
What if you include some library in your code and see that it breaks all your existing code base because it introduces an implicit cast to a random type?
Then it is a stupid library and you shouldn't use it. This is already a problem in C++ by the way, with implicit casts to bool and the like.

So any library with a type

Code: Select all

template<typename T>
class SomeClass {
   SomeClass(const std::unique_ptr<T> &ptr);
};

(or any other moveable but not copyable type instead of unique_ptr) is stupid? What about

Code: Select all

template<typename T>
class SomeClass {
   SomeClass(const T &object);
};

is this stupid too?

Both examples introduce ambiguity in your proposed snippet!

User avatar
Jplus
Posts: 1721
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: Coding: Fleeting Thoughts

Postby Jplus » Tue Jul 29, 2014 8:18 am UTC

Yes, both of those examples are stupid. The constructors should be marked with the explicit keyword.

Perhaps explicit should be the default, and "implicit" should be available as a keyword for in-library automatic casting. Perhaps implicit casting should even require friendship. Although that would hurt the convenience of std::function.
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Coding: Fleeting Thoughts

Postby EvanED » Tue Jul 29, 2014 3:53 pm UTC

I love manpages.

Code: Select all

GLOB(3)
...
No tilde expansion or parameter substitution is done; if you want these, use wordexp(3).
...
       GLOB_TILDE
              Carry  out  tilde  expansion.
...

:roll:

I mean, yes, it's an option you have to turn on explicitly. But "No tilde expansion...is done; use wordexp(3)" is wrong.

troyp
Posts: 557
Joined: Thu May 22, 2008 9:20 pm UTC
Location: Lismore, NSW

Re: Coding: Fleeting Thoughts

Postby troyp » Tue Jul 29, 2014 4:53 pm UTC

Bloody emacs breaks hard links by default!

I switched to using .emacs.d/init.el as my init file a while ago, since I often edit it at the same time as other .el files I use for keeping functions I write. But I like having .emacs in ~, so not long ago I decided to just hard link them. A few days ago, I was having unaccountable trouble getting a customization to work and I discovered the .emacs file had been replaced with a copy, so it hadn't changed. I thought "Huh, how did that happen?", deleted it, relinked it... Then today I'm having the same problem again... I can't work out why my C-h C-m keybinding isn't working (try replacing C-m with RET, try changing the value in help-map directly...). I check .emacs and sure sure enough, it's happened again.

It turns out that emacs replaces hardlinked files by default. I really don't understand why they'd do this*. It's good to have the option, but this is crazy as a default. If I hardlink a file and edit it, I expect to be editing the hardlinked file. I don't expect to have the link broken and an identically named file replace the one I opened!! WTF emacs?

At least I found out now. I've also put the rest of my dotfiles hardlinked in a dotfiles directory for easy backups, and I realize now they're all going to be the old versions. I'm glad I didn't discover that in the future after reformatting my hard drive or something.

Btw, the command to change this is

Code: Select all

(setq backup-by-copying-when-linked t)

(or set 'backup-by-copying if you prefer)

* the name of the variable controlling the behaviour, 'backup-by-copying-when-linked, gives a clue about what's going on. The file is renamed into the backup and the new data is saved as a new file of the old name. So the behaviour is essentially a side effect of the backup mechanism. But it's not like they haven't noticed the implication for hard links in all these years (they've made a variable specifically for the case of linked files!) So keeping the defaults is still a deliberate decision.

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

Re: Coding: Fleeting Thoughts

Postby ahammel » Tue Jul 29, 2014 5:47 pm UTC

Code: Select all

thing, = other_thing,


I'm an idiot.
He/Him/His/Alex
God damn these electric sex pants!

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Coding: Fleeting Thoughts

Postby EvanED » Tue Jul 29, 2014 6:09 pm UTC

troyp wrote:It turns out that emacs replaces hardlinked files by default. I really don't understand why they'd do this*.
Blame the fact that filesystems don't support transactions. So if you want safety if the program crashes or power goes out when writing the file, you have to pull stupid tricks like what emacs does (and many other editors do). The exact method emacs uses isn't the only thing that could be done -- it'd probably be better-behaved to truncate the file rather than deleting and recreating it, for other reasons as well -- but that's why they do it anyway.

But then you say "transactional NTFS is awesome!" and the Unix neckbeards come out of the wood work and say "file systems don't need transactions. programs can emulate them well enough. it's way too complicated. implementation simplicity trumps programs actually working correctly." :roll: I may be exaggerating the last one in terms of what they say, but that's the effect anyway.


Return to “Coding”

Who is online

Users browsing this forum: No registered users and 8 guests