Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Позволю себе вмешаться. Синтаксическую ошибку в программе VladD2 компилятор нашел, но посчитал ее предупреждением. Не обращать внимание на предупреждения не стоит ни в С++, ни в С#. Как минимум, надо на них посмотреть и решить, стоит ли игнорировать, а лучше вообще убрать.
+1. Только есть некоторая разница. Это компилятор посчитал ее предупреждением. Хотя и ясно, что подобная ошибка предупреждением быть не может. Непонятно о чем думали разработчики компилятора.

PD>А что касается вывода, то ошибка в спецификации строки вывода ловится только в рантайме. Вот такое
PD> float f = 9;
PD> Console.WriteLine("{0,8:d}", f);
PD>компилируется на ура
Абсолютно правильно компилируется. Это ошибка семантики программиста. Но есть достаточно много ситуаций когда среда может говорить об ошибке постфактум. Типа:

//такое даст ошибку компиляции
bool b=true;
int i=(int)fl;
//такое даст ошибку при исполнении
bool b=true;
object obj=b;
int i=(int)b;

Но по крайней мере я знаю, что компилятор старается помочь мне.

PD>А вот такое
PD> Console.WriteLine("{0,8:d}");
PD>и вообще работает, только выводит не то, что автор хотел , а то, что здесь есть.
Это семантическая ошибка программиста. Среда всего-лишь выполнила то, что программист ей сказал. А что программист хотел, ни один язык не предугадает.

С уважением, Gleb.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Всем, кто с этим согласен — прошу, поставьте плюс.
PD>Всем, кто с этим несогласен — прошу, поставьте минус.

Ну соглашусь, а дальше? Будем делать мультиязыковые проекты? Из скольких языков? Каких языков? Как между ними роли распределять?

Ну например, есть C++ проект и C++ программисты. Совсем не сложно обучить их Python-у или Ruby чтобы соединить код на Python/Ruby в одном проекте (там вообще все просто -- либо C++ код становится расширением Ruby/Python, либо в C++ приложение интегрируется Python/Ruby интерпритатор).

Если взять уже C++ и C#, то C# на так прост, как Python или Ruby. Нужно потратить гораздо больше времени на его изучение. Более того, мышление менять -- это ж надо привыкнуть, что вместо шаблонов в compile-time рефлекшен в run-time использовать. Или делегаты вместо функторов. А что делать после изучения? Как объединять код на C++ и код на C#? Через COM? А если в C++ проекте COM-а вообще не было никогда, его что насильно в C++ тащить, чтобы с C# проинтегрироваться?

А если C++ и Java? Через JNI? Так ведь еще умудриться нужно сложную C++ структуру через JNI в Java передать. Или наоборот. А если не JNI, тогда что? CORBA? Почти что COM, но другое

---

Все нижесказанное является моим крайне субъективным ИМХО.

Как мне кажется, не так уж много программистов смогут одинаково эффективно работать на нескольких (больше трех) языках и использовать разные платформы. Даже в достаточно близких языках, таких как C++, Java, C# есть свои идиомы. Поэтому многое, что мы привыкли делать в C++ (шаблоны, RAII), в Java уже бесполезно. То, что в Java или C# элементарно выполняется с помощью рефлекшена, в C++ достигается долгими экспериментами со сторонними библиотеками или самописным велосипедом. Переключение между этими языками уже требует переключения сознания на другой способ оценки задачи и способов ее решения.

А если взять более далекие друг от друга языки? Например, C++ и Ruby, или C# и Python, или Java и Erlang? Сколько потребуется времени и сил, чтобы подготовить специалиста, способного одинаково хорошо пользоваться такими связками? А если количество языков увеличится, скажем, C++ + Java + Erlang + Python?

Но программировать это одно дело, здесь опыт нажить можно со временем. А вот проектировать кто будет? Какой опыт нужен проектировщику, чтобы сказать -- вот это на Python, вот это на Erlang, вот это в виде C++ расширения для Python, вот это только на C++, вот это на Java... И существует вероятность того, что написав какой-то фрагмент на Python можно убедиться, что он нифига не подходит. Даже после рефакторингов, оптимизаций и C++ных вставок. Большой кусок работы будет выброшен в мусор?

Другой фактор здесь, который следует учитывать -- это нравится ли конкретный язык конкретному разработчику или нет. В теории понятно, что можно взять С++ и Python, и на их основе делать проект. Но если мне, как заядлому C++нику, не нравится Python из-за своего структурирования пробелами и необходимостью передавать в каждый метод класса параметр self, то я буду откровенно филонить в использовании Python и пытаться больше кода сделать на C++. И если мне язык не нравится, то нет никакой гарантии, что я буду его хорошо знать и применять эффективные способы программирования на Python -- более вероятно, что буду делать "абы работало".

Да и человеческий фактор в мультиязыковых проектах становится гораздо более важным, чем в моноязыковых. Взаимозаменяемость может стремительно уйти в ноль. Просто потому, что бывает мало знать основы языка, нужно знать еще и кучу специализированных фреймворков для конкретного языка. Например, я смогу разобрать простые программы на Java, но в EJB я полный ноль. Поэтому с ходу заменить любого из наших Java-программистов я не смогу. Так же, как и EJB Java программист не сможет заменить C++ Qt программиста. Только после длительного переобучения.

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

---

Все сказанное базируется на моем собственном опыте. Некоторое время назад у нас в компании часть проектов стартовали на Java вместо C++. А сейчас я обдумываю как лучше подружить Ruby и C++. При этом наибольшее количество вопросов вызывают не технические детали, а перечисленные выше политические, психологические и социальные проблемы.

Здравствуйте, Дарней, Вы писали:

Д>а ты еще не прекратил глушить самогон по утрам?

В классике был ни то коньяк, ни то виски. Это ж из Карлсона.

Здравствуйте, minorlogic, Вы писали:

M>Странно ты воспринимаешь , агресивно . Я например пишу на многих языках , в том числе и на яве и на C# и С и С++ . Почему ты на меня переносишь СВОИ проекции . ?

У люди которые одинаково много пишут на разных языках синдром кастовости обычно почти не проявляется. Более того они обычно более адекватно воспринимают разные мнения о языках. Так что ты видимо не тот случай. Но тех случаев тут хватает.

Здравствуйте, Дарней, Вы писали:

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

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

Здравствуйте, AndreyFedotov, Вы писали:
AF> Да знаем мы, знаем... Только сдаётся мне, что лет через 20 мы будем наблюдать шоу "Последний самурай", в котором мерзопакостный молодняк будет лезть со своим Oberoid##, а кое-кто от них будет отмахиваться Generic'ами и приводить в качестве примера статистику с миллионами приложений, написаных на C#
А чего долго ждать? Если к дженерикам второго шарпа народ был более-менее психологически готов, то обычная первая реакция шарпдевелопера на LINQ из тройки совершенно нецензурна. Хейльсберг еще молод, так что в ближайшие десять лет я ожидаю наблюдать развернутую борьбу девелоперов с собственными предрассудками. Когда те, кто уже постиг очередной уровень, бегают с выпученными глазами и орут, как все круто, а те, кто еще нет, в упор не понимают нахрена оно вообще, при этом с остервенением отбиваясь от тех, кто еще не понял даже скрытого смысла автоматической сборки мусора

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А что касается вывода, то ошибка в спецификации строки вывода ловится только в рантайме. Вот такое
PD> float f = 9;
PD> Console.WriteLine("{0,8:d}", f);
PD>компилируется на ура
PD>А вот такое
PD> Console.WriteLine("{0,8:d}");
PD>и вообще работает, только выводит не то, что автор хотел , а то, что здесь есть.
Ты будешь смеяться, но есть такой тул, как ReSharper. Он прекрасно отлавливает вот эту ситуацию. И, в принципе, не исключено, что в следующей версии отловит и первую ошибку.

Здравствуйте, eao197, Вы писали:

E>Как мне кажется, не так уж много программистов смогут одинаково эффективно работать на нескольких (больше трех) языках и использовать разные платформы. Даже в достаточно близких языках, таких как C++, Java, C# есть свои идиомы. Поэтому многое, что мы привыкли делать в C++ (шаблоны, RAII), в Java уже бесполезно. То, что в Java или C# элементарно выполняется с помощью рефлекшена, в C++ достигается долгими экспериментами со сторонними библиотеками или самописным велосипедом. Переключение между этими языками уже требует переключения сознания на другой способ оценки задачи и способов ее решения.

E>А если взять более далекие друг от друга языки?

Давай возьмем.
Вот Типичное Современное Приложение. Это маахонький веб сайт.
Он написан с использованием:
SQL для бэкенда
VB.NET для миддл-тайер
JScript для клиент презентейшн.
Достаточно далекие языки? А тем не менее, пишется все командой в полтора человека, а при необходимости и в одного. Что, мало такого народу?
Конечно, больше тех, кто владеет только двумя смежными технологиями. Ну скажем SQL+C#, или HTML/CSS/JScript+VBScript... Теи не менее, нет никакой проблемы работать одновременно на двух языках, один из которых декларативный, а другой — императивный. Поначалу трудно работать на синтаксически близких языках. Но это проходит с тренировкой.

Здравствуйте, GlebZ, Вы писали:

Ввиду того, что я выступил с мирной инициативой, в дискуссии по языкам не участвую. замечание только по одному моменту.


GZ>+1. Только есть некоторая разница. Это компилятор посчитал ее предупреждением. Хотя и ясно, что подобная ошибка предупреждением быть не может. Непонятно о чем думали разработчики компилятора.

Правильно они думали. Если Вас это не устраивает — поставьте

/WX Treats all warnings as errors. For a new project, it may be best to use /WX in all compilations; resolving all warnings will ensure the fewest possible hard-to-find code defects.

и наслаждайтесь. А вот наоборот, увы, не получится — error не обойдешь. Поэтому если что-то хоть в 1% случаев может быть верным (хитрость программиста), то не надо это запрещать. Пусть сам запрещает, если хочет.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Правильно они думали. Если Вас это не устраивает — поставьте

PD>/WX Treats all warnings as errors. For a new project, it may be best to use /WX in all compilations; resolving all warnings will ensure the fewest possible hard-to-find code defects.
Warning все таки нужны. Их цель ты правильно определил. Обман компилятора. И чтобы об этом не забывали. Хочешь забыть — пиши прагму.

PD>и наслаждайтесь. А вот наоборот, увы, не получится — error не обойдешь. Поэтому если что-то хоть в 1% случаев может быть верным (хитрость программиста), то не надо это запрещать. Пусть сам запрещает, если хочет.
Вот мне хотелось бы узнать, в чем может состоять хитрость программиста. Если бы я знал хотя бы об одном потенциальном способе использования такого кода, то я не против. Но этого способа я не знаю.

С уважением, Gleb.

Здравствуйте, Sinclair, Вы писали:

S>Ты будешь смеяться, но есть такой тул, как ReSharper. Он прекрасно отлавливает вот эту ситуацию. И, в принципе, не исключено, что в следующей версии отловит и первую ошибку.

Я не буду смеяться, но вроде бы в Unix был когда-то tool , который отлавливал несоответсвия всякие в С программах еще когда С++ не было. В частности, несоответствия между описанием функции и ее вызовом (если помнишь, в версии С Кернигана-Ритчи прототипов не было, а вызывать неописанную функцию в С даже сейчас компилятор позволит, предупреждение, правда, будет. Не исключаю, что и для C++ такие тулзы либо есть, либо их можно написать. Но мне они не нужны.

Здравствуйте, Sinclair, Вы писали:

E>>А если взять более далекие друг от друга языки?

S>Давай возьмем.
S>Вот Типичное Современное Приложение. Это маахонький веб сайт.

Может быть веб-сайт и является Типичным Современным Приложением (хотя, имхо, нужно было бы сказать, что только в одной области), то вот "маахонький" -- это совершенно не пример. Команды в 1.5-2-3-3.25 человек -- они по своему живут, многие вещи там гораздо проще. А вот если объем проекта за 250 тысяч строк переваливает, и команда от десятка человек, тут уже другие законы. Имхо, опять же.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Позволю себе вмешаться. Синтаксическую ошибку в программе VladD2 компилятор нашел, но посчитал ее предупреждением. Не обращать внимание на предупреждения не стоит ни в С++, ни в С#. Как минимум, надо на них посмотреть и решить, стоит ли игнорировать, а лучше вообще убрать.

Несомненно. Но вот если уж компилятор считает сообщение не важным, то ошибка ну, никак не должна приводить к разным AV/GPF. А именно такой случай мы имеем.

PD>А что касается вывода, то ошибка в спецификации строки вывода ловится только в рантайме. Вот такое

> float f = 9;
PD> Console.WriteLine("{0,8:d}", f);

PD>компилируется на ура


PD>А вот такое

PD> Console.WriteLine("{0,8:d}");

PD>и вообще работает, только выводит не то, что автор хотел , а то, что здесь есть.

Понимаш ли, есть огромная разница между логическими ошибками и ошбками вроде описаной в теме. В Шарпе без ансэйва ты просто не сможешь повредить память, а в данном случае неверно поставленная скобка привела именно к повреждению памяти. И слава богу, что все было относительно безопасно. Как-то я видел намного более забавную ошибку. Человек в следствии сложных манипуляций возвратил их функции указатель на стековую переменную. Какое-то время код даже работал, а потом... потом были 2 недели поиска ошибки.

Здравствуйте, VladD2, Вы писали:

VD>Понимаш ли, есть огромная разница между логическими ошибками и ошбками вроде описаной в теме. В Шарпе без ансэйва ты просто не сможешь повредить память, а в данном случае неверно поставленная скобка привела именно к повреждению памяти. И слава богу, что все было относительно безопасно. Как-то я видел намного более забавную ошибку. Человек в следствии сложных манипуляций возвратил их функции указатель на стековую переменную. Какое-то время код даже работал, а потом... потом были 2 недели поиска ошибки.
Как-то пришлось подключать библиотеку, которая в своей функции удаляло строку, а потом создавала свою вместо нее. Долго разбирался. Сначала долго разбирался с ошибкой поскольку строку по незнанию я создавал в стеке. Потом долго выбивал из них, хотя бы скомпиленную библиотеку с msvcrt.dll, поскольку ихнюю строку должен был удалять уже я. Пробивать нормальный интерфейс от них по некоторым причинам было нельзя.

С уважением, Gleb.

Здравствуйте, Kluev, Вы писали:

K>Но вернемся к теме, для чего вообще я это пишу? Да просто С++ единственный язык котороый позволяет писать такие вещи без боли в области головы и заднего прохода .

А что-нибудь ещё кроме списков он умеет?

K>А еще меня очень сильно прет partal specialization для геометрических примитивов:

Watch this:

public abstract class Person : ObjectBase
{
  [Required, MaxValue(50)] public abstract string FirstName { get; set; }
  [Required, MaxValue(50)] public abstract string LastName  { get; set; }
                           public abstract Gender Gender    { get; set; }
  [MaxValue(100)]          public abstract string Address   { get; set; }
}

В результате имеем:

1. EditableObject с возможностью принятия/отката изменений и проверки флага IsDirty.
2. Маппинг во что угодно и из чего угодно (БД, XML и т.п.).
3. Визуальный баиндинг на контролы, включая гриды.
4. Автоматическую валидацию с подсветкой контролов и/или исключениями.
5. Базовый DataAccessor с готовыми основными CRUDL операциями.
6. Возможность тонкой настройки всего вышеперечисленного декларативными средствами.

Всё это без потери производительности, наглядности и тухлых указателей.

Сможешь такое на C++?

K>А cтрашилки про printf — это просто развод для лохов. Всю жизнь юзаю sprintf т.к. iostream не люблю и ничего, ни одной ошибки еще не было. Вот попробуй на С# повтори те упражнения что я здесь привел, тогда и поговорим.

Повторить что, твой код или решение конечной задачи?

Здравствуйте, eao197, Вы писали:

E>Может быть веб-сайт и является Типичным Современным Приложением (хотя, имхо, нужно было бы сказать, что только в одной области),
Просто в этой области выпускаются сотни приложений в день.
E>то вот "маахонький" -- это совершенно не пример. Команды в 1.5-2-3-3.25 человек -- они по своему живут, многие вещи там гораздо проще.
Какие вещи? Мы все еще говорим о лингвистических способностях или уже о чем?
E>А вот если объем проекта за 250 тысяч строк переваливает, и команда от десятка человек, тут уже другие законы. Имхо, опять же.
Я правильно понимаю, что ты считаешь такие проекты прибежищем для людей, неспособных программировать на трех языках?

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я не буду смеяться, но вроде бы в Unix был когда-то tool , который отлавливал несоответсвия всякие в С программах еще когда С++ не было. В частности, несоответствия между описанием функции и ее вызовом (если помнишь, в версии С Кернигана-Ритчи прототипов не было, а вызывать неописанную функцию в С даже сейчас компилятор позволит, предупреждение, правда, будет. Не исключаю, что и для C++ такие тулзы либо есть, либо их можно написать. Но мне они не нужны.
Я тоже не исключаю возможности таких средств для C++. Хотя, конечно, писать их значительно труднее.

Здравствуйте, VladD2, Вы писали:

VD>Как-то я видел намного более забавную ошибку.

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

Здравствуйте, Чипсет, Вы писали:

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

Я 12 лет был гениальным... я устал.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Чипсет, Вы писали:

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

IT>Я 12 лет был гениальным... я устал.

Дело не в гениальности конкретного человека а в том как компилятор оценивает программиста