LINUX.ORG.RU

Ответ на: комментарий от rechnick

начиная изучение программирования с процедурного, а не объектно-ориентированного языка, можно приобрести вредные привычки процедурного программирования

Тут Фролов погнал.

rupert ★★★★★
()
Ответ на: комментарий от rupert

А как придумать высосанное из пальца требование, которое нормальному человеку даже и в голову не прийдёт?

Это важное требование, называемое «предотвращение протечки абстракции», если ты, конечно, понимаешь о чём речь, хотя, вряд ли :-)

anonymous
()
Ответ на: комментарий от rupert

Это бред сивой кобылы в твоей голове. Услышал звон, как говорится.

Слив засчитан :-) Следующий :-)

anonymous
()
Ответ на: Почему цепепе не ахти :-) от anonymous

А как на цепепе написать шаблон функции, в котором параметром шаблона может быть не любая функция, а только одна из допустимых?

Трейты и static_assert, уже сейчас. Концепты, пока только в некоторых компиляторах и может быть в будущем C++17.

Macil ★★★★★
()
Ответ на: Почему цепепе не ахти :-) от anonymous

Проверка должна осуществляться компилятором, т.е. код вроде auto x = f == &A::f ? &A::f : &B::g ? &B::g : nullptr; не приемлем :-)

О, идиот смайлик опять радует посетителей LOR-а идиотскими вопросами.

Поставленная задача противоречива сама по себе, поскольку указатель на функцию — это значение, известное в run-time, соответственно, в компайл-тайм оно проверено быть не может. Тогда как в задаче стоит требования выполнять все проверки именно в компайл-тайм.

Что наводит на мысль о том, что в случае со смайликом идиотизм идет рука об руку с шизофренией. Что экзотично даже для анонимных LOR-овских экспертов.

Очень хочется попросить у господина смайлика решения этой задачки для любого другого статически типизированного языка. Но, боюсь, идиотизм с паре с шизофренией не оставляют шансов на получения вменяемого ответа.

А вообще, на C++ такие вещи решаются по-другому. Т.к. функции A::f и B::g имеют одинаковый тип, а для шаблонов нужен некий уникальный тип-дискриминатор, то такой тип нужно вводить явно. Например, вот таким образом:

namespace A {

struct f_tag {};
void f() { cout << "A::f()" << endl; }

}

namespace B {

struct g_tag {};
void g() { cout << "B::g()" << endl; }

}

namespace C {

template< typename TAG > struct call_traits {};

template<> struct call_traits< A::f_tag >{ static void call() { A::f(); } };
template<> struct call_traits< B::g_tag >{ static void call() { B::g(); } };

template< typename TAG >
void h() { call_traits< TAG >::call(); }

}

После чего мы получаем возможность вызывать C::h вот таким образом: C::h< A::f_tag >()

eao197 ★★★★★
()

Интересно, что по ссылке народ не так сильно возбудился, как на ЛОРе.

Stalin ★★★★★
()
Ответ на: Почему цепепе не ахти :-) от anonymous

А еще лучше было бы в этой задаче вообще обойтись без шаблонов:

namespace A {

void f() { cout << "A::f()" << endl; }

}

namespace B {

void g() { cout << "B::g()" << endl; }

}

namespace C {

struct f_tag {};
struct g_tag {};

void h(f_tag) { A::f(); }
void h(g_tag) { B::g(); }

}

int main()
{
	h( C::f_tag() );
	h( C::g_tag() );
}

eao197 ★★★★★
()
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от eao197

Поставленная задача противоречива сама по себе, поскольку указатель на функцию — это значение, известное в run-time

Нет, функцию можно использовать как параметр шаблона и ес-но можно ее проверять:

#include <cstdio>

int f()
{
    return 100;
}

template<int(*F)()>
int dummy()
{
    static_assert( F == f, ":-)" );
    
    return F();
}

int main()
{
    printf( "%d\n", dummy<f>() );
}

Что смайлик очевидно тоже не знал.

anonymous
()
Ответ на: комментарий от anonymous

Думаю, что знал. Поэтому и сделал условие, чтобы у C::h был именно такой прототип: h(F f). Здесь F в static_assert-е не получится сравнить с указателями на f и g.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Думаю, что знал. Поэтому и сделал условие, чтобы у C::h был именно такой прототип: h(F f)

Нет, как раз потому и не знал. Т.к. он написал про этап компиляции, а там ес-но никакие указателей на функции не имеют смысла, только типы. А для рантайма можно добавить общий шаблон и проверять уже при исполнении.

anonymous
()
Ответ на: комментарий от anonymous

никакие указателей на функции не имеют смысла

никакие динамические указатели на функции т.е.

anonymous
()
Ответ на: комментарий от rechnick

ну, присобачить ООП к С можно, но выглядит это не слишком красиво. хотя, безусловно, работает. ведь компилятор никаких чудес не творит, он генерит код. а то, что можно сгенерить, можно написать и вручную. просто затрат больше будет.
для студента проще изучать структурированные языки типа Java или C# (кстати, последний я считаю аналогом жабы, а не C, ибо с С он не имеет абсолютно ничего общего). С# сейчас активно навяливается в ВУЗах. мне программисты-студенты, которые у нас работают, даже рассказали, что они на этом шарпе там «контроллеры программируют». я, честно говоря, хз, какой такой контроллер можно программировать на таком языке, но фиг его знает. в общем, мелкософт отчаянно впаривает свою поделку в учебных заведениях, это их стратегический план. хотя с точки зрения студентов лучше и выгоднее изучать ту же жабу. она более распространена и по-настоящему кроссплатформенна.
я не считаю процедурное программирование или ООП злом. но переусложнение паттернов в ООП иногда налицо. а студенты без опыта ещё и пытаются навернуть побольше всяких теоретических изысков в практику. в итоге выходят монстрообразные программы, которые приходится оптимизировать методом полного переписывания.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Macil

Трейты и static_assert, уже сейчас.

Что-то не соображу чем тебе помогут трейты. Можешь изобразить схематически?

DarkEld3r ★★★★★
()
Ответ на: комментарий от slackwarrior

Делаешь такой трейт, явно специализируешь его конкретным типом функции, остальные лесом :)

Примерно как eao197 показал? Тогда зачем там static_assert?

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Не обязательно же все использовать, что можно использовать :) Зависит от твоих конкретных нужд.

slackwarrior ★★★★★
()
Ответ на: комментарий от Iron_Bug

Примеры вузов можете привести? Вообще, это странно. У нас в вузе именно жабку предлагали изучать, а шарп рекомендовали для коннекта к мелкомягкой бд (использовал принципиально Qt). Хотя признаюсь, что пропаганда мс у нас жуткая.

kachsheev ★★★
()
Ответ на: комментарий от kachsheev

ну, в данном случае это бывший УрГУ, матмех (сейчас его присоединили к идиотскому УрФУ и он называется как-то вроде «института математики» УрФУ). вроде преподаватели там остались ещё нормальные, со старых времён. однако, мелкософт и С# там пропихивается коммерческими спонсорами факультета, как я понимаю. они проплачивают, чтобы студентов обучали тому, что им нужно.

Iron_Bug ★★★★★
()
Ответ на: комментарий от kachsheev

Вообще, это странно. У нас в вузе именно жабку предлагали изучать

А учитывая что с выходом C++11 все книги и курсы устарели к чертям, хрен тебе, а не C++ в вузе.

Самое прикольное не в этом. M$ в настоящий момент активно пилит Windows Runtime (сиречь WinRT, не путать с WindowsRT), который в сущности является старым-добрым COM (со своим старым-добрым ABI) в красивой обёртке, и *не* использует технологии CLR.

Я постоянно борюсь с желанием достать из закромов диски с MSDN конца 90-х годов. Там хоть можно найти незамутнённое описание COM и COM ABI.

Так что чую, вскорости unemployment lane пополнится свеженькими C# недоучками, прямиком из вузов.

Macil ★★★★★
()
Ответ на: комментарий от Macil

Не всё. Базовые классы/функции остались теми же, как и работа с ними. Ну да, добавились новые, есть такое.

Кстати, нам начали давать плюсы как раз в районе 2011-2012 года с рекомендацией использовать 2010 студию. Никто и не обмолвился тогда о новом стандарте.

kachsheev ★★★
()
Ответ на: комментарий от kachsheev

сейчас я вроде даже слышала, что С больше не будут преподавать на моём бывшем матмехе. возможно, и плюсы тоже не будут. насчёт плюсов я думаю, что это, скорее, из-за сложности въехать в плюсы для нубов. за год - вряд ли, а два года на один курс там не дадут по часам. так что получится неэффективно. однако, всё, что не преподаётся, даже больше привлекает внимание студентов. так что негативного влияния на изучение плюсов вряд ли следует ожидать. плюсы заметно поднялись за последние года два в рейтинге и интерес к ним не ослабевает. а от сишечки всё равно никуда не деться, она была, есть и будет, тут можно не беспокоиться. если в сях будет меньше нубов - это только к лучшему.

Iron_Bug ★★★★★
()
Ответ на: комментарий от kachsheev

Не всё.

Все. Серьёзно была переработана семантика языка. Фактически C++98 с поправками 2003 года и C++11 — два разных языка.

Macil ★★★★★
()
Ответ на: комментарий от Iron_Bug

плюсы заметно поднялись за последние года два в рейтинге и интерес к ним не ослабевает

Поднялись они исключительно за счёт C++11, C++14 и ожиданий C++17. В этом-то и проблема. Их и так раньше объясняли через пень-колоду, а теперь... Даже понятия не имею что теперь.

Macil ★★★★★
()
Ответ на: комментарий от vertexua

Зачем писать браузер на жабе?

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

reprimand ★★★★★
()
Ответ на: комментарий от Iron_Bug

C# (кстати, последний я считаю аналогом жабы

лучше и выгоднее изучать ту же жабу. она более распространена и по-настоящему кроссплатформенна

да, но почему-то на java практически нет гейм девелопмента. А на C# имеется, притом немало. Может, всё дело в перформансе?

З.Ы. Ни с тем ни с другим языками не работал, просто изучал тему игровых движков в своё время

reprimand ★★★★★
()
Ответ на: комментарий от vertexua

хм. Существует такой движок как Unity, его поддержка имеется в linux. Ни XNA ни DirectX под онтопиком нет. Но разработка все равно под C#

а если говорить о привязках, то, судя по гуглёжу, OpenGL для Java имеется. Неужели никто ничего не сделал? Кто-нибудь знает, http://jmonkeyengine.org/ популярен хоть как-то?

reprimand ★★★★★
()
Ответ на: комментарий от reprimand

OpenGL не популярен в приципе, только среди опенсорц-пердунов, где как известно игр нету.

Другое дело конечно PS4, но фиг знает что там за API, но вроде C++ обязателен.

Получается вот ниши для Java нету, хотя я сам много раз писал очень высокопроизводительную графику на Java. CPU там отдыхал, лениво дергая API для вызова отрисовки разных буферов в видеокарте, которые потом красились шейдерами. Можно было с таким успехом на Python переписать

vertexua ★★★★★
()
Ответ на: комментарий от Macil

Если надо объяснять через пень колоду — то лучше не объяснять, а посоветовать пиноколаду и жениться, чтоб не волноватсья о Гондурасе

В этом-то и проблема... Даже понятия не имею что теперь.

В любой непонятной ситуации жди ответного звонка. Нет никакой проблемы: человеков нельзя чему-то научить (извне), это знали еще др. римляни с греками и это нормально — это должно прийти изнутри, «само». А нет — так нет.

slackwarrior ★★★★★
()
Ответ на: комментарий от reprimand

Ну давай посмотрим категории где используется OpenGL

1) Опенсорц - игр особо нету, в DE всяких

2) PS4 - там что-то проприетарное и С++

3) Android - там подобие Java, но уже далеко только на уровне сорцов.

4) Кросс-API движки например для Steam. Вот тут может где-то приютится твой C#, но все-равно большинство на С++

Где используется DirectX/XNA

1) XBox

2) Windows

vertexua ★★★★★
()
Ответ на: комментарий от reprimand

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от vertexua

Ну давай посмотрим категории где используется OpenGL

начнём с того, что OpenGL - это промышленный стандарт. интерфейс для работы с векторной графикой. его реализации можно использовать где угодно, если железо его поддерживает (в современных GPU чаще всего так оно и есть). он не привязан к платформе. и большинство современных программ его используют, даже если и косвенно. потому что сам по себе он не то, чтобы сложен, но неосиляторам и формошлёпам не даётся. они даже не подозревают, что многие графические библиотеки на нём базируются. клепают гуйню и не задумываются, что внизу под их софтом реально работает куча библиотек.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Преимущества OpenGL и барану понятны. Дело в реальности и у нас есть конкретная тема разговора, а именно «Java не используется в играх, наверное потому что она тормозит». Это 4.2, и я обьясняю причины, такие как отсутствие ниши, доминирование консолей на игровом рынке, у которых фиксированый C++ (PS4) или C++/C# (Xbox) API. А чисто технических проблем с VM нету, там даже специальный gc есть для игр в том числе. Плюс я сам писал приложение на Java/OpenGL, где масса частичек звезды через n-body simulation на OpenCL падала в черную дыру, и это над поверхностью астероида. Noise post-processing, bloom, 3д очки.

CPU посредством Java там курило бамбук, двигало камеру и меняло парочку параметров шейдеров на каждом кадре, а потом несколько раз вызывало команду OpenGL «ну-ка, нарисуй вот это все у тебя в видеопамяти»

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

CPU посредством Java там курило бамбук, двигало камеру и меняло парочку параметров шейдеров на каждом кадре, а потом несколько раз вызывало команду OpenGL «ну-ка, нарисуй вот это все у тебя в видеопамяти»

оно верно, только не надо тут подменять сущности: не «посредством жабы», а посредством OpenGL. если через саму жабу графику рисовать, CPU просто умрёт от инфаркта.
пока жаба дёргает сишные функции библиотек нижего уровня или функции системы - она более-менее шустро крутится. но сама по себе она не предназначена для быстрой работы.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

пока жаба дёргает сишные функции библиотек нижего уровня или функции системы - она более-менее шустро крутится. но сама по себе она не предназначена для быстрой работы.

Непробиваемая логика. Что такое «сама по себе»?

Midael ★★★★★
()
Ответ на: комментарий от Iron_Bug

А либы в жабе нижнего уровня с каких пор не на С++? Ой, а жаба случайно сама по себе не либа нижнего уровня на С++?

vertexua ★★★★★
()
Ответ на: комментарий от Midael

когда какой-то код выполняется в JVM. проще из JVM дёрнуть код на Си. будет работать быстрее.

Iron_Bug ★★★★★
()
Ответ на: комментарий от vertexua

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Так говорят все люди, которые не особо разбирались как «виртуалка» работает. Например

1) new X() работает за амортизированые O(1), которые амортизируется сборкой мусора, возможно в другом потоке.

2) Виртуальные методы в большой части кода заменяются на невирутальные везде где это возможно. Причем не путем анализа дерева кода, а профилированием в runtime. Например если где-то есть интерфейс A, но в реале туда всегда приходит B extends A, то применят оптимизацию.

3) Вот такой код

String getXText() {
  if (this.x != null) {
     return this.x.getText();
  } else {
     throw new Exception("xxx");
  }
}

если окажется что x никогда не null в рантайме, то будет заменен на вызов без проверки с trap процессора, который выстрелит если это таки окажется иногда null и JVM достанет из закрома байткоды и перекомпилирует с проверкой.

4) Не говоря уже о всяких LongAdder, ConcurrentHashMap, которые еще надо поискать в плюсах, что повышает порог принятия решения о использовании сторонней библиотеки для плюсов. А речь как раз о написании высокопроизводительного кода. Я не раз видел когда С++ разработчики по причине гемора с библиотеками лепили std::unordered_map+std::mutex в реально неподходящем для этого месте.

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

не особо разбирались как «виртуалка» работает

дык, нафига в сортах говна разбираться ещё? оно тормозит и жрёт память. это просто факт. и он не только эмпирический, доказанный мировой практикой админства, но даже теоретический. то есть, оно таким было, есть и будет всегда и это не исправить. думаю, не надо слишком долго ковырять это палочкой, чтобы понять, что оно не годится для серьёзной работы.
для мелких поделок и гуйни всякой дешёвой десктопной - да хоть пистон, там пофигу. а сервера и приложухи для эмбеддеда писать надо на нормальных ЯП, без оверхеда. да, никто не сказал, что это будет легко и доступно для детсада. но профессионализм на то и есть, и за это заинтересованные компании платят очень нормальную зарплату. а прикрывать явные тормоза высосанными из пальца аргументами про реализацию хитрых алгоритмов - это не серьёзно. спроси любого админа и он скажет, что жаба тормозит и жрёт память. и всё, не надо никаких теоретических дебатов про O от хрен знает чего.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от Iron_Bug

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

Вот это уровень владения вопросом

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

это уровень владения информацией. а уж нырять вглубь в эти ваши канализации - это вы как-нить сами, без меня.

Iron_Bug ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.