Да, в целом все правильно — теперь уже хорошо стало видно, что Microsoft движется по пути мягкого, но настойчивого перевода всех пользователей на Metro.
Не совсем согласен, что мы как технари рассуждали (хотя это и не исключено, все-таки опыт в карман не спрячешь :)) Я пытался исходить из рыночных реалий, вопрос о судьбе Desktop приложений задают очень-очень многие. Потому что это очень важный рыночный фактор.
Но Microsoft, похоже, учится действовать очень тонко и хитро. Они как бы ничего не ломают, но в то же время всех за ручку в будущее поведут. А в будущем будет только Metro.
Кстати говоря, скоро мы можем увидеть одно очень важное подтверждение этому, если Microsoft решится выпустить Office 15 для Metro (возможно и в двух вариантах). И вообще, не исключено, что концепция Metro начнет развиваться так, что покроет и сценарии конструктивной работы.
Я извиняюсь, не понял первый вопрос насчет реальной ОС. Успех iOS понятно с чем связан: она глубоко оптимизирована для популярных нынче сценариев потребления информации. Windows 8 обещает одинаково хорошо поддержать оба сценария: и создания, и потребления. Получится ли? Посмотрим.
Зачем на планшетах запускать старые проги? А для Microsoft планшет теперь ничем не будет отличаться от ноутбука. Обещают, по-крайней мере так.
Гибриды бывают и не жуткие, а наоборот очень даже вкусные и симпатичные :) Работать с информацией нужно не только прожженным технарям, а сотням миллионов пользователей Windows.
Покажите, пожалуйста, как на C++ оформить публичный контракт для класса. Заранее спасибо! :) Примечание. Про могучие фреймворки мы знаем, это уже не C++ получается, а «C++ с могучими фреймворками»
С++ это не совсем ООП в чистом виде язык… это мультипарадигменный язык.
Согласен. (Позволю себе пропустить Ваши предложения почитать о мультипарадигменности вообще и в C++ в частности, ибо читал достаточно много на эту тему.)
Тем более пропускаю Вашу попытку спровоцировать холивар, я обожаю C++ и люблю его (особенной любовью). Сравнивать языки (вернее конкретные родственные механизмы в разных языках) можно и нужно, ибо это помогает развивать мышление и кругозор. Вешать ярлыки «хороший» и «плохой» — никогда!
Теперь по существу вопроса.
Во-первых, принцип изоляции реализации от интерфейса отнюдь не исключительная прерогатива ООП. Принцип исключительно полезный и исходя именно из этого многие, если не большинство современных языков стремятся его так или иначе реализовать.
Поэтому рассуждения о контракте и интерфейсе в полной мере применимы к C++. Проблема только в том, что Вы смешиваете понятие «интерфейс», которое вообще говоря в C++ не определено, и понятие «определение класса», которое как раз принадлежит C++.
В том примере, который я привел выше, два определения класса A безусловно разные. Интерфейсы — идентичные. Даже несмотря на то, что число публичных методов одинаковое. С точки зрения интерфейса определение реализующего его класса — это уже деталь реализации.
И прошу заметить, что я здесь не пытаюсь описывать C++ в терминах другого языка. Только лишь в терминах универсального принципа изоляции интерфейса от реализации.
Еще раз, если вам все-таки хочется продолжать утверждать, что в мире C++ интерфейс класса и определение класса — одно и тоже, вспомните, что в C++ еще бывают публичные переменные-члены. Которые ну никак не сочетаются с принципом изоляции.
Необходимо признать, что данная концепция изоляции в C++ работает только через волевое признание воображаемой сущности «интерфейс» и неукоснительное следование определенному набору правил, обеспечивающему соблюдение той самой изоляции. Можно это сделать и с помощью хитрых программных фреймворков, но в этом случае все равно получится, что интерфейс <> определение класса.
Если же Вы отказываетесь признать понятие интерфейса в описаном выше смысле, то, тем самым, Вы просто признаетесь в том, что не можете последовательно придерживаться универсального принципа изоляции интерфейса от реализации. С++ действительно мультипарадигменный язык. На нем можно писать и так и сяк. Я люблю C++, но еще больше я люблю обсуждаемый выше принцип, поэтому я всегда буду писать на C++ с соблюдением данного принципа.
Именно поэтому для меня классы с одной функцией Foo (int n = 10) и с двумя Foo (int n) и Foo () обладают идентичными интерфейсами.
Когда Вам, как безусловно очень опытному разработчику (без какой-либо иронии), предложат должность технического директора в крупной компании, занимающейся разработкой, Вам, увы, придется изменить мнение насчет 5-ки по брейнбенчу у многих из тысяч программистов.
Гораздо конструктивнее (Вам как техдиректору) — пойти на поводу у большинства и сделать все возможное, чтобы их средние мозги делали меньше ошибок в коде.
Вот здесь и придется идти на компромисс с определением «интуитивности».
Про delete согласен полностью! Ну уж как-то так повелось, что стараешься ужать пример по максимуму, чтобы не отвлекаться от главного. Хотя раз уж написал return 0; то и delete pa; не грех написать.
Если брать любой код, который пишется для практического применения, то я из тех «пуристов», кто будет обливаться потом, но везде ставить смартпойнтеры или по-другому освобождать память. Такое уж воспитание, ничего с собой поделать не могу.
Поведение функций, естественно, зависит от реализации. Только если Вы уж начали говорить об «интерфейсах», нужно не забыть сказать, что клиент интерфейса имеет право исходить только из тех предположений о поведении класса, которые были зафиксированы в публичном контракте между создателем и пользоваталем.
С++ увы практически не имеет выразительных средств для специфицирования таких контрактов: преусловия, постусловия, инварианты и т. п.
Тем не менее, все, что Вы пытаетесь сделать, это убедить нас в том, что несмотря на это (отсутствие самых типовых механизмов для контрактов) в языке C++ есть один уникальный механизм для документирования одного очень специфического положения контракта класса: каким именно частным случаем является вызов некой функции без параметров по отношению к вызову фукции с тем же именем и с явно заданным параметром.
При отсутствии базовых механизмов создания контрактов, использовать такой уникальный механизм для одного единственного чрезвычайно специфического случая ну как-то странно, согласитесь!
Число людей, кто посчитал это поведение «интуитивным» в комментариях — единицы (уж точно не десятки). По сравнению с число просмотров и одобрений топика — очень мало.
Что еще раз подтверждает мой исходный тезис, что большинство разработчиков средней квалификации, не сталкивавшихся до того с подобной конструкцией, не находят ее интуитивной и им все-таки требуется время (пусть и небольшое), чтобы в голове сопоставить «виртуальность» вызова функции с «невиртуальностью» подстановки параметров.
Еще раз повторю, что из моего опыта собеседования кандидатов средней квалификации (около 100 человек), не более 10% давали сходу верный ответ.
И еще раз хочу заверить Вас, чтобы мы больше к этому не возвращались, что c законностью данного поведения C++ никто не спорит и, тем более, это не вызывает ни малейшего сомнения.
Коллега, давайте не будем передергивать! Я полагаю, что все активные участники этого обсуждения уже имели возможность изучить досконально все, что стандарт имеет сказать на эту тему.
Из моего исходного топика:
Для сомневающихся — §8.3.6, пункт 10 в текущем working paper стандарта ISO/IEC 14882: Programming Language C++. (Ссылка на working paper дана просто по причине его бесплатной доступности. В действующем стандарте 1998 года этот пункт находится в той же редакции.)
Как может inline являться частью интерфейса, если это ключевое слово указывает компилятору исключительно на способ вызова функции?
Цитирую Вас: "… конструкция…, используемая для специфицирования услуг, предоставляемых классом..."
Услуг, а не подсказки компилятору о том, как можно более эффективно эти услуги получить.
В любом описании этого ключевого слова делается существенный упор на том, что его можно без каких-либо побочных эффектов опустить, компилятор также имеет право его проигнорировать.
Из этого же следует, что тело inline функции с ее декларацией никак не связано и может быть в абсолютно любой ситуации от нее оторвано и вынесено либо из класса с сохранением inline, либо вообще в другую единицу трансляции без сохранения inline.
Посмотрите на эту проблему и с другой стороны. Что такое интерфейс по существу? Это контракт между пользователем класса и его создателем. Изменится ли что-нибудь от наличия или отсутствия inline для пользователя класса, кроме, возможно, мизерной выгоды в эффективности, да и то совершенно эфемерной, ведь компилятор может ее проигнорировать.
Коллеги, у меня к вам несколько вопросов по результатам обширной дискуссии:)
Согласны ли вы, что следующее модифицированное определение класса: class A {
public:
virtual void Foo (int n);
inline void Foo () {
Foo (10);
}
};
во всех смыслах эквивалентено исходному, использующему параметры по умолчанию: class A {
public:
virtual void Foo (int n = 10);
};
А именно, при вызове метода Foo с использованием параметра по умолчанию A * pa = new A ();
pa->Foo ();
а) результат работы идентичен
б) не вызывает никаких побочных эффектов
в) не привносит сколь-нибудь существенного оверхеда
г) «интерфейс» класса A не претерпевает изменений
Я надеюсь, что здесь спорить не о чем, поэтому следующий вопрос. Изменяет ли следующая модификация класса A его «интерфейс»? class A {
public:
virtual void Foo (int n);
void Foo ();
};
Я первый раз столкнулся с этой проблемой (это когда два дня багу искал) в одна тысяча девятьсот девяносто восьмом году :) В тот момент я еще Майерса не читал, поскольку его первая книжка в самой первой редакции вышла в 1996.
Потом читал, вернее перелистывал. Мне не очень понравилось, что многие случаи разбираются с одной стороны слишком категорично, с другой стороны без достаточно глубокого и разностороннего анализа. Ведь у многих проблем нет очевидного решения в стиле «так писать нельзя». То есть иногда ничего другого не остается, к сожалению (как, например, в разбираемом здесь случае), но все-таки хотелось бы подойти к этому выводу после того, как исчерпывающе проанализированы все альтернативы.
Написал и подумал сам про себя, что в своей писанине далеко ведь не все возможные случаи разобрал :) Прошу прощения, исправлюсь!
Вернее, по задумке — это только первая публикация на эту тему. Дальше планировал написать про дефолтные параметры в C# 4.0 и потом уже отдельный топик с анализом всей проблемы.
Не совсем согласен, что мы как технари рассуждали (хотя это и не исключено, все-таки опыт в карман не спрячешь :)) Я пытался исходить из рыночных реалий, вопрос о судьбе Desktop приложений задают очень-очень многие. Потому что это очень важный рыночный фактор.
Но Microsoft, похоже, учится действовать очень тонко и хитро. Они как бы ничего не ломают, но в то же время всех за ручку в будущее поведут. А в будущем будет только Metro.
Кстати говоря, скоро мы можем увидеть одно очень важное подтверждение этому, если Microsoft решится выпустить Office 15 для Metro (возможно и в двух вариантах). И вообще, не исключено, что концепция Metro начнет развиваться так, что покроет и сценарии конструктивной работы.
Зачем на планшетах запускать старые проги? А для Microsoft планшет теперь ничем не будет отличаться от ноутбука. Обещают, по-крайней мере так.
Гибриды бывают и не жуткие, а наоборот очень даже вкусные и симпатичные :) Работать с информацией нужно не только прожженным технарям, а сотням миллионов пользователей Windows.
Проблема С++ состоит в том, что он создает техническому руководству указанные Вами две проблемы :)
Простите меня, я ради каламбура, конечно, жутко утрирую :)
Покажите, пожалуйста, как на C++ оформить публичный контракт для класса. Заранее спасибо! :) Примечание. Про могучие фреймворки мы знаем, это уже не C++ получается, а «C++ с могучими фреймворками»
Согласен. (Позволю себе пропустить Ваши предложения почитать о мультипарадигменности вообще и в C++ в частности, ибо читал достаточно много на эту тему.)
Тем более пропускаю Вашу попытку спровоцировать холивар, я обожаю C++ и люблю его (особенной любовью). Сравнивать языки (вернее конкретные родственные механизмы в разных языках) можно и нужно, ибо это помогает развивать мышление и кругозор. Вешать ярлыки «хороший» и «плохой» — никогда!
Теперь по существу вопроса.
Во-первых, принцип изоляции реализации от интерфейса отнюдь не исключительная прерогатива ООП. Принцип исключительно полезный и исходя именно из этого многие, если не большинство современных языков стремятся его так или иначе реализовать.
Поэтому рассуждения о контракте и интерфейсе в полной мере применимы к C++. Проблема только в том, что Вы смешиваете понятие «интерфейс», которое вообще говоря в C++ не определено, и понятие «определение класса», которое как раз принадлежит C++.
В том примере, который я привел выше, два определения класса
Aбезусловно разные. Интерфейсы — идентичные. Даже несмотря на то, что число публичных методов одинаковое. С точки зрения интерфейса определение реализующего его класса — это уже деталь реализации.И прошу заметить, что я здесь не пытаюсь описывать C++ в терминах другого языка. Только лишь в терминах универсального принципа изоляции интерфейса от реализации.
Еще раз, если вам все-таки хочется продолжать утверждать, что в мире C++ интерфейс класса и определение класса — одно и тоже, вспомните, что в C++ еще бывают публичные переменные-члены. Которые ну никак не сочетаются с принципом изоляции.
Необходимо признать, что данная концепция изоляции в C++ работает только через волевое признание воображаемой сущности «интерфейс» и неукоснительное следование определенному набору правил, обеспечивающему соблюдение той самой изоляции. Можно это сделать и с помощью хитрых программных фреймворков, но в этом случае все равно получится, что интерфейс <> определение класса.
Если же Вы отказываетесь признать понятие интерфейса в описаном выше смысле, то, тем самым, Вы просто признаетесь в том, что не можете последовательно придерживаться универсального принципа изоляции интерфейса от реализации. С++ действительно мультипарадигменный язык. На нем можно писать и так и сяк. Я люблю C++, но еще больше я люблю обсуждаемый выше принцип, поэтому я всегда буду писать на C++ с соблюдением данного принципа.
Именно поэтому для меня классы с одной функцией
Foo (int n = 10)и с двумяFoo (int n) и Foo ()обладают идентичными интерфейсами.Подписываюсь под этим три раза!!!
h1ppo^3
Когда Вам, как безусловно очень опытному разработчику (без какой-либо иронии), предложат должность технического директора в крупной компании, занимающейся разработкой, Вам, увы, придется изменить мнение насчет 5-ки по брейнбенчу у многих из тысяч программистов.
Гораздо конструктивнее (Вам как техдиректору) — пойти на поводу у большинства и сделать все возможное, чтобы их средние мозги делали меньше ошибок в коде.
Вот здесь и придется идти на компромисс с определением «интуитивности».
return 0;то иdelete pa;не грех написать.Если брать любой код, который пишется для практического применения, то я из тех «пуристов», кто будет обливаться потом, но везде ставить смартпойнтеры или по-другому освобождать память. Такое уж воспитание, ничего с собой поделать не могу.
С++ увы практически не имеет выразительных средств для специфицирования таких контрактов: преусловия, постусловия, инварианты и т. п.
Тем не менее, все, что Вы пытаетесь сделать, это убедить нас в том, что несмотря на это (отсутствие самых типовых механизмов для контрактов) в языке C++ есть один уникальный механизм для документирования одного очень специфического положения контракта класса: каким именно частным случаем является вызов некой функции без параметров по отношению к вызову фукции с тем же именем и с явно заданным параметром.
При отсутствии базовых механизмов создания контрактов, использовать такой уникальный механизм для одного единственного чрезвычайно специфического случая ну как-то странно, согласитесь!
Что еще раз подтверждает мой исходный тезис, что большинство разработчиков средней квалификации, не сталкивавшихся до того с подобной конструкцией, не находят ее интуитивной и им все-таки требуется время (пусть и небольшое), чтобы в голове сопоставить «виртуальность» вызова функции с «невиртуальностью» подстановки параметров.
Еще раз повторю, что из моего опыта собеседования кандидатов средней квалификации (около 100 человек), не более 10% давали сходу верный ответ.
И еще раз хочу заверить Вас, чтобы мы больше к этому не возвращались, что c законностью данного поведения C++ никто не спорит и, тем более, это не вызывает ни малейшего сомнения.
Из моего исходного топика:
А варнинги как раз и нужны на законный, но потенциально опасный, неинтуитивный и пр. код, типа пресловутого
if (x = 0) {Разве нет?
Как может inline являться частью интерфейса, если это ключевое слово указывает компилятору исключительно на способ вызова функции?
Цитирую Вас: "… конструкция…, используемая для специфицирования услуг, предоставляемых классом..."
Услуг, а не подсказки компилятору о том, как можно более эффективно эти услуги получить.
В любом описании этого ключевого слова делается существенный упор на том, что его можно без каких-либо побочных эффектов опустить, компилятор также имеет право его проигнорировать.
Из этого же следует, что тело inline функции с ее декларацией никак не связано и может быть в абсолютно любой ситуации от нее оторвано и вынесено либо из класса с сохранением inline, либо вообще в другую единицу трансляции без сохранения inline.
Посмотрите на эту проблему и с другой стороны. Что такое интерфейс по существу? Это контракт между пользователем класса и его создателем. Изменится ли что-нибудь от наличия или отсутствия inline для пользователя класса, кроме, возможно, мизерной выгоды в эффективности, да и то совершенно эфемерной, ведь компилятор может ее проигнорировать.
Согласны ли вы, что следующее модифицированное определение класса:
class A {public:
virtual void Foo (int n);
inline void Foo () {
Foo (10);
}
};
во всех смыслах эквивалентено исходному, использующему параметры по умолчанию:
class A {public:
virtual void Foo (int n = 10);
};
А именно, при вызове метода
Fooс использованием параметра по умолчаниюA * pa = new A ();pa->Foo ();
а) результат работы идентичен
б) не вызывает никаких побочных эффектов
в) не привносит сколь-нибудь существенного оверхеда
г) «интерфейс» класса
Aне претерпевает измененийЯ надеюсь, что здесь спорить не о чем, поэтому следующий вопрос. Изменяет ли следующая модификация класса
Aего «интерфейс»?class A {public:
virtual void Foo (int n);
void Foo ();
};
Надеюсь, что вы согласны с тем, что не изменяет.
Наверное, вы уже поняли, к чему я клоню. Хорошо видно, что константа
10исчезла из «интерфейса» класса без вреда для него. Из чего следует, что она не является его частью. Из чего следует, что она является частью реализации классаA.______________________
Текст подготовлен в Хабра Редакторе от © SoftCoder.ru
Я первый раз столкнулся с этой проблемой (это когда два дня багу искал) в одна тысяча девятьсот девяносто восьмом году :) В тот момент я еще Майерса не читал, поскольку его первая книжка в самой первой редакции вышла в 1996.
Потом читал, вернее перелистывал. Мне не очень понравилось, что многие случаи разбираются с одной стороны слишком категорично, с другой стороны без достаточно глубокого и разностороннего анализа. Ведь у многих проблем нет очевидного решения в стиле «так писать нельзя». То есть иногда ничего другого не остается, к сожалению (как, например, в разбираемом здесь случае), но все-таки хотелось бы подойти к этому выводу после того, как исчерпывающе проанализированы все альтернативы.
Написал и подумал сам про себя, что в своей писанине далеко ведь не все возможные случаи разобрал :) Прошу прощения, исправлюсь!
Вернее, по задумке — это только первая публикация на эту тему. Дальше планировал написать про дефолтные параметры в C# 4.0 и потом уже отдельный топик с анализом всей проблемы.