Всем привет.

Чем вы обходитесь чтобы быстро скакать по коду, группировать код в блоки подобных ф-ций и т.д... C++ подобные хеадеры отменили, сейчас всё одной большой простынёй.

Нашёл похожую тему от 2003 года, предлагалось использовать "Collapse to definitions". Вариант, только неудовлетворительный на 100%. Возможно таки появилось что то новое за 10 лет?

Я так понимаю использовать интерфейсы — не вариант. Работать через них — каждый раз вызов через виртуальный метод, издержки на ровном месте. Хотя поддерживать впринципе подобно по сложности поддержки C++ headers (ну тут уже Visual Assist выручает).

Здравствуйте, johny5, Вы писали:


J>Всем привет.

J>Чем вы обходитесь чтобы быстро скакать по коду, группировать код в блоки подобных ф-ций и т.д... C++ подобные хеадеры отменили, сейчас всё одной большой простынёй.

Средствами навигации в студии.

J>Нашёл похожую тему от 2003 года, предлагалось использовать "Collapse to definitions". Вариант, только неудовлетворительный на 100%. Возможно таки появилось что то новое за 10 лет?

Да, появилось.

J>Я так понимаю использовать интерфейсы — не вариант. Работать через них — каждый раз вызов через виртуальный метод, издержки на ровном месте. Хотя поддерживать впринципе подобно по сложности поддержки C++ headers (ну тут уже Visual Assist выручает).

Где можно посмотреть на ваш код без единого наследования, в котором заметен выигрыш от замены callvirt на call, учитывая, что callvirt шарп ставит везде, кроме как если класс не помечен как sealed?

Здравствуйте, Aen Sidhe, Вы писали:

AS>Где можно посмотреть на ваш код без единого наследования, в котором заметен выигрыш от замены callvirt на call, учитывая, что callvirt шарп ставит везде, кроме как если класс не помечен как sealed?

У меня нет наследований, и всё равно идёт callvirt?

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

Здравствуйте, johny5, Вы писали:

J>У меня нет наследований, и всё равно идёт callvirt?
Оптимизацией callvirt занимается JIT. Эта инструкция несёт в себе семантику проверки this на null. Реальных же проверок не остаётся, за не надобностью (т.к. AV по 0 и так прекрастно трансформируется в NullReferenceException). Поэтому компилятор на всё подряд ставит callvirt, где это ему удобно.

J>Хорошо, перефразируя скажем — плохой вариант. Вносить издержки в рантайм только для улучшения читабельности... должен быть другой путь.
Меня в C++ очень парят издержки править что-то в 2-х местах. А ещё всякие макросы надо в хидере вставлять (OVERRIDE например какой-нибудь), которые бы соответствовали всем правилам того или иного кода. А вот смотря на имплементацию какого-нибудь метода, макроса этого не видно. Сигнатура — не совсем полная.

Уже сказали за массу средств навигации самой студии. Ещё можно попытаться доки генерировать. Кому как удобнее.

PS: Ну и врядли добавление ненужного интерфейса как-либо улучшит читаемость.

Здравствуйте, johny5, Вы писали:

J>Здравствуйте, Aen Sidhe, Вы писали:

AS>>Где можно посмотреть на ваш код без единого наследования, в котором заметен выигрыш от замены callvirt на call, учитывая, что callvirt шарп ставит везде, кроме как если класс не помечен как sealed?

J>У меня нет наследований, и всё равно идёт callvirt?

Дизассемблируй и посмотри.

J>Хорошо, перефразируя скажем — плохой вариант. Вносить издержки в рантайм только для улучшения читабельности... должен быть другой путь.

Тогда вам в машинные коды и ассемблер с плюсами.

Здравствуйте, johny5, Вы писали:
J>Чем вы обходитесь чтобы быстро скакать по коду, группировать код в блоки подобных ф-ций и т.д...
Директива #region и partial classes спасут отца русской демократии.
Это в том случае, если архитектурно оправдано иметь настолько длинный список мемберов, что его хочется попилить на слабозависимые части. Вы же в курсе про Single Responsibility Principle?
J>C++ подобные хеадеры отменили, сейчас всё одной большой простынёй.
Хидеры C++ — позор и ужос, т.к. Don't Repeat Yourself.

J>Я так понимаю использовать интерфейсы — не вариант. Работать через них — каждый раз вызов через виртуальный метод, издержки на ровном месте.
Издержек никаких нет, ваши представления о производительности кода устарели.
J>Хотя поддерживать впринципе подобно по сложности поддержки C++ headers (ну тут уже Visual Assist выручает).
Да, поддержка лишних интерфейсов, как и хидеров С++ — это геморрой на ровном месте, т.е. чистые затраты без каких-либо выигрышей.