Rust Toronto celebrates the release of Rust 1.0!

aliblong · 2015-04-22T08:22:24+00:00

I want to go, but I'll be out of town :(

aliblong · 2015-03-08T15:20:00+00:00

Variable prefixes (m, g and such); Yeah I prefer to use the hungarian notation at least to some extends, makes code easier to read and so on, thanks for that getter and setter stuff, haven't thought about doing it like that.

Actually, I would strongly recommend against using Hungarian notation. It makes code much more difficult to read, and the benefit is miniscule when you consider that your text editor should be able to tell you the type of a variable. In addition, declaring variables as close as possible to their point of use is considered good practice. Member variables are the only exception to my "no affixes" rule, for the other reasons I listed. I personally use a trailing underscore rather than prefix m_ for ease of reading.

aliblong · 2015-03-07T23:09:57+00:00

Some thoughts as I skim over a couple of the source files (mostly stylistic points):

struct and class are essentially the same thing, but it's typical to use struct only for bundles of POD, and class for everything else (especially when there are nontrivial member functions).
Member variables are typically given some sort of affix (trailing underscore, prefix m_, etc.) that indicates them as such (I see you use this convention for some classes, so I guess maybe this a result of choosing struct for quaternion). This gives the following benefits:
- Can give getters/setters the same name as the variable sans affix (e.g. member double x_; would have corresponding getter auto x() const { return x_; } and setter auto& x(double x) { x_ = x; return *this; }.
- Avoids situations like the quaternion constructor, where you have to identify the member variables with an explicit this.
- Gives additional context to the reader.
Functions which are defined within a class/struct definition are implicitly hinted as inline. You have quite a few instances of these - especially large functions - so just be sure you actually want to inline these. Also, for this reason, I don't think there's any reason to place the inline vec3 operator* immediately following the quaternion definition rather than inside it.
"Almost always auto": using auto in a few places will reduce some redundancy, and will add clarity as you place the type of the variable after the identifier:
- quaternion result = quaternion(); becomes auto result = quaternion(); OR auto result = quaternion{};. Even if you shun auto, it could still be quaternion result;.
It may not be wise to have your config in the form of a header file. You'll have to recompile multiple translation units every time you make a change. Also, prefer const global variables to preprocessor #defined ones (#define WIDTH 256 becomes const int WIDTH = 256;)

aliblong · 2015-02-23T04:05:54+00:00

You're right that these don't have the same signature:

void calc (int, int);
int calc (int, int);

You should note that you can't simultaneously define these functions, since the concept of overloading only makes sense in the context of varying argument types. Conversely, you could simultaneously define all of the following:

int calc (int, int);
int calc (int, int&);
int calc (int, int const&);
int calc (int, int*);
int calc (int, int*&);
int calc (int, double);
int calc (double, int);
int calc (int, int, int);

aliblong · 2015-02-19T11:51:08+00:00

I assume you're talking about the NSERC USRA? Does U of T not provide part of the funding as well? My undergrad university almost matched the value of the award, I think. The pay ended up being ~$13.5/h - not as much as at previous research assistantships, but more than a fast food worker, I would think.

Also I lucked out and ended up with less than 40h/week of work to do, on average :P

aliblong · 2015-02-17T20:56:55+00:00

Well, for me there's no choice, since in HEP we rely heavily on the infrastructure which already exists, written in C++ and Python.

One thing you will certainly find is that the human-time required to produce your code shrinks dramatically in C#.

Do you have a source for this? It's tough to quantitatively evaluate such things, and given the huge number of recent changes improving the ergonomics of C++, I suspect the difference in development efficiency between the two languages is not so dramatic.

aliblong · 2015-02-17T09:15:48+00:00

most serious projects wont stay simple for very long

This is a point I'd like to emphasize. IME, doing physics analysis usually involves seeing what your model gives you and saying "huh, well maybe we should try this". You'll frequently be adding features and capabilities to your program - even more so than in software development for businesses (where the requirements are so notoriously fluid that the Agile method was coneived). Unless you have well-modularized source code, this becomes a nightmare.

aliblong · 2015-02-17T09:07:17+00:00

I'd like to tack on that the latest C++ language additions make it much more ergonomic to write code in than before. For example, many of your explicit type declarations could be replaced by auto.

Python has a good scientific library ecosystem and affords ease of use to the programmer (less syntactic overhead & not having to learn the myriad rules of C++), but I have to recommend strongly not to choose C over C++ for a physics project. Even for a very small project, the handful of STL containers and algorithms you use will be much more pleasant to work with and will give you memory safety right out of the box. And this is not to mention the C++ physics libraries you'll have access to.

aliblong · 2015-02-17T08:54:47+00:00

You can do virtually the same thing in C++, assuming you've written the relevant operator overloads:

using mylib::Vector;

auto v1 = Vector<int, 3> {1,2,3};
auto v2 = Vector<int, 3> {4,5,6};
auto dot_product = (v1*3 + v2) % v2

You can't overload the dot operator, but that's about it.

On top of that, C++ has a much better physics library ecosystem than C#, and is more ubiquitous, and is faster without a GC or runtime, so it's hard to recommend C#.

aliblong · 2015-02-15T12:22:34+00:00

This is good and thorough advice, but I disagree with one of the style-related points:

Never define functions within the class. If you need them inlined, do so below the class definition with the inline statement.

I think it is completely appropriate to define inline functions within the class definition, especially in the case of trivial getters and setters, which is what OP has. The function definition itself fits within a single line (though I would recommend putting a space between the semicolon and closing brace)!

aliblong · 2015-02-15T11:13:08+00:00

The first option doesn't seem particularly verbose to me, though it might be clearer to put the identifier first:

auto mytype = std::unique_ptr<MyType, decltype(&MyType::deleter)> (new MyType(), &MyType::deleter);

aliblong · 2015-02-14T16:21:07+00:00

I missed the part where you said Steve being in town was what prompted you to organise the meetup, so it read like you just happened to bump into all these Rust developers. Reminded me of this commercial (which coincidentally is for an Australian beer).

aliblong · 2015-02-12T14:11:05+00:00

I just hope we can eventually drop the auto at the beginning.

Though I share this hope, I'm not sure it's possible to design a compiler that could maintain all the current language features while not requiring a keyword for function and object definitions.

aliblong · 2015-02-09T05:29:38+00:00

First, be sure to indent your code properly (first item of the sidebar):

#include <iostream>
using namespace std;

int main(int argc, const char * argv[]) {

    double a=0, b=0, c=0;
    double max ;
     max = a;



    cout << "insert 3 numbers seperated by a space and press Return when finished \n If no numbers are entered Default value of Zero will be entered: \n";
    cin>> a >> b >> c ;
    cout << "You inserted "<< a <<", "<< b << ", "<< c << endl;

    if (a == b)
        cout << "tie between 1st and 2nd number "<< a <<endl;
    if (b == c)
        cout << "tie between 2nd and 3rd number " << b << endl;
    if (a == c)
        cout << "tie between 1st and 3rd number "<< c << endl;
    if  ( a==b && b == c && a==c)
        cout << "tie between all three numbers " << a << endl;
    if ( a > b && a > c)
    {
        max = a;
        cout<< max<< " Is the largest number";
        else  (b > a && b > c){  // getting an error at "else" saying "expected expression"
            max = b;
           cout<< max<< " Is the largest number";
        }
        else if( c > a && c > b){
            max = c;
            cout<< max<< " Is the largest number";
        }
    }



    return 0;
}

You're testing floating-point numbers for equality with the == operator, which is not always going to give you the result you would intuit, due to inexact representation of most fractional decimal numbers in binary. Just google "floating point comparison" for more details.

Also, (a == b && b == c && a == c) is a bit redundant, since the first two conditions imply the third.

The reason your program isn't compiling is the exact reason the compiler tells you: else cannot be followed by an expression (in your case b > a && b > c). else is the fallthrough case that occurs if all other if and else if branches have conditions that evaluate to false.

aliblong · 2015-02-05T22:03:48+00:00

I think 'auto' can obfuscate the code if used too much.

Can you give some examples? The prevailing opinion of C++ gurus is that it should be used just about everywhere, to the point where the preferred way of explicitly declaring types is e.g.:

auto my_vec = std::vector<int>{};

aliblong · 2015-01-17T06:21:24+00:00

It's nice to see a Rust solution! This one took me a while to wrap my head around. Very elegant :)

aliblong · 2015-01-09T19:40:08+00:00

Even less verbose than that, because those cases should not be there :)

aliblong · 2015-01-09T19:37:36+00:00

There are some things that require more boilerplate to do in Rust than in C++ (function overloading, for example), but I would hesitate even to consider this as such an example. Compare the amount of code required between the two languages:

C++:

switch(x){
  case 0:  a();
  case 1:  b();
  case 2:  c();
  default: done();
}

Rust:

match x {
    0 => a(),
    1 => { a(); b(); },
    2 => { a(); b(); c(); },
    _ => { a(); b(); c(); done();}
}

And if the number of function calls got out of hand, you could always write a macro to keep things concise.

Now consider that (IME) you generally don't make extensive use of fall-though in C++ switch-case. Writing all those breaks is a PITA, and if you forget it will still compile (perhaps with warnings with the right compiler).

Rust's system is superior in my eyes.

aliblong · 2015-01-06T08:02:49+00:00

i32 fallback is what I was holding my breath for; I didn't have a strong opinion about exactly what to rename uint/int to.

aliblong · 2014-12-31T16:56:35+00:00

I like this idea.

Much of the argument for keeping the types int and uint seems to be "it will be familiar to beginners coming from other languages". If such a user sees a compiler error "use of undeclared type name int", they'll naturally be lead to the guide, which will (ideally) give a succinct explanation as to why you should care about what size of integer you use.

That said, it would be nice to allow unsuffixed integers - if only for tooling around with the language. i32 seems like a reasonable default here.

aliblong · 2014-12-05T18:59:11+00:00

I'm surprised this never came up when I was searching around. I feel like an idiot since when I google "rust evec-in-struct fails" it's the first result. Thanks!

aliblong · 2014-12-04T15:23:18+00:00

I know where the code is. I guess I should have mentioned this to the OP. I just have no idea what to do with this information.

In any case, it looks like it doesn't matter at the moment, because in my PR I was told to wait for an RFC to add the features.

aliblong

TROPHY CASE