Почему я выбираю C++

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

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

Плохому танцору и яица мешают.

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

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

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

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

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

Замени namespace на class и используй BOOST::TTI

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

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

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

Проверка должна осуществляться компилятором, т.е. код вроде 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 >()

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

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

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() );
}

Поставленная задача противоречива сама по себе, поскольку указатель на функцию — это значение, известное в 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>() );
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не всё.

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

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

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

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

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

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

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

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

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

Потому что XNA/DirectX? Не думал об этом?

Потому что XNA/DirectX? Не думал об этом?

а что с XNA/DirectX?

Привязки только к плюсам и шарпу

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

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

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

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

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

спасибо за инфу, но

OpenGL не популярен в приципе

вот это уже лютое 4.2

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

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

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

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

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

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

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

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

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

1) XBox

2) Windows

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

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

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

Преимущества 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 «ну-ка, нарисуй вот это все у тебя в видеопамяти»

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

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

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

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

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

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

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

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

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 в реально неподходящем для этого месте.

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

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

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

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

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