auto_ptr<MyClass> myPtrs[10];
cout << sizeof(myPtrs) / sizeof(auto_ptr<MyClass>);
плюсы и минусы С++ и Delphi
Чотелось бы узнать разные мнения по поводу этих языков программирования... Заранее спасибо:)
Цитата: Kogrom
Я уловил следующее: он говорил, что у C++ плохие макросы, которые не позволяют сделать много во время компиляции программы, не позволяют "расширить" язык.
Если он еще что-то говорил - требую расшифровать в доступной форме :)
Если он еще что-то говорил - требую расшифровать в доступной форме :)
да макросы тут ни при чем... и вообще сам язык ни причем...
общий смысл - профессионал должен обладать широким спектром инструментов и под каждую задачу выбирать свой наиболее подходящий (причем по приведенным им доводам цпп находится в самой заднице иерархии этих инструментов)
Цитата: Washington
оксотник, я тебя прощаю... ))
зеленым квадратиком принимаю дары... ну или коньяком :)
Цитата: oxotnik333
да макросы тут ни при чем... и вообще сам язык ни причем...
общий смысл - профессионал должен обладать широким спектром инструментов и под каждую задачу выбирать свой наиболее подходящий
общий смысл - профессионал должен обладать широким спектром инструментов и под каждую задачу выбирать свой наиболее подходящий
Это и без него понятно. Тут он ничего нового не сказал.
Цитата: oxotnik333
(причем по приведенным им доводам цпп находится в самой заднице иерархии этих инструментов)
Вот. Требую расшифровать, почему этот инструмент плох. Какие доводы были? Если довод про foreach - то это как раз про макросы.
В пылу дискуссии забыли мы об одной вещи. Зачастую язык и инстумент программирования выбирается не только исходя из личных предпочтений программиста и задачи, но также и так скажем и "традиций".
Пришел я на новое место и посадилим меня за большой проект, который разработан уже очень давно. И если этот проект написан на C++, то не имеет значения на каком месте иерархии находится C++, не имеет значение мое к нему отношение. Проект уже написан на C++ и я буду дорабатывать его на этом языке.
Пришел я на новое место и посадилим меня за большой проект, который разработан уже очень давно. И если этот проект написан на C++, то не имеет значения на каком месте иерархии находится C++, не имеет значение мое к нему отношение. Проект уже написан на C++ и я буду дорабатывать его на этом языке.
Цитата: Kogrom
Вот. Требую расшифровать, почему этот инструмент плох. Какие доводы были? Если довод про foreach - то это как раз про макросы.
двумя словами: ты не решаешь задачу средствами языка а ищешь способ как втиснуть эту задачу в возможности языка.
Для примера возьмем C# vc C++
в первом - создал объект, поработал и забыл - остальное за тебя автоматом все сделают
во втором: надо либо самому следить за уничтожением, либо знать (причем со всеми тонкостями) что есть оказывается такие шаблоны, которые следят за временем жизни объекта.
Цитата: nikitozz
Проект уже написан на C++ и я буду дорабатывать его на этом языке.
Ну никто же силком не тянул на это место работы? ;)
[quote=Kogrom]Я уловил следующее: он говорил, что у C++ плохие макросы, которые не позволяют сделать много во время компиляции программы, не позволяют "расширить" язык.[/quote]Это одна из причин, почему тот мужик считает C++ наиболее неприемлемым инструментом программиста.
Цитата: oxotnik333
Для примера возьмем C# vc C++
в первом - создал объект, поработал и забыл - остальное за тебя автоматом все сделают
во втором: надо либо самому следить за уничтожением, либо знать (причем со всеми тонкостями) что есть оказывается такие шаблоны, которые следят за временем жизни объекта.
в первом - создал объект, поработал и забыл - остальное за тебя автоматом все сделают
во втором: надо либо самому следить за уничтожением, либо знать (причем со всеми тонкостями) что есть оказывается такие шаблоны, которые следят за временем жизни объекта.
Неудачный пример. Сборщик мусора - это по мнению Xenocephal средство, позволяющее не бояться, что "обезьяна прострелит себе ногу":
[QUOTE=Xenocephal]Java - это типичный bondage&discipline language, созданный с единственной целью - выкрутить руки разработчикам. Он очень сильно ограниченный, и в нем сложно решить одну задачу более чем одним способом. Плюсы такого подхода - можно позволить программировать на нем всяким убогим дуракам. Так же - тупой и примитивный язык лучше поддается автоматизированному анализу, отсюда и такое количество свистелок и ... в жабских IDE, да и серьезных систем статического анализа хватает. Но за это приходится платить низким уровнем абстракции, невозможностью легко и красиво реализовывать сложные идеи.[/QUOTE]
О C# он лучшего мнения, но по другим причинам.
То есть, сборщик мусора - это приятная мелочь и все.
Ну, в общем, смысл ясен.
Цитата: Kogrom
Путаница во второй половине высказывания. Надо: "а ищешь подходящий для задачи язык".
Сказал именно то, что хотел сказать.
А именно: на С++ не решаешь задачу (основное время тратится на сам язык) а пытаешься ее впихнуть в в средства языка.
Цитата: Kogrom
Неудачный пример. Сборщик мусора - это по мнению Xenocephal средство, позволяющее не бояться, что "обезьяна прострелит себе ногу":
О C# он лучшего мнения, но по другим причинам.
То есть, сборщик мусора - это приятная мелочь и все.
Пример был дан для того, что бы понять, что язык (среда) абстрагирует разработчика от головной боли (в частности отслеживания жизни объектов)
Другой пример:
Массивы C# представлены объектом, в котором есть такое замечательное свойство как количество элементов. Т.е. это уже фича самого языка.
в плюсах же (без использования векторов) довольно проблематично.
Цитата: oxotnik333
Сказал именно то, что хотел сказать.
А именно: на С++ не решаешь задачу (основное время тратится на сам язык) а пытаешься ее впихнуть в в средства языка.
А именно: на С++ не решаешь задачу (основное время тратится на сам язык) а пытаешься ее впихнуть в в средства языка.
Я стер свое замечание, но поздно :)
Цитата: oxotnik333
Массивы C# представлены объектом, в котором есть такое замечательное свойство как количество элементов. Т.е. это уже фича самого языка.
в плюсах же (без использования векторов) довольно проблематично.
в плюсах же (без использования векторов) довольно проблематично.
Ну, в принципе, можно через sizeof вытащить в определенных случаях. Но в общем - да.
А чем вектора не устраивают? Единственное, что мне в них не нравится - неудобная инициализация, в случае, если начальные значения элементов разные.
Цитата: Kogrom
А чем вектора не устраивают? Единственное, что мне в них не нравится - неудобная инициализация, в случае, если начальные значения элементов разные.
Да. Но это не недостаток vector. Это особенность auto_ptr.
Цитата: Kogrom
Да. Но это не недостаток vector. Это особенность auto_ptr.
Недостаток контейнеров в том что они накладывают определенные требования/ограничения к помещаемым туда объектам, и это дело заранее не предусмотрено на уровне самого языка.
Т.е. возвращаясь к предыдущим примерам: я не могу с легкостью использовать автовыделение/очистку памяти для элементов массива, с тем условием что бы мне в любой точке кода иметь возможность безгеморойно узнать размер массива.
Цитата: oxotnik333
Недостаток контейнеров в том что они накладывают определенные требования/ограничения к помещаемым туда объектам, и это дело заранее не предусмотрено на уровне самого языка.
Можно посмотреть на это дело с другой стороны. На уровне языка включена возможность создавать объекты, которые можно запретить включать в контейнер :)
Хотя нужность такой возможности под вопросом.
Цитата: oxotnik333
Т.е. возвращаясь к предыдущим примерам: я не могу с легкостью использовать автовыделение/очистку памяти для элементов массива, с тем условием что бы мне в любой точке кода иметь возможность безгеморойно узнать размер массива.
Можно. Если объекты одного типа, то и добавляйте/удаляйте сами объекты, а не указатели на них. Всё просто.
Другое дело, когда в контейнер надо затолкать объекты разных типов. В данном случае, языки со сборкой мусора, действительно, удобнее.
Добавлено позже.
Да и вообще, не так уж сложно определить размер массива, например
Код:
если не нравится, что много букв, можно определить соответствующий макрос.
Что значит --- мы не знаем другие языки и оттого сказать ничего не можем?
Мы знаем много разных языков.
Мы знаем много разных языков.
Цитата: oxotnik333
Недостаток контейнеров в том что они накладывают определенные требования/ограничения к помещаемым туда объектам, и это дело заранее не предусмотрено на уровне самого языка.
По-конкретнее, плз.
Цитата: oxotnik333
Т.е. возвращаясь к предыдущим примерам: я не могу с легкостью использовать автовыделение/очистку памяти для элементов массива, с тем условием что бы мне в любой точке кода иметь возможность безгеморойно узнать размер массива.
Почему ты скачешь с контейнеров на массивы?
Определить размерность массива не представляет сложностей, так же, как и размер контейнера.
Или я опять что-то не понял твоей мысли. Конкретизируй, плз.
Цитата: Green
По-конкретнее, плз.
Конструктор копирования например.
Цитата: Green
Почему ты скачешь с контейнеров на массивы?
Определить размерность массива не представляет сложностей, так же, как и размер контейнера.
Или я опять что-то не понял твоей мысли. Конкретизируй, плз.
в данном случае я имел ввиду std::vector - как заменитель массива.
объясни плз, как в таком случае в теле ф-ции получить размер массива:
Код:
void SomeFunc (int *array)
{
// сколько элементов в массиве array?
}
{
// сколько элементов в массиве array?
}
Цитата: Kogrom
Да и вообще, не так уж сложно определить размер массива, например
Код:
auto_ptr<MyClass> myPtrs[10];
cout << sizeof(myPtrs) / sizeof(auto_ptr<MyClass>);
cout << sizeof(myPtrs) / sizeof(auto_ptr<MyClass>);
ну а в таком случае:
Код:
int *a = new int[N]; // N- ранее вычисляется
Цитата: Zorkus
Что значит --- мы не знаем другие языки и оттого сказать ничего не можем?
Мы знаем много разных языков.
Мы знаем много разных языков.
Ну, я про себя говорил, конечно. Да и знание знанию не равно.
Например, мой зоопарк:
1. Паскаль - сравнительно неплохо знал.
2. Дельфи. На этом языке программировал в паскалевском стиле. То есть, не делал своих объектов. ООП в нем изучил после того, как перестал на нем программировать.
3. ActionScript - программировал в паскалевском стиле.
4. JavaScript - также паскаль...
5. Ассемблер для контроллеров. Наверно, программировал в ассемблерном стиле.
6. C - паскаль...
7. C++. Впервые попытался оторваться от Паскаля. Вроде, получилось.
8. Python начал изучать - стиль C++ использую пока...
Зоопарк вроде большой, но смысла от него нет. Ну, единственный плюс - могу прогу с Дельфей на C++ перевести, если в ней нет использования хитрых компонент. А так, получается, что я только на Паскале и C++ программировал. И, в общем, не могу сравнивать языки.
Вот такая грустная картина. А по тому, что говорили другие участники темы, сделал вывод, что и остальным сказать особо нечего.
Тема побила все рейтинги популярности!
[COLOR="Silver"]…простите за мой оффтоп,который,конечно же,идёт в разрез с этой тролльской темой…[/COLOR]
По теме:ИМХО,нельзя сравнивать эти языки программирования(равно как и IDE)–ну они ооочень разные!Повторюсь–это сугубо моё личное мнение
[COLOR="Silver"]…простите за мой оффтоп,который,конечно же,идёт в разрез с этой тролльской темой…[/COLOR]
По теме:ИМХО,нельзя сравнивать эти языки программирования(равно как и IDE)–ну они ооочень разные!Повторюсь–это сугубо моё личное мнение
Цитата: oxotnik333
Конструктор копирования например.
Ну и в чем сложность, в чем ограничения?
Кто-то запрещает создать конструктор копирования?
Да и создавать его надо в том случае, если нет дефолтного, а его нет сам знаешь в каких случаях.
Давай сравним с тем же C#. Там в контейнерах объекты классов хранятся по ссылке, поэтому копирования не надо. Если в C++ хранить объекты по ссылке (естественно, имеется в виду указатель обычный или умный), то так же конструктора копирования не понадобиться.
Цитата: oxotnik333
в данном случае я имел ввиду std::vector - как заменитель массива.
объясни плз, как в таком случае в теле ф-ции получить размер массива:
Код:
void SomeFunc (int *array)
{
// сколько элементов в массиве array?
}
{
// сколько элементов в массиве array?
}
А здесь в функцию массив не передается.
Я уже неоднократно рассказывал о том, как часто путают массив и указатель на первый элемент.
Ты в C# передав ссылку на первый элемент сможешь определить размерность массива? Думаю, что нет.
Для того, чтобы в функции определить размерность массива его надо, для начала, передать в функцию. :)
Теперь другое заблуждение. Хоть массивы существуют и в С++ и в C#, но несмотря на одинаковое название, это разные сущности. В C# - это класс, а в C++ - это специфичный тип, не сруктура и не класс. Аналогом же массива C# в C++ будет vector, а не массив.
Если потребуется, могу показать, как в C++ в функцию передать именно массив, а не указатель на первый элемент. И, соотв-но, как получить размер переданного массива.
P.S. Только вот к топику это обсуждение уже не имеет отношения.
Цитата: Green
Ну и в чем сложность, в чем ограничения?
Кто-то запрещает создать конструктор копирования?
Да и создавать его надо в том случае, если нет дефолтного, а его нет сам знаешь в каких случаях.
Кто-то запрещает создать конструктор копирования?
Да и создавать его надо в том случае, если нет дефолтного, а его нет сам знаешь в каких случаях.
в том то и дело что его надо создавать, что является доп. гемороем, отвлекающим от решения задачи
Цитата: Green
Давай сравним с тем же C#. Там в контейнерах объекты классов хранятся по ссылке, поэтому копирования не надо. Если в C++ хранить объекты по ссылке (естественно, имеется в виду указатель обычный или умный), то так же конструктора копирования не понадобиться.
простой пример из MFC (хотя возможно это библиотека не очень
прямая)
Код:
class CSomeClass
{
vector<CDBVariant>m_fldVals;
....
};
void CSomeClass::SomeFunc(...)
{
CRecordset rs(this);
...
CDBVariant fldVal;
rs.GetFieldValue(FieldName.c_str(), fldVal);
m_fldVals[n] = fldVal;
}
{
vector<CDBVariant>m_fldVals;
....
};
void CSomeClass::SomeFunc(...)
{
CRecordset rs(this);
...
CDBVariant fldVal;
rs.GetFieldValue(FieldName.c_str(), fldVal);
m_fldVals[n] = fldVal;
}
дефолтовый конструктор копирования не решает поставленных задач
после выхода из ф-ции m_fldVals[n].m_pstring = <Bad Ptr>
Цитата: Green
Теперь другое заблуждение. Хоть массивы существуют и в С++ и в C#, но несмотря на одинаковое название, это разные сущности. В C# - это класс, а в C++ - это специфичный тип, не сруктура и не класс. Аналогом же массива C# в C++ будет vector, а не массив.
в общем то я уже об этом уже говорил, что это фича языка
PS: производительность шарписта будет больше плюсника при равных условиях
Цитата: oxotnik333
в том то и дело что его надо создавать, что является доп. гемороем, отвлекающим от решения задачи
Ну конструктор копирования создавать не обязательно. Это нужно лишь в некоторых случаях. В частности тогда, когда ты смешиваешь стили программирования. О чем и ярко говорит твой след. пример:
Цитата: oxotnik333
простой пример из MFC (хотя возможно это библиотека не очень
прямая)
Код:
class CSomeClass
{
vector<CDBVariant>m_fldVals;
....
};
void CSomeClass::SomeFunc(...)
{
CRecordset rs(this);
...
CDBVariant fldVal;
rs.GetFieldValue(FieldName.c_str(), fldVal);
m_fldVals[n] = fldVal;
}
{
vector<CDBVariant>m_fldVals;
....
};
void CSomeClass::SomeFunc(...)
{
CRecordset rs(this);
...
CDBVariant fldVal;
rs.GetFieldValue(FieldName.c_str(), fldVal);
m_fldVals[n] = fldVal;
}
дефолтовый конструктор копирования не решает поставленных задач
после выхода из ф-ции m_fldVals[n].m_pstring = <Bad Ptr>
m_pstring - это, на сколько понимаю (я не знаю MFC), это C-string.
А вот если не смешивать стили и писать на C++, т.е. использовать класс string вместо C-string, то конструктора копирования определять не придется.
Цитата: oxotnik333
в общем то я уже об этом уже говорил, что это фича языка
Именно, что фича, а не ограничение.
В C# нет альтернативы массива C++.
А в C++ есть альтернатива массива C#.
И сравнивать массив C++ и массив С# некорректно.
Это все равно, что сравнивать колесо обозрения и рулевое колесо.
Цитата: oxotnik333
PS: производительность шарписта будет больше плюсника при равных условиях
Это глупое холливарное утверждение я даже не буду обсуждать.
Цитата: oxotnik333
ну а в таком случае:
Код:
int *a = new int[N]; // N- ранее вычисляется
Стандартных способов нет. И, думаю, это упущение, так как размер этот где-то хранится, ведь в delete он прямо не передается. В некоторых реализациях языка есть некая функция _msize, но насколько корректно она работает - не знаю.
С другой стороны, контейнеры STL меня тоже не всем устраивают. Например, мне не достает способов инициализации. Например, чтобы инициализировать элементы контейнера разными значениями мне приходится создавать дополнительный обычный массив. Вроде бы, это правильно по логике языка, но неудобно.
Цитата: Kogrom
С другой стороны, контейнеры STL меня тоже не всем устраивают. Например, мне не достает способов инициализации. Например, чтобы инициализировать элементы контейнера разными значениями мне приходится создавать дополнительный обычный массив. Вроде бы, это правильно по логике языка, но неудобно.
А как бы ты хотел инициализировать?
Цитата: Green
m_pstring - это, на сколько понимаю (я не знаю MFC), это C-string.
А вот если не смешивать стили и писать на C++, т.е. использовать класс string вместо C-string, то конструктора копирования определять не придется.
нет, это CString* MFC-шный такойже контейнер строки как и std::string
Цитата: Green
Именно, что фича, а не ограничение.
В C# нет альтернативы массива C++.
А в C++ есть альтернатива массива C#.
И сравнивать массив C++ и массив С# некорректно.
Это все равно, что сравнивать колесо обозрения и рулевое колесо.
я сравниваю всего лишь удобство использования
Цитата: Green
Это глупое холливарное утверждение я даже не буду обсуждать.
сорри, я не правильно выразился...
правильней будет, что абстракция С++ весьма не высокая, и помимо решения задачи приходится делать кучу посторонних (не являющихся частью самой задачи) движений.
Цитата: oxotnik333
нет, это CString* MFC-шный такойже контейнер строки как и std::string
Ты лукавишь или не видишь разницы между CString* и CString ? :)
Цитата: oxotnik333
я сравниваю всего лишь удобство использования
Ну и чем vector неудобнее?
Цитата: oxotnik333
сорри, я не правильно выразился...
правильней будет, что абстракция С++ весьма не высокая, и помимо решения задачи приходится делать кучу посторонних (не являющихся частью самой задачи) движений.
Да точно такая же "абстракция", как у C#. Во всяком случае в контексте твоего повествования.
Что бы не делать лишних движений, используй уже готовые движения.
Отличие от C# только в том, что там движения зашиты в базу, а в C++ надо сделать выбор (STL, Boost, Qt и т.д.).
P.S. Я не собираюсь спорить что лучше или на чем быстрее... это ГЛУПО!
Есть вопросы по C++, в т.ч. по аналогии с C#, задавайте.
Но только вот глупости по поводу того, что в C# массив лучше, чем в C++ писать не надо. ;)
Цитата: Green
Именно, что фича, а не ограничение.
Таких фич вон знаем: можно исключения перехватывать и по значению, и тебе по указателю, и даже по ссылке... Можно. А нужно - по ссылке. Ну и на фиг такие фичи? Лучше б файнали прикрутили. А void* зачем?
А Охотник ведь толкает замечательнейшую в этом топике мысль.
Да зачем мне десять лет учить С++ вместо того, чтобы десять лет учиться программировать?
Цитата: Green
В C# нет альтернативы массива C++
В рамках одного метода есть unsafe код и fixed конструкция - можно получить указатель на что угодно. Также есть stackalloc - способ выделения памяти на стеке.
[quote=Green]А вот если не смешивать стили и писать на C++, т.е. использовать класс string вместо C-string, то конструктора копирования определять не придется.
[/quote]А сколько нужно учиться чтобы не смешивать стили?
[quote=Kogrom]Стандартных способов нет. И, думаю, это упущение, так как размер этот где-то хранится, ведь в delete он прямо не передается. В некоторых реализациях языка есть некая функция _msize, но насколько корректно она работает - не знаю.
[/quote]_msize, если она есть, вернет блок памяти, в который влез требуемый блок памяти. Часто менеджеры памяти выделяют блоки памяти кратные степени двойки - 8, 16, 32 байта (и т.д.)
мне кажецо, что вы тут норкоманете!
Цитата: Der Meister
Таких фич вон знаем: можно исключения перехватывать и по значению, и тебе по указателю, и даже по ссылке... Можно. А нужно - по ссылке.
Кто сказал, что нужно по ссылке?
Патамушта так в C# ?
Цитата: Der Meister
Лучше б файнали прикрутили.
А зачем?
Патамушта так в C# ?
Цитата: Der Meister
А void* зачем?
В основном, для обратной совместимости с языком C.
Цитата: hardcase
В рамках одного метода есть unsafe код и fixed конструкция - можно получить указатель на что угодно. Также есть stackalloc - способ выделения памяти на стеке.
Это будет альтернатива C-шному malloc, но не массиву C++. Нужно объяснять почему?
Цитата: Der Meister
А сколько нужно учиться чтобы не смешивать стили?
Ты о времени или мозгах? :)
Цитата: Der Meister
А Охотник ведь толкает замечательнейшую в этом топике мысль.
Да зачем мне десять лет учить С++ вместо того, чтобы десять лет учиться программировать?
Ну я не думаю, что Оксотник толкает такую идиотскую мысль.
Зачем десять лет учить русский вместо того чтобы десять лет учиться писать стихи?
И если у кого-то при изучении С++ возникают трудности с изучением программирования, то это... (как-бы по-корректнее выразиться) .. личные особенности этого индивидуума. И эти "особенности" не красят его как инженера. Вы бы ещё привели как аргумент количество книг на русском языке.
Вы сейчас пытаетесь смотреть на один язык через призму другого.
Если бы в C++ было бы все так же как в C#, это был бы уже C#, а не С++.
А давайте, попробуем взглянуть с т.з. функционального программирования.
Нафига вообще структуры и классы? Зачем всякие там исключения? Что за дурацкая идея с контейнерами и какими-то массивами?
Это все не надо для программирования!
Зачем учить все это и прочую ерунду, чтобы программировать?
А может, просто, перестать заниматься глупостями - сравнивать два (и более) разных языка программирования?
Цитата: Green
А как бы ты хотел инициализировать?
Например, хочу так:
vector<int> myVector = {36, 25, 88, 1, 14, 72, 76};
А приходится примерно так:
int myMass[] = {36, 25, 88, 1, 14, 72, 76};
vector<int> myVector(myMass, myMass + 7);
Цитата: Green
А может, просто, перестать заниматься глупостями - сравнивать два (и более) разных языка программирования?
Сравнивать надо. Не надо делать дурацкие выводы. Однако, сложно удержаться.
Надо сравнивать примерно так: в этом языке есть такая-то фича, а в этом нет. Но не так: в этом языке нет такой-то фичи - он убог и бесполезен. Не надо делать выводы вслух.
Добавил позже:
И вообще, зачем сравнивать популярные (в бывшем СССР) языки, типа C++, Java, C#, Delphi. Таких сравнений полно в сети. Лучше бы поговорили о преимуществах менее известных языков.
Пару человек на форуме как заклинание повторяют "немерле, немерле". Ну и чем знаменит этот язык? Что вам в нем нравится?
Цитата: Green
А давайте, попробуем взглянуть с т.з. функционального программирования.
Нафига вообще структуры и классы? Зачем всякие там исключения? Что за дурацкая идея с контейнерами и какими-то массивами?
Это все не надо для программирования!
Зачем учить все это и прочую ерунду, чтобы программировать?
В функциональном программировании (лямбда-исчислении) нет массивов, возможно. В теории лямбда-исчисления я не особо силен.
Но в функциональных языках они есть (хотя бы потому что реализация массивов как функций индексы->значения не очень эффективна).
В Хаскелле, например, массив рассматривается как абстрактный тип данных с операцией индексирования.
Есть и структуры данных, пользовательские типы, контейнеры (в другом виде чем в С++, естественно, но есть).
prooflinks:
http://www.rsdn.ru/article/haskell/haskell_part1.xml
http://www.rsdn.ru/article/haskell/haskell_part2.xml
Цитата: Kogrom
Пару человек на форуме как заклинание повторяют "немерле, немерле". Ну и чем знаменит этот язык? Что вам в нем нравится?
Существует класс задач, которые невозможно решить с помощью темплейтов и генериков. К примеру, создание интерфейса взаимодействия с СУБД, осонванного на вызовах хранимых процедур. Логично сделать так, чтобы было однозначное отображение хранимой процедуры в БД и соответствующего ей метода в некотором классе. Решая задачу в-лоб приходится писать код примерно такого вида:
Код:
public class DataAccess {
public List<MyObject> GetMyObjects(int param1, string param2) {
using(SqlCommand cmd = new SqlCommand("GetMyObjects")) {
cmd.Parameters.Add("@param2").Value = param1;
cmd.Parameters.Add("@param2").Value = param2;
using(SqlDataReader reader = cmd.ExecuteReader()) {
List<MyObjects> result = new List<MyObjects>();
if(reader.HasData) {
while(reader.Read()) {
MyObject obj = new MyObject();
obj.Field1 = (int)reader["field1"];
obj.Field2 = (string)reader["field2"];
result.Add(obj);
}
}
return result;
}
}
}
}
public List<MyObject> GetMyObjects(int param1, string param2) {
using(SqlCommand cmd = new SqlCommand("GetMyObjects")) {
cmd.Parameters.Add("@param2").Value = param1;
cmd.Parameters.Add("@param2").Value = param2;
using(SqlDataReader reader = cmd.ExecuteReader()) {
List<MyObjects> result = new List<MyObjects>();
if(reader.HasData) {
while(reader.Read()) {
MyObject obj = new MyObject();
obj.Field1 = (int)reader["field1"];
obj.Field2 = (string)reader["field2"];
result.Add(obj);
}
}
return result;
}
}
}
}
Можно легко заметить что код по-сути обобщенный (generic), да только это обобщение в основном зависит от количества параметров метода.
В дотнете, в принципе, можно написать метод, который на основании отражения будет дергать хранимки, но отражение - это чертовски медленно (такой способ есть в LINQ).
Посему я создал кодогенератор. В рантайме. Кодогенератор получает на вход абстрактный тип вида:
Код:
public abstract class DataAccess {
[StoredProcedure("GetMyObjects")]
public abstract List<MyObject> GetMyObjects(int param1, string param2);
}
[StoredProcedure("GetMyObjects")]
public abstract List<MyObject> GetMyObjects(int param1, string param2);
}
Генерировать код в рантайме - зло. Также не говорите мне про разные инструменты генерации кода из xml описания, это тоже не ахти как клево - я не хочу выходить за рамки языка. Объявления на C# в данном случае читать приятнее чем нечеловеческий XML.
Компилятор во время своей работы обладает всей полнотой метаинформации, которая в принципе позволяет реализовать продемонстрированное обобщение кода. Просто инструмент таков, что мы не можем расширить его функционал и потому начинаются извращения с CodeDOM или Emit. А вот языки типа Nemerle (в Boo тоже можно) позволяют расширять возможности компилятора. Эти расширения назвываются макросами, и они не имеют ничего общего с макросами в C/C++. Однажды я портирую свои проекты на Nemerle (благо cs2n умеет конвертировать код) и все рантаймовые кодогенераторы сверну в макросы-метаатрибуты. Но это еще не все - есть возможности для изменения самого синтаксиса языка (я на досуге проектирую кое-какой e-DSL в немерлях).
Насколько я понял, подтверждается то, о чем я говорил. Жалко, что не был приведен код для сравнения. Но, в общем, примерно понятно.
Цитата: hardcase
А вот языки типа Nemerle (в Boo тоже можно) позволяют расширять возможности компилятора. Эти расширения назвываются макросами, и они не имеют ничего общего с макросами в C/C++.
Почитал про Boo. Понравилось. Есть подозрение, что мне, как человеку, не отягащенному знанием языка C#, будет ближе Boo, чем Nemerle.
А если сравнивать Boo и Nemerle - какие плюсы/минусы? (надеюсь, такой вопрос не вызовет священной войны)
Цитата: Kogrom
А если сравнивать Boo и Nemerle - какие плюсы/минусы? (надеюсь, такой вопрос не вызовет священной войны)
Boo не позволяет внедрять новый синтаксис. Работа с AST (дерево разбора программы) не такая изящная как в Nemerle.
Цитата:
Жалко, что не был приведен код для сравнения.
Еще не написал просто. Но он будет раз в 20 короче эквивалентного кодогенератора.
З.Ы. Boo - клевый язык (входит в поставку SharpDevelop, в Linux, кажется есть под MonoDevelop). Имхо лучше чем C#.
Цитата: Green
Кто сказал, что нужно по ссылке?
Патамушта так в C# ?
Патамушта так в C# ?
Код:
class ExceptionBase
{
public:
virtual SomeMethod() {
cout << "ExceptionBase::SomeMethod()" << endl;
}
virtual ~ExceptionBase() {
cout << "ExceptionBase::~ExceptionBase()" << endl;
}
};
class DerrivedException : public ExceptionBase
{
public:
virtual SomeMethod() {
cout << "DerrivedException::SomeMethod()" << endl;
}
virtual ~DerrivedException() {
cout << "DerrivedException::~DerrivedException()" << endl;
}
};
int main()
{
try {
throw DerrivedException();
}
catch (ExceptionBase ex) {
ex.SomeMethod(); // Ой!
}
try {
throw new ExceptionBase;
}
catch (ExceptionBase * ex) {
} // Но где же деструктор ExceptionBase?!
return 0;
}
{
public:
virtual SomeMethod() {
cout << "ExceptionBase::SomeMethod()" << endl;
}
virtual ~ExceptionBase() {
cout << "ExceptionBase::~ExceptionBase()" << endl;
}
};
class DerrivedException : public ExceptionBase
{
public:
virtual SomeMethod() {
cout << "DerrivedException::SomeMethod()" << endl;
}
virtual ~DerrivedException() {
cout << "DerrivedException::~DerrivedException()" << endl;
}
};
int main()
{
try {
throw DerrivedException();
}
catch (ExceptionBase ex) {
ex.SomeMethod(); // Ой!
}
try {
throw new ExceptionBase;
}
catch (ExceptionBase * ex) {
} // Но где же деструктор ExceptionBase?!
return 0;
}
Цитата: Green
А зачем?
Патамушта так в C# ?
Патамушта так в C# ?
А зачем топору топорище? Потомуха на балконе такой валяется?
Цитата: Green
Вы сейчас пытаетесь смотреть на один язык через призму другого.
Беспонтовый развод. Я сказал о феномене программирования на этом языке, и никаких намёков на сравнения в моей речи не звучало.
Зачем мне изобретать, как собрать из балалайки рояль, если мне нужно сыграть Иоганна Себастьяновича Бахова?
А то, может, попробуем взглянуть на это дело с точки зрения духовых инструментов? Зачем все эти клавиши да струны, что за дурацкая идея?
Цитата: Green
Ты лукавишь или не видишь разницы между CString* и CString ? :)
Ну и чем vector неудобнее?
Ну и чем vector неудобнее?
прекрасно вижу разницу... однако, потому что на уровне языка не предусмотрен конструктор копирования (по умолчанию) который скопирует объект вместе с его вложенностями (и создаст указатель на новый объект, иначе в чем смысл копирования), пришлось потерять какое то время на исправление этой "незаложенности". Все это замедляет решение основной задачи.
Цитата: Green
Что бы не делать лишних движений, используй уже готовые движения.
Отличие от C# только в том, что там движения зашиты в базу, а в C++ надо сделать выбор (STL, Boost, Qt и т.д.).
благодаря такому "зашитию в базу" язык абстрагирует пользователя от ненужных телодвижений. Про "трудности" STL - уже писал, boost - по твоим же словам - большая помойка (сорри если приукрасил).
Цитата: Green
P.S. Я не собираюсь спорить что лучше или на чем быстрее... это ГЛУПО!
Нигде не говорил что шарп "лучше" плюсов.
Цитата: Green
Но только вот глупости по поводу того, что в C# массив лучше, чем в C++ писать не надо. ;)
Нигде не говорил, что массивы шарпа "лучше" плюсов. Говорил лишь то, что в самой базе языка зашиты удобные фичи.
PS: Я всего лишь хотел сказать, что для определенного круга задач (не такого уж и маленького, где C# и С++ пересекаются на 100% по возможностям) большинству разработчиков, одинаково владеющих обоими этими средствами разработки, проще будет сделать на шарпе.
Цитата: oxotnik333
PS: Я всего лишь хотел сказать, что для определенного круга задач (не такого уж и маленького, где C# и С++ пересекаются на 100% по возможностям) большинству разработчиков, одинаково владеющих обоими этими средствами разработки, проще будет сделать на шарпе.
хм. а вот чисто любопытно - очертите плиз тот самый "немаленький" круг где согласно вашему утверждению си-шарп и си-плас-плас "пересекаются".
Потому как я согласен с Green - подобное утверждение - это архиглупость, но возможно правы и вы.
Цитата: hardcase
3-4 раза написать такой код - не проблема, но реальность такова, что количество хранимых процедур подступает к сотне и больше. Кароче тронешься мозгами пока накопипастишь и отладишь их. А еще бывает, что параметры в них меняются...
Можно легко заметить что код по-сути обобщенный (generic), да только это обобщение в основном зависит от количества параметров метода.
В дотнете, в принципе, можно написать метод, который на основании отражения будет дергать хранимки, но отражение - это чертовски медленно (такой способ есть в LINQ).
А ORM и вынос логики в middleware как вариант не рассматривается?
Цитата:
Генерировать код в рантайме - зло. Также не говорите мне про разные инструменты генерации кода из xml описания, это тоже не ахти как клево - я не хочу выходить за рамки языка. Объявления на C# в данном случае читать приятнее чем нечеловеческий XML.
А почему выходить за рамки языка - это не труъ?
У нас используется JAXB и схема базы данных генерится в процессе билда вместе с классами ORM, после чего поверх накладывается code injection в сгенеренные по XSD-схемам классы через sun.*.codemodel* API.
По моему опыту я бы сказал, что в Enterprise проекте где большая и довольно сложная база данных, со сложными бизнес-моделями, без ORM (как, конечно, и без хранимых процедур) в том или ином виде не обойтись. И хранимые процедуры, генерация Java кода на основе XML кода, ORM и кодогенарация разного уровня может в таком проекте вполне гармонично сочетаться. IMHO.[/QUOTE]
Цитата: Zorkus
А ORM и вынос логики в middleware как вариант не рассматривается?
Вопрос донельзя глуп: А чо это такое?
У меня на кодогенераторах и перзистент-объекты поднимаются с БД (хранимки с entry-объектами - это нижний уроень, тут еще кстати кэширование сделано).
Цитата: Zorkus
А почему выходить за рамки языка - это не труъ?
Это первый признак того, что язык не годится для решения стоящей задачи, разве не так?
Требуется дополнительный инструмент (xml-препроцессор), помимо компилятора.
Цитата: Zorkus
У нас используется JAXB и схема базы данных генерится в процессе билда вместе с классами ORM, после чего поверх накладывается code injection в сгенеренные по XSD-схемам классы через sun.*.codemodel* API.
А я вот предполагаю, что в немерле можно сделать без всякого XML и нечеловеческого codemodel апи (не думаю, что он лучше CodeDOM). Я с удовольствием бы занялся разработкой ORM двигла для Nemerle, ато народ вон уже почти LINQ реализовал, без изменений компилятора!