Правда, некоторым не нравится(

«Это для шаблоном придумали, юзайте только с decltype»!

«Это для шаблоном придумали, юзайте только с decltype»!

и для лямбд)

auto main() -> decltype(declval(int)) {}

Вот те на!

auto main() -> decltype(declval(int)) {}

ахах

auto main() -> decltype(declval(int)) {}

а вот это точно надо спереть в цитатник

Зато всё согласно букве закона стандарта разработки, кек.)

auto main() -> decltype(declval(int)) {}

вот это уже С++14?

C++11 тоже прожовывается.

вот это уже С++14?

да это все в 11 было уж

лучше про яндекс и ок расскажи)

что именно рассказать?)

Хотя не оч и работает) http://melpon.org/wandbox/permlink/ljFcWsXk1JJOzUWY

Хотя не оч и работает) http://melpon.org/wandbox/permlink/ljFcWsXk1JJOzUWY

ага, тоже хотел сказать

На main, т.е.

что именно рассказать?)

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

ага, тоже хотел сказать

Можно просто auto писать без типа, если C++14

И оно валидно, штандартно.

auto main() -> auto {};

auto auto auto

auto main() -> auto {};

#шуткапро_auto_auto

Можно просто auto писать без типа, если C++14

ну не, идешки на таком шкварятся немножко

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

в ок ничего так, но ява

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

я думал ты там плюсил) (я про янедкс)

в поиске - да

в общем везде ява, яснопонятно)

неудивительно, учитывая что до фб я писал в основном на яве)

Эммм

Хреново

Значит джава всё-таки нужна

Значит джава всё-таки нужна

не такая уж она и сложная

Она самый лёгкий язык ваще

Но библиотека стандартная дичь

обмазаться декораторами

ща мы сюда дмсола призовем 😂

знал джависта который перешел на плюсы и говорил что продуктивность резко упала

че нашел) https://github.com/cucumber/cucumber-cpp/

знал джависта который перешел на плюсы и говорил что продуктивность резко упала

интересно, почему

Люди, которые привыкли к сборке мусора, не хотят сами его собирать.

unique_ptr<> shared_ptr<>

да, они прекрасны

Помню, на последнем курсе сдавал курсовую "REST на c++". Препод так удивился, что это возможно... 😂

Помню, на последнем курсе сдавал курсовую "REST на c++". Препод так удивился, что это возможно... 😂

сырцы в студию!

unique_ptr<> shared_ptr<>

Да, но ты по сути говоришь, что хочишь обеспечить уборку этого мусора. Полуавтомат такой.

сырцы в студию!

Там ничего интересного. libhttpserver

ну по современным рекомендациям ты должен всегда вместо new/delete использовать make_unique/make_shared

ничем не отличается от вечного v = new V() в жабе

Там ничего интересного. libhttpserver

И это только потому, что c++11 не разрешен был.

ничем не отличается от вечного v = new V() в жабе

Зависит от мировоззрения

Еще джавистов бесят все эти ссылки, указатели, значения

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

примитивные типы - values, а еще большая гора boxing/unboxing

сложнее плюсов!

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

где-т была статейка по поводу классификации передачи параметров по значению/рефу

И из джавистов только самые лучшие занимвются оптимизацией. Остальные предпочитают покупать новый сервер.

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

Особенно с появлением перемещения

Во-во

И из джавистов только самые лучшие занимвются оптимизацией. Остальные предпочитают покупать новый сервер.

да, плюсану)

А потом они просто приносят свой проект, например, чувакам их Яндекса, и просят переписать так, чтобы было быстро.

Мне чувак на собеседовании рассказал

Скажите джависту "таблица ыиртувльных функций" - он в осадок выпадет.

У них же там все функции, кроме final, виртуальные

У них же там все функции, кроме final, виртуальные

Я бы не хотел разводить лишний раз, но это не вполне точно. Виртуальная функция в Java-коде и виртуальная функция в реально выполняющемся машинном коде — две большие разницы. Иначе говоря, настоящий компилятор JVM умеет развиртуаливать вызовы, и делает это неплохо.

Я бы не хотел разводить лишний раз, но это не вполне точно. Виртуальная функция в Java-коде и виртуальная функция в реально выполняющемся машинном коде — две большие разницы. Иначе говоря, настоящий компилятор JVM умеет развиртуаливать вызовы, и делает это неплохо.

Это знают только гуру

Я бы не хотел разводить лишний раз, но это не вполне точно. Виртуальная функция в Java-коде и виртуальная функция в реально выполняющемся машинном коде — две большие разницы. Иначе говоря, настоящий компилятор JVM умеет развиртуаливать вызовы, и делает это неплохо.

на самом деле, JIT умеет делать методы невиртуальными там, где виртуальность не нужна. Скорее в c++ разделение на виртуальные и невиртуальные методы - костыль

на самом деле, JIT умеет делать методы невиртуальными там, где виртуальность не нужна. Скорее в c++ разделение на виртуальные и невиртуальные методы - костыль

Возможность эффективно это делать, как мне кажется, связана с деоптимизацией в случае, если JIT "не угадал". В C++ такой механизм не представлен, и потому виртуальные функции всё-таки костылём не назовёшь. Ну а если ты реально написал virtual, но нигде не переопределил — тогда компилятор волен её заинлайнить и не виртуалить; с этой точки зрения всё ок.

Возможность эффективно это делать, как мне кажется, связана с деоптимизацией в случае, если JIT "не угадал". В C++ такой механизм не представлен, и потому виртуальные функции всё-таки костылём не назовёшь. Ну а если ты реально написал virtual, но нигде не переопределил — тогда компилятор волен её заинлайнить и не виртуалить; с этой точки зрения всё ок.

> компилятор волен её заинлайнить и не виртуалить нет, откуда ж он знает что ты в другом compilation unit не переопределяешь?

WPO

Есть несколько источников для такого рода знания: - если он знает точный тип объекта - LTO

Если компилятор этого наверняка не знает — тогда, конечно, упс, и JIT может потенциально выиграть. Сами знаете какой ценой.

http://hubicka.blogspot.cz/2014/01/devirtualization-in-c-part-1.html http://hubicka.blogspot.ca/2014/01/devirtualization-in-c-part-2-low-level.html http://hubicka.blogspot.ca/2014/02/devirtualization-in-c-part-3-building.html http://hubicka.blogspot.ca/2014/02/devirtualization-in-c-part-4-analyzing.html http://hubicka.blogspot.ca/2014/04/devirtualization-in-c-part-5-feedback.html http://hubicka.blogspot.ca/2014/08/devirtualization-in-c-part-5-asking.html http://hubicka.blogspot.ca/2014/09/devirtualization-in-c-part-6-enforcing.html

очень крутая серия постов на эту тему

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

https://habrahabr.ru/company/abbyy/blog/248429/

вот тоже статья мне нравится

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

> http://hubicka.blogspot.ca/2014/09/devirtualization-in-c-part-6-enforcing.html WAT

копию на ссылку

скажем так