Поломана совместимость с С в С++11?

это один из видов метапрограммирования.

Да, оно. Так вот ОО без мета - это ... ОО препроцессор к С (чем плюсы в молодости и были).

Да, через рефлексию при правильной постановке инкапсуляцию обойти не получится. Защита остается защитой.

Можешь начать с его определения.

Определения есть разные. А мне проще начать с первого настоящего ОО языка - смоллтолка. И его фич.

Кажется вот эта тема. Было еще в каком-то блоге конкретное сравнение С++, жабки и шарпа.

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

Жабка справляется так(код из темы):

import java.io.*;
abstract class ScalarProduct<A> {
    public abstract Integer scalarProduct(A second);
}
class Nil extends ScalarProduct<Nil>{
    Nil(){}
    public Integer scalarProduct(Nil second) {
        return 0;
    }
}
class Cons<A extends ScalarProduct<A>> extends ScalarProduct<Cons<A>>{
    public Integer value;
    public A tail;
    Cons(Integer _value, A _tail) {
        value = _value;
        tail = _tail;
    }
    public Integer scalarProduct(Cons<A> second){
        return value * second.value + tail.scalarProduct(second.tail);
    }
}
class _Test{
    public static Integer main(Integer n){
        return _main(n, 0, new Nil(), new Nil());
    }
    public static <A extends ScalarProduct<A>> Integer _main(Integer n, Integer i, A first, A second){
        if (n == 0) {
            return first.scalarProduct(second);
        } else {
            return _main(n-1, i+1, new Cons<A>(2*i+1,first), new Cons<A>(i*i, second));
            //return _main(n-1, i+1, first, new Cons<A>(i*i, second));
        }
    }
}
public class Test{
    public static void main(String [] args){
        System.out.print("Enter a number: ");
        try {
            BufferedReader is = new BufferedReader(new InputStreamReader(System.in));
            String line = is.readLine();
            Integer val = Integer.parseInt(line);
            System.out.println(_Test.main(val));
        } catch (NumberFormatException ex) {
            System.err.println("Not a valid number");
        } catch (IOException e) {
            System.err.println("Unexpected IO ERROR");
        }
    }
}

А перевирать цитаты религия позвляет?

Где именно я переврал?

Было сказано «размер не известен на этапе компиляции» надо «на этапе компиляции вызова функции гарантировать, что векторы будут одной и той же длины». То есть эти векторы разных типов? Я не понимаю как я попал в такую ситуацию, я попросил пример. Можно?

Ну так чего же ты не можешь объяснить свои проблемы? Почему у меня их нет и я спокойно ушел с С?

Можно пример, чего ты наелся?

Метапрограммирование ортогонально используемой парадигме. Это все равно что сказать, что процедурное программирование без рефлексии - это ... процедурные препроцессор ассемблера. Глупости пишешь.

Смоллтолк не первый ОО язык - тебя обманули. Первым была Симула 67, от которой и идут все наиболее распространенные версии ООП(в том числе и С++). Из живых языков последователем смоллтолка является только Objective-C. И то не чистым из-за наследия С.

Где именно я переврал?

Я привел точную цитату - сравни со своей. Гарантировать равенство длин нужно на этапе компиляции, а не ассертом.

я попросил пример. Можно?

Ищи. ЕМНИП, разговор об этом был на ЛОР (правда, не припомню, чтобы жабные дженерики справились с задачей).

В С++ ООП во время выполнения. В смысле в С++ реализовано полноценное позднее связывание. Рефлексия к этому механизму не имеет отношения. В той же жабке методы вызываются так же по указателям в реализации(грубо говоря), а рефлексия создана сбоку в виде некоторой метаинформации(еще более грубо говоря). Не знаешь - не пиши.

Я же привел выше ссылку и процитировал задачу и java-код. Разве это не оно?

Наелся я именно НЕЯВНОСТИ (нечитаемости). Чехарда с конструкторами и операторами присваиваний и передачей объектов (ссылок, указателей - или самих объектов) параметрами. Шиза с переопределением операторов, делающая код плохо читаемым - потому что один маленький значок может означать аццкую деятельность, включающую кучу всего. Безумие виртуальных функций (о да, конечно же - деструкторов!), особенно при множественном наследовании и переопределении. Достаточно?

Да, это все можно использовать аккуратно. Но в этом и проблема - нужна очень жесткая дисциплина, иначе все будет очень плохо. Мощь плюсов направлена против программиста. Она провоцирует его, особенно начинающего.

В С++ ООП во время выполнения.

Нет там полноценного ООП, если нет мета-информации. Я уж не говорю о том, что наличие указателей позволяет ковыряться в объекте, забив на защищенность любого содержимого.

В той же жабке методы вызываются так же по указателям в реализации

И что?

а рефлексия создана сбоку в виде некоторой метаинформации(еще более грубо говоря)

И что? Важно то, что она есть. Сбоку или сверху - пофиг. Объект анализируем. В отличие от плюсов.

Кстати, а ваши любимые темплейты - их же в рантайме вообще ни в каком виде нет.

Практически вся ОО в плюсах - она во время компиляции

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

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

В общем, твоя история типична и никаких аргументов я от тебя не услышу. Жаль. Была надежда.

Тема, наверное, та. Но для оценки решения моих знаний Явы не хватает.

процедурные препроцессор ассемблера.

А разве нет? Это как раз про С;)

Да, про симулу забыл, виноват. Но там ЕМНИП тоже была ОО больше во время компиляции, чем во время выполнения. Или я ошибаюсь? Там были полноценные (анализируемые) объекты в рантайме

Докажи тезис:

Нет там полноценного ООП, если нет мета-информации

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

Молодец, наконец-то ты сказал что-то стоящее. Да С++ не безопасный язык. Наследие С, между прочим.

Темплейты не имеют никакого отношения к ООП. Более того, вся наша STL не ОО. А ее автор вообще ООП не взлюбил(вернее, не видит в нем пользы). Открою тайну - С++ является мультимпарадигменным языком, а не ОО-языком.

Я буду использовать ЯВНЫЕ вызовы функций.

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

и куча подобных историй в гугле

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

Так в этом и проблема - по-настоящему ОСИЛИТЬ плюсы, с их ОХРЕНЕННОЙ мощью - это куча усилий, которые достойны лучшего применения.

правильно, зачем тратить время на ЯП, ведь тогда не останется времени на то, чтоб писать раздутый и нечитабельный код на С, в котором масса ручной работы с памятью

твоя история типична

ВОТ! Слава богу, признали! Дело не в том, какой я программист и какая была моя команда. А в том, что ИСТОРИЯ ТИПИЧНА. И вот эта типичность уходит корнями в проблемы языка С++.

По секрету - ХОРОШИЙ КОД можно написать и на php. Но почему-то обычно чаще пишут плохой. И вот это - свойство языка. Провоцировать хреновый, опасный код, особенно среди начинающих. Это относится к php. perl. C++.

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

Прикольно. Согласен. Но такое писать мозг можно поломать.

С++ является мультимпарадигменным языком

Я знаю. Это охрененный винегрет, причем каждую из парадигм он реализует хреновато - хуже, чем языки «одной парадигмы».

ООП в С++ - это попытка перенести фичи симулы в системный язык. С этого начался С++. Страуструп писал на Симула всякие работы, влюбился в ООП, но потом ему пришлось все переписывать на BCPL из-за тормозов(симуловский сборщик мусора и пр.). Тогда он решил взять системный язык и прикрутить к нему быстрое ООП, чтобы программисты могли не мучиться и использовать нормальные языковые механизмы не жертвуя производительностью. Он хотел взять Алгол, но взял С(работал он в bell labs, да и популярность С была выше), хотя и плевался на ужасный синтаксис объявлений...

На самом деле я тебе советую как-нибудь на досуге прочесть D&E Струструпа. Многое поймешь. И как он с вами, упертыми сишниками, намучался.

И как он с вами, упертыми сишниками, намучался.

Он породил монстра - и потом мучался с теми, кто не желал иметь с ним дело. Бееедненький. При этом начальный С++ еще был относительно скромным языком. А потом кааак начали наворачивать синтаксический сахар..

Да, и еще. Если мы говорим о платформе юникс, то любой адекватный API должен быть выражен в терминах С. Исторически сложившаяся правильная традиция. В этом смысле почти все равно, на чем оно написано внутри.

Гарантировать равенство длин нужно на этапе компиляции, а не ассертом.

Это понятно, просто я не понял зачем это надо кроме спортивного интереса.

Он породил монстра - и потом мучался с теми, кто не желал иметь с ним дело.

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

Я думаю, что корнями она уходит в программистов.

И да, на С++ обычно пишут хороший код. Как было в 90ых - не знаю, я тогда писал на Delphi, потом на С. Тогда С++ был в тренде и может на нем писали все подряд и всё подряд. ХЗ.

Сейчас С++ - не мейнстрим, а чуть ниже его(на мой вкус - самое то). И программисты хорошие. На собеседованиях попадаются правда редкостные идиоты=)

И да, сравнение с пыхом не корректно - сейчас его есть чем заменить(питон, руби и даже scala). А у С++ пока конкурента нет. Если бы в С были хотя бы RAII(пусть хотя бы через(стандартизованный и поддерживающий longjmp) __attribute__(cleanup)), пространства имен, дженерики(в простеньком виде) или просто типобезопасные макросы, то можно было бы о чем-то спорить. А так говным говно...

Я тут раз пять Rust упомянул. Что о нем думаешь?

Да нет в нем сахара-то почти. Весь сахар - от С. Все остальное - нужные фичи, не реализуемые иначе(макросов-то нормальных нет).

И да. На С++ перешли. И переходят. Причем сейчас к нему новый интерес из-за новых фич и нового витка востребованности скорости и экономии. Уже знаю людей, переписывающих часть Android приложений на NDK. А с сишечкой чистой у них никакого желания возиться нет=)

Я думаю, что корнями она уходит в программистов.

Для меня это одно и то же. Язык делается для людей. Я выше сказал, что С++ - очень хороший язык для зеленых человечков с интеллектом повыше нашего.

Тогда С++ был в тренде и может на нем писали все подряд и всё подряд

В общем, близко к тому.

А у С++ пока конкурента нет.

C. Objective C. D. Vala (который тоже ОО препроцессор, только попроще).

Что о нем думаешь?

Честно - не смотрел. Посмотрю.

переписывающих часть Android приложений на NDK.

Наверняка такие есть. Но потом им приходится делать сборки для разных версий arm. И еще надо будет делать сборки для интела. И при этом люди с андроидом на mips будут грустить.

С откровенно слаб. Objective-C - смотрится как один большой костыль. Ну совершенно никак не сочетается там ОО-часть с сишной. Неудобен он. Да и вызов функции по хешу меня как-то напрягает. Для прикладного софта он вполне нормален. Для системного... Да и нет в нем даже дженериков(или добавили уже?) D - не торт. И он не проще С++... Я попытался его как-то нормально использовать в разработке - бросил затею. Vala да, очень неплоха. Но для gtk и десктопного софта...

Я думаю, что корнями она уходит в программистов.

В С++ есть много способов отстрелить себе ногу на ровном месте. Большая часть относится к копирующим конструкторам и не использованию умных указателей.

У плюсов, на мой вкус, куча проблем, которые совсем не очевидны. Например идиотская система исключений: почему нельзя кинуть exception в одной dll и словить его в другой? Да и вообще с динамической линковкой. Почему это в стандарт не внесли?

почему нельзя кинуть exception в одной dll и словить его в другой?

можно

Objective-C - смотрится как один большой костыль.

Вот! ОДИН. Это правильно!

совершенно никак не сочетается там ОО-часть с сишной.

Как мне кажется, это сделано намеренно - и это мне нравится. Сразу видно по коду - он про «сишную часть» или про «ОО часть». Никаких иллюзий про совместимость. Никакой дурацкой идеи, что классы и структы как-то там связаны друг с другом. И зато там ОО в рантайме нормальное, с интроспекцией. ОО - так ОО!

Для системного..

Как было сказано, для системного софта APIs все равно должны быть в терминах C;)

Представил код из ОП-поста:

#include <stdio.h>

int main(int argc, char** argv)
{
	desu int i = 2;
	printf("Hello! desu~\n");
	return 0;
}

можно

только когда рантайм один и тотже

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

Плюсы делают удобнее многие вещи, которые сложно делать на чистом Си. Плюсы созданы под определённую парадигму программирования. Это определённый инструмент. Но что инструментом пользуются не так, как надо - это не проблема инструмента. А то так можно сказать, что кухонный нож провоцирует убивать или причинять увечья.

только когда рантайм один и тотже

т.е. практически всегда, эта проблема была актуальна во времена gcc2.96, VC6 и т.п.

Но что инструментом пользуются не так, как надо - это не проблема инструмента.

Если им слишком часто пользуются не так, как надо - это именно проблема инструмента - ведь инструмент делается для людей, не для зеленых человечков. Код, написанный чайником на жабе - намного менее опасен и проще распутываем, чем код, написанный чайником на плюсах. Если язык идет в мейнстрим - он ОБЯЗАН обладать некоей защитой от чайника. Язык должен быть нянькой..

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, it blows away your whole leg.
Bjarne Stroustrup

Он все правильно сказал! Ну разве что насчет harder - это он льстит плюсам. Это видимое harder

Язык должен быть нянькой..

Язык не должен быть нянькой. Язык должен быть инструментом. Молоток пошёл в мейнстрим, но если кто-то отбивает им пальцы, что-то рушит или ударяет по голове - никто не бугуртит на тему: «молоток позволяет вандалить, плохой молоток, надо бы его сменить на поролоновую биту, она такого не позволяет!» Зато как дело касается программирования, так «язык должен защищать, оберегать, нянчить программиста». Будто бы все программисты - олигофрены, не могущие 2+2 сложить и предварительно изучить, что и как надо делать.

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

Для мейнстримных языков это почти что так и есть. И если язык это не учитывает - это плохой язык для мейнстрима. Пусть становится нишевым, для крутых пацанов.

С тобой всё понятно. Я могу написать ещё портянку текста, на которую ты скажешь, что «нужна защита, ведь херню сделать могут», но вместо этого вот тебе цитата:

Ну что за тоска! Дурака лелеют, дурака заботливо взращивают, дурака удобряют, и не видно этому конца... Дурак стал нормой, еще немного – и дурак станет идеалом, и доктора философии заведут вокруг него восторженные хороводы.

Хорошо братья написали, очень хорошо. Актуально.

Дык я и с не спорю с братьями. В мейнстримном промышленном массовом программировании оно именно так.

Это понятно, просто я не понял зачем это надо кроме спортивного интереса.

За тем же, зачем вообще нужна статическая проверка типов.

Вот этого делать как раз не надо. Пойнт был в том, что поклонники Scala, помешанные на статической типизации, готовы превратить довольно неплохой язык в черти знает что. Тут интересна мысль svu о том, что C++ - отличный язык, но для зеленых человечков. Может быть, и Scala такая же? Боюсь представить, во что превратят Scala, когда она станет массовой, только а станет ли?

Нет, обезъянки уже жалуются, что scala сложна. И кто-то из продвинутых членов сообщества скалки отвечал им, что да, мол, она сложна и не берите ее, если не можете и не хотите=) Статья была, сейчас лень искать.

Ну если вы не в состоянии осилить один из своих инструментов(язык в данном случае), то какие же вы программисты? Мне вот как раз и scala и C++ нравятся, ибо они очень хорошо(лучше многих других) справляются со своими задачами.

И как убогий и старый как говно мамонта С может быть лучше С++ - не понимаю.

Что такое «язык для мейнстрима»? Язык нужен для решения определенных задач в определенной нише сферы разработки софта. Ты так и не понял, то что тебе пытались объяснить. Весь фан в С++ от того, что ты решаешь задачи методами ООП, метапрограмминга и пр. высокоуровневыми плюшками, но при этом в рантайме у тебя все легкое и быстрое, ОО получается быстрее сишных велосипедов, метапрограмминг и обобщенность же вообще не сказываются на стоимости рантайма и т.д. и т.п. При чем если ты какую-то возможность языка не используешь - это никак не скажется на производительности, т.е. ты не платишь за то, что не используешь(в отличие от других высокоуровневых языков, которые заботливо наделают тебе не нужных тебе плюшек).

Статическая типизация не есть зло.

Динамическая - тоже. Вроде как у дилана была полноценная поддержка и того и другого? Или тоже на уровне лиспов? В шарпе dynamic как-то некузяво смотрится.

Зло есть безмерное употребление. Всему должна быть мера.

Нет, это ты не понял что пытались объяснить. Задача промышленных программистов (тех, кто зарабатывает на этом деньги), грубо говоря - написание программ для пользователей. Как эти программы там внутри устроены, что там за метапрограммические плюшки, пользователей не волнует. Это волнует только тех, кто сопровождает и развивает код.

Практика показывает что наиболее производительно и предсказуемо программировать получается на простых языках. С - почти идеален. Многие используют С++, но без фанатизма, скорее как «С с классами». Ну и для командной разработки С++ совсем уж так себе. Время, которое могло бы потратиться на написание кода, убивается на споры об использовании фич языка, декомпозицию и прочую никому не нужную ерунду

C++ прост, если у тебя есть мозг и инженерный талант. От вас сишников никакого конструктива не слышно. Ни одного примера проблем С++ по сравнению с С за всю тему. Пару раз слились на ООП, подсчете ссылок и пр. И все. И опять толдычите как мантру «практика показывает...».

Моя(и многих других) практика показывает, что С++ лучше С. С не проще - он ущербнее. Почувствуй разницу. На С++ разработка идет быстрее и качественнее. Си вам не питон. Вот на нем действительно быстрее чуть ли не в разы разработка идет по сравнению с С++, потому берем его, если не требуется производительность. Но си скорость разработки только замедлит из-за своей ущербности.