В Rust используется разрушающее сопоставление с образцом, что в купе с моделью памяти Rust, иногда, дает очень занятные эффекты. Для примера возьмем структуру MyStruct и создадим две переменные типа Option в которых будет лежать наша структура, в одном случае в виде стекового объекта, а во втором в виде уникального указателя.

struct MyStruct {
    val: int
}
let stack_data = Some(MyStruct{val:42});
let own_data = Some(~MyStruct{val:42});

http://sysdev.me/destructive-pattern-matching

Теперь RSDN поддерживат и Rust!

extern mod std;

use std::{task, io, uint, libc};
use std::comm::{SharedChan};

struct TestInfo {
    mode: task::SchedMode,
    tasks_count: i32,
    timeout: i64
}

Как несложно догадаться, нобходимо использовать тег rust в квадратных скобочках.

Сергей, добрый день.

Что ж, я в принципе разобрался со всеми сложностями и напастями, что мне встречались и теперь могу рассказать, что же у меня получилось.
На текущий момент, у меня готов первый вариант, из тех, что я описывал, т.е. практически всю работу на себя берет WCF (правда в .Net 4.5 работа так или иначе идет с использованием WIF, но от вас лично не потребует ни строчки кода для WIF — разве что вы начнете делать какие-то кастомные расширения).

Для начала, чтобы у нас было единое понимание того, что происходит, позволю себе небольшое описание процесса (см. картинку):

0. Пользователь вводит свои UserName и Password (U/P)
1. Клиент пытается подключиться к WCF Service используя переданные ему U/P. Однако, инфраструктура WCF, анализирует указанные ей настройки и выясняет, что от нее требуется работать по Federation протоколу, а это значит, что вместо прямого обращения WCF Service...

Это загадка, которую я недавно публиковал на Twitter и давал коллегам на работе. Пока что её отгадал только один человек — Mads Torgersen (причём почти сразу).

Напишите валидную C# программу, которая содержит следующую последовательность токенов:

? null :

и которая остаётся валидной, если мы уберём токен null из этой последовательности, т.е. оставим

?      :

	Пояснения
	* Валидная программа — это программа, которая компилируется без ошибок. Она может быть как приложением (.exe), так и библиотекой классов (.dll). * Комментарии, части строковых литералов, имена регионов, текст в пропущенных секциях (#if false) и т.д. не являются токенами. * Части токенов не являются токенами (например, символ `:` в выражении `foo::bar` или `?` в выражении `foo ?? bar` не являются токенами) * Runtime поведение программы несущественно. То, что оно может измениться при удалении токена null, также несущественно.

Joe Duffy's team has been designing and implementing a set of “systems programming” extensions to C# over the past 4 years.
At long last, I’ll begin sharing our experiences in a series of blog posts.

The first question is, “Why a new language?”

Ссылка

Краткое описание ключевых возможностей нового языка программирования Rust. Основной акцент делается на особенностях Rust, которых не хватает многим системным и сетевым разработчикам в других языках программирования.

Приятная новость: в Clang сделали полную поддержку C++1Y. Вообще, в компиляторе довольно много интересных изменений, начиная с поддержки дополнительных диагностических сообщений, заканчивая режимом совместимости с компилятором из Visual Studio. Подробности тут.

Т.к. считается, что принцип открытости-закрытости был введен Бертраном Мейером, а позже несколько перефразирован и конкретизирован Бобом Мартином, то для лучшего понимания принципа стоит рассмотреть, как он описывался в обоих источниках: у Мейера и у Мартина.

Начнем с рассмотрения принципа в книге Мейера "Объектно-ориентированное конструирование программных систем":

[q]Открыт-Закрыт

Любой метод модульной декомпозиции должен удовлетворять принципу семафора: Открыт-Закрыт:

Принцип Открыт-Закрыт

Модули должны иметь возможность быть как открытыми, так и закрытыми.

Противоречие является лишь кажущимся, поскольку термины соответствуют разным целевым установкам:
[list]

Модуль называют открытым, если он еще доступен для расширения. Например, имеется возможность расширить множество операций в нем или добавить поля к его структурам данных.

Модуль называют закрытым, если он доступен для использования другими модулями. Это означает...

http://adamralph.com/2013/12/06/ndc-diary-day-3/

//primary constructors - 
public class Point(int x, int y) { }
//read only auto-properties - 
public int X { get; } = x;
//static type using statements - 
using System.Math;
//property expressions - 
public double Distance => Sqrt(X * X + Y * Y);
//method expressions - 
public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);
//params for enumerables - 
public Point Average(params IEnumerable<Point> points) { }
//monadic null checking - 
if (points?.FirstOrDefault()?.X ?? -1) { }
//constructor type parameter inference - 
var t = new Tuple(1,2); // infers Tuple<T1, T2>
//inline declarations for out params - 
public void Foo(out var x, out var y) { }

Имхо, какой то хоть и полезный но хлам.

Здравствуйте, Аноним, Вы писали:


А>Nunit
А>Есть вот такой метод для теста
А>Как лучше, оставить как есть или сделать через параметры и указывать все значения init1, do1, 0, 1 — через аттрибуты
А>Насколько это удобно будет отлаживать во 2м случае ?

Конечно здесь явно напрашиваются параметризованные тесты, ведь по сути, здесь не один тест, а два.

[TestCase("init1", "do1", Result = 0)]
[TestCase("init2", "do2", Result = 1)]
public int Test_That_Do_Produces_Expected_Result(string initData, string doData)
{
  // У нас же тут ООП, как никак, а раз так, то инварианты класса А
  // должны устанавливаться в конструкторе
  var a = new A(initData);

  return a.Do(doData);
}

Основной плюс параметризованных тестов в том, что это четко показывает, что у нас не один тест, а два. Ведь существуют правила написания юнит-тестов...