Если вы уверены что метод существует, то попробуйте использовать перегрузку с BindingFlags.
как-то так:
t.GetMethod("GetVolumeList", BindingFlags.NonPublic | BindingFlags.Instance).
BindingFlags.Instance использовать если метод не статичный, для статичного есть BindingFlags.Static
ну в любом случае нужен будет объект StorageManager для того чтобы вызвать метод. Скажите, есть ли в проекте ссылка не сборку Mono.Android? если да то просто используйте typeof (StorageManager). Если нет ссылки то действительно нужно использовать Type.GetType(string). Как я и говорил попробуйте использовать AssemblyQualifiedName только сборка должна быть либо рядом с исполняемым файлом либо в GAC
Не знаю читаете ли вы что-то про паттерны и вообще про проектирование, но все же порекомендую книгу "Паттерны проектирования" от Эрика Фримена и Элизабет Фримен. Отличные примеры, читается на одном дыхании, примеры на Java, все доступно и понятно.
Мне кажется тут уместен паттерн стратегия. Определить семейство алгоритмов IJumpBehavior или ISayBehavior или IWhateverBehavior и наделять Человека тем или иным поведением при прыжке, произношении фразы и прочего. при определенном интерфейсе поведение может меняться просто сменив реализацию поведения на лету.
Nikita Ignatenkov тут все дело в округлениях. если по простому в первом случае вы приводите к int 93.9999999 а во втором 94.0000000001. если вам интересно, то есть объяснение на английском вот тут
Еще могу добавить
1) Внутри команды должны быть одни и те же правила оформления кода для всех. Можно сесть и выработать их вместе, учитывая при этом информацию из умных книжек по оформлению кода. Можно сформировать правила форматирования в Resharper если пользуетесь, дальше развернуть их у каждого. Ну а дальше пинайте друг друга за не соблюдение ваших же стандартов. Ну или тот кто зафейлил форматирование, кладет в банку деньгу на пиво (пиченьки, чай, пиццу, ect.) в концу месяца на всю команду. Потеря финансов и пинки - два самых-самых стимула исправлять плохое поведение.
2) Раз вы пишете на C#, то обязательно к прочтению Дж. Рихтер - CLR via C#. Много нюансов можно узнать . Про джаву ничего не могу сказать по книгам.
ну да, это не влияет на конечную сборку, но вот в процессе компиляции неймспейсы играют свою роль в разрешении того или иного типа, и чем их больше тем больше будет переборов для нахождения того или иного типа.
Кстати да, хотелось бы понять что это такое этот ваш определенный вид. Можно же по разному задавать характеристики, например через какие-нибудь экстремумы, критические точки, диапазоны их изменения, и прочее
Как бы получше объяснить? Репозиторий это коллекция если упростить. а для коллекции основные действия это добавить, удалить, возможно обновить, найти, обратиться по индексу и некоторые другие. Разве логически правильно если коллекция сама для себя будет создавать объекты? Разве правильно если полка для книг будет печатать книги сама для себя (было бы прикольно, но основная цель у нее хранить уже напечатанные книги)? Так и тут, мы добавляем, вносим или регистрируем объект в репозитории, уже готовый объект. Можно конечно сделать метод create, но он должен быть только оберткой для фабричного создания объекта. Тут еще вопрос какие объекты хранит репозиторий. Если это примитивные типы то какая для них фабрика? Создавай и не мучайся! Но если это сложный объект, то лучше через фабрику.
Предполагаю, что если для некоторой лексемы не находится правила, то тут получаем ошибку. Вот тут есть про простенький LR-анализатор.
P.S. Предлажу вам использовать System.Collections.Generic.Stack, который собственно и есть нужный вам стек, вместо такого дурного использования System.Collections.Generic.List.
Виталий Пухов я думаю тут логика такая: файл большой и его тянуть повторно в оперативку скажем так долго, а вот выкинуть его оттуда можно в любой момент, это ж кеш и при большой нужде его и очистить можно, вот ОС и думает "придержу-ка я его в оперативке, может понадобится скоро". Я уже говорил про утилиту RamMap. Ради интереса можете посмотреть что у вас там валяется)
P.S. У меня в данный момент нет свободной оперативки, 13 гб из 16-и скушали программы, а остальное кешем съедено, и ничего, все работает.
ну так вы же читаете 50 гигов данных, предполагаю что из файла. В тех же интернетах был пример, когда делался бекап базы размером в ~4 ГБ и все это добро потом лежало в этом кеше, хотя после завершения создания бекапа эти данные больше не нужны.
@CookieMonster все правильно сказал. .Net c++ сборки и чистые с++ сборки имеют разный формат. первые содержат код в неком промежуточном языке, понятном для Common Language Runtime (далее CLR) .Net-a. CLR и компилирует код из сборки в машинные команды. У .Net c++ нету header-файлов, потому что вся нужная информация хранится внутри DLL-ки и эту DLL-ку можно применять в среде, где есть CLR (она входит в .Net Framework). И еще, благодаря такого рода сборкам решение может содержать проекты на разных языках, можно реализовывать нужные части на том языке, который больше всего для этого подходит и подцеплять сборку в другом проекте.
Раз скорость USB3 соответствует скорости обычного HDD, то нет никакого смысла.
Если подстраховаться и держать систему на внешнем диске (если там такое возможно в этих ваших маках), то можно и не SSD брать.
Если хотите потом его впихнуть внутрь, то можно и ssd.
А вообще я за то, чтобы сразу впихнуть внутрь.
P.S. Ну и гадость же этот iMac. Эти дундуки впихнули туда hdd 5400. Почему сразу ssd или хотя бы hdd 7200 не поставили - загадка. Вроде как десктоп, а получается тупо моник подключенный к ноутбуку. Да еще и с разбором беда. Ноут (не яблочный) хоть разобрать можно, да спокойно почистить да поменять все что позволяет, а тут что?
