O>Marshal.PtrToStructure + [StructLayout(LayoutKind.Explicit)] O>и [FieldOffset] в структуре.
Для первого метода предложение принимается.
O>Плюс во втором случае я вижу два варианта:
O> O>Использовать бОльшую по размеру из структур (но это может не всегда работать). O>Зная, где именно находится wfx->wFormatTag, вытягивать его с помощью Marshal.ReadInt32() (и подобных методов). Если поле не в начале структуры, то можно указать offset. O>
Для второго предложения не принимаются, ибо
Здравствуйте, alvas, Вы писали:
A>т.е. размер не равен размеру структуры, а размер структуры + дополнительный размер, который указан в самой структуре (wfx->cbSize)
Ты был невнимателен. Этот wfx->cbSize можно получить, используя Marshal.ReadInt32() — разве нет? Если нет, то аргументируй, пожалуйста.
Здравствуйте, VladD2, Вы писали:
VD>В версии 6470 добавлена ковариантность/контрвариантность для делегатов и интерфейсов.
VD>Описывается это дело с помощью "+" и "-" перед параметрами типов: VD>
Забавно, есть предложение по поддержке данной фичи в C#: Variance and Generalized Constraints for C# Generics, там используется аналогичный синтаксис. Это общепринятое соглашение или Nemerle'овцы делали это с оглядкой на вышеозначенную работу?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: [Nemerle] Новая возможность: Ко/контрвариантность для
EC>Забавно, есть предложение по поддержке данной фичи в C#: Variance and Generalized Constraints for C# Generics, там используется аналогичный синтаксис. Это общепринятое соглашение или Nemerle'овцы делали это с оглядкой на вышеозначенную работу?
Несовсем точно написал, имеется в виду поддержка ко/контрвариантности.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: [Nemerle] Новая возможность: Ко/контрвариантность для
Здравствуйте, EvilChild, Вы писали:
EC>Забавно, есть предложение по поддержке данной фичи в C#: Variance and Generalized Constraints for C# Generics, там используется аналогичный синтаксис. Это общепринятое соглашение или Nemerle'овцы делали это с оглядкой на вышеозначенную работу?
Нет. Они опирались на опыт ML-подобных языков и Scala.
Здравствуйте, VladD2, Вы писали:
EC>>Забавно, есть предложение по поддержке данной фичи в C#: Variance and Generalized Constraints for C# Generics,
VD>А ты открывал pdf на который дал ссылку? Там слово "Scala" встречается чуть ли чаще чем слово "but". VD>Так что даже вопроса не возникает откуда ноги растут.
Оперативность твоих ответов радует
Вопрос был в том, откуда брали немерловцы идею, а не шарписты
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: [Nemerle] Новая возможность: Ко/контрвариантность для
Здравствуйте, VladD2, Вы писали:
VD>Блин, обожаю математиков! 25 мстриц бушита . Оно в коде компилятора существенно меньше занимает. В Скале тоже описано в одном абзаце.
VD>В общем, если нужно что-то полностью запутать, то тут без высшей математики никак.
Ну, первые 10 страниц написаны обычным языком — для простых крестьян, а те кого интересуют формализмы читают дальше.
Прочитал статью — впечатление о языке создалось двоякое, с одной стороны он предлагает прикольные фичи, например, мне очень понравилось то, что компилятор ругается на игнорирование возвращаемого значения функции и как реализовано явное игнорирование(переменная "_").
С другой стороны я считаю что код :
Max(x : int, y : int) : int
{
if (x > y) return x else return y
}
более читабелен, чем:
Max(x : int, y : int) : int
{
if (x > y) x else y
}
хоть и немного длиннее, так как при использовании оператора return даже при беглом просмотре кода гораздо проще понять, где функция может завершить свое выполнение...
Специально привел только по 1 за и против для равновесия=) если наберусь сил и терпения, изложу оставшуюся часть впечатлений...
Здравствуйте, andrey.bond, Вы писали:
AB>С другой стороны я считаю что код :
AB>
AB>Max(x : int, y : int) : int
AB>{
AB> if (x > y) return x else return y
AB>}
AB>
AB>более читабелен, чем: AB>
AB>Max(x : int, y : int) : int
AB>{
AB> if (x > y) x else y
AB>}
AB>
Просто сила привычки. Мозгу требуется некоторое время чтобы перестроиться. Зато когда он перестроится, то синтаксис c# будет казаться громоздким и неудобным.
Здравствуйте, Блудов Павел, Вы писали:
БП>Просто сила привычки. Мозгу требуется некоторое время чтобы перестроиться. Зато когда он перестроится, то синтаксис c# будет казаться громоздким и неудобным.
Вполне может быть..
А немерле поддерживает множественное наследование классов? я понимаю что скорее всего нет, т.к. ооп в нем от с#, но надежда умирает последней...
Здравствуйте, andrey.bond, Вы писали:
AB>А немерле поддерживает множественное наследование классов? я понимаю что скорее всего нет, т.к. ооп в нем от с#, но надежда умирает последней...
Нет, и не надо!
Mixin-ов (uses) которые, кажется, стоят в очереди на релизацию будет вполне достаточно.
Здравствуйте, andrey.bond, Вы писали:
AB>хоть и немного длиннее, так как при использовании оператора return даже при беглом просмотре кода гораздо проще понять, где функция может завершить свое выполнение...
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, andrey.bond, Вы писали:
AB>>хоть и немного длиннее, так как при использовании оператора return даже при беглом просмотре кода гораздо проще понять, где функция может завершить свое выполнение...
K>В ФЯ функция не выполняется — она вычислятся.
А где можно поподробнее почитать о концепции ФЯ без особой привязки к конкретному языку, именно о самом подходе?
Здравствуйте, andrey.bond, Вы писали:
AB>С другой стороны я считаю что код : AB>
AB>Max(x : int, y : int) : int
AB>{
AB> if (x > y) return x else return y
AB>}
AB>
AB>более читабелен, чем:
AB>
AB>Max(x : int, y : int) : int
AB>{
AB> if (x > y) x else y
AB>}
AB>
AB>хоть и немного длиннее, так как при использовании оператора return даже при беглом просмотре кода гораздо проще понять, где функция может завершить свое выполнение...
Это всего лишь говорят твои привычки. Поверь, после небольшого промежутка времени ты будешь недоумевать зачем были нужны эти return-ы во многих местах программы.
К тому же тут основная фишка в том, что мы имеет дело с выражением (expression), а не "констркцией" (statment) if. Так мы можем написать:
def z = if (x > y) x else y;
в C# — это невозможно, так как if — это statment (не может чего либо возвратить).
Что же касается конкретно return-ов, то в принципе их никто не запрешал. Подклчаешь пространство имен Nemerle.Imperative и твой код будет работать как предпологается.
НО Хотя в таком примитивном случае этого не видно, но в облее сложных случаях код без return-ов читается намного проще! Дело в том, что у тебя есть увереннсть, что код не прервется где-то незаметно для тебя. По этому ты можешь полагаться на ветвления. В общем, код становится проще для понимания.
AB>Специально привел только по 1 за и против для равновесия=) если наберусь сил и терпения, изложу оставшуюся часть впечатлений...
Давай. Это интересно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.