а, вот еще - async захватит SynchronizationContext

В общем насколько я понял, лучше не юзать асинк, если один таск является обёрткой другого, более общего.

Напомню, что у нас есть флудилка @csharprest

'def isDebily(List[User] users) = users.forall(u —> u isDebil)'

1111

Можете подсказать хорошие статьи по организации папок для кода?

Стоит ли хранить окна рядом с другими классами в одной папке/одном namespace?

Как тебе удобнее так то

Ну и от проекта зависит

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

Если еф пользуешь, то вроде после сейвконтекст сущность получает идшку

найс

ща потестим

Если еф пользуешь, то вроде после сейвконтекст сущность получает идшку

Да, так и есть

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

можешь сам генерить айдишку, если готов заботиться о её уникальности

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

При добавлении в базу обычно возвращается ключ, под которым сущность добавлена. Почитай доки.

Если обычный sql то просто returning id дописать

утра в чатик

обед уже скоро

если через EF

то есть аттрибут, вроде как [Id]

да, спасибо. вопрос был в том вернет ли база без дополнительных вопросов модели айдишку. возвращает, полет нормальный

Ребят, проблема возникла. Понял, что через numercUpDown мою проблему не решить, добавил domainUpDown. Залил в него значения из таблицы. Так вот, проблема в том, что пока я не нажму кнопку вниз - кнопка вверх не работает. Че за фигня?

ку! няши

как лучше хранить настройки программы в XML файле или в полях базы данных?

смотря что за настройки и что за программа

Я храню в параметрах программы, т.к. из настроек у меня строка пути к файлу.

в программе настройки оборудования надо хранить, там куча параметров, адреса портов, ip адреса, mac адреса, целое дерево настроек. Вот и как его лучше, в базу пихать или отдельных XML файлом хранить

Ребята, где будет хранится string/класс если его использовать в струтуре (в куче или стеке) ?

в программе настройки оборудования надо хранить, там куча параметров, адреса портов, ip адреса, mac адреса, целое дерево настроек. Вот и как его лучше, в базу пихать или отдельных XML файлом хранить

Ну если у тебя прям их очеь много то навреное лучше в базе

Ребята, где будет хранится string/класс если его использовать в струтуре (в куче или стеке) ?

Ссылочные типы всегда хранятся в куче. В теле структуры будет только ссылка.

Доброго дня мудрецы, помогите советом плз. Ситуация следующая: есть mvc проект, есть Controller унаследованный от BaseController. BaseCont содержит статический кэш (dictionary | concurentDictionary) Вопрос: надо ли делать кэш потокобезопасным? Спасибо

Доброго дня мудрецы, помогите советом плз. Ситуация следующая: есть mvc проект, есть Controller унаследованный от BaseController. BaseCont содержит статический кэш (dictionary | concurentDictionary) Вопрос: надо ли делать кэш потокобезопасным? Спасибо

да

Спасибо

да

concurrent коллекции же потокобезопасные

йеп, я и имею ввиду что надо делать канкарент

А если инициализация кэша происходит только при старте аппликации и при работе производятся только операции чтения?

Что случится в случае множественного доступа к обычному словарю?

Что случится в случае множественного доступа к обычному словарю?

https://msdn.microsoft.com/en-us/library/xfhwa508%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396#Thread Safety > A Dictionary<TKey, TValue> can support multiple readers concurrently, as long as the collection is not modified. Even so, enumerating through a collection is intrinsically not a thread-safe procedure.

О прикольно, спс

как лучше хранить настройки программы в XML файле или в полях базы данных?

но где ты будешь хранить настройки подключения к БД, если ты хранишь настройки в бд?

Ссылочные типы всегда хранятся в куче. В теле структуры будет только ссылка.

аккуратнее со словами "всегда" и "никогда"

аккуратнее со словами "всегда" и "никогда"

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

ты ещё начни рассказывать, что все типы наследуются от object

Сходу б я сказал, что все, кроме указателей.

указатели - это то, что нельзя скастовать к object

а вообще всякие штуки типа интерфейсов и непараметризированных дженериков

от объекта не наследуются

Можно рефлекшеном намутить тип, который будет наследоваться от какой-нибудь другой дребеды, если поменять некоторые приватные поля в типе :)

ERROR: S client not available

структурки так вообще от System.ValueType наследуются

Я так создавал инстансы System.Void и System.Math (второй даже сложнее, кстати).

который, внезапно, не наследуется от object

структурки так вообще от System.ValueType наследуются

Ха, не все!

runtimetypehandle всякие там

который, внезапно, не наследуется от object

как это

На днях обнаружили, что F#-конпилятор делает структуры и не наследует их от System.ValueType :)

валью тайп же переопределяет методы object для типов по значению

про valuetype напиздел, да

На днях обнаружили, что F#-конпилятор делает структуры и не наследует их от System.ValueType :)

недокомпилятор маргинального языка

как его вообще CLR носит

недокомпилятор маргинального языка

Ути-пути.

нет, ну серьёзно

Важен ПОРЯДОК файлов в проекте

CLR носит ещё некоторые интересные вещи, которые не поддерживаются спекой и Mono.

Например, из Void-методов можно вернуть 0. Внезапно.

пушто stdcall

Важен ПОРЯДОК файлов в проекте

Это очень хорошая архитектурная фича, и в целом у сообщества отношение к ней положительное.

и cdecl

И воще, не гони на F#. Я вчерась весь вечер там всем топил за Авалонию, так что вот не надо тут.

лучше бы шеневмерл пилили

а то он уже почти вмерл

Это можно, Немерле ок.

у них там случилась проблема с поднятием самих себя за шнурки ботинок

И воще, не гони на F#. Я вчерась весь вечер там всем топил за Авалонию, так что вот не надо тут.

А почему хорошее ?