Доброго времени суток! Возник такой вопрос: Допустим у меня есть программа написанная на Visual C++ . Могу я в Visual C++ код этой программы перевести из С ,например, в Delphi ? Я знаю,что в той же Delphi такая возможность есть, то есть можно код,написанный на Дельфи переделать в любой другой(С++,Jawa и т.д.).

Есть такой механизм в С++ и если нет,то появится ли он в следующих версиях?

Зачем??? Ну если очень хочется поиметь проблемы, то ]]>ВОТ]]>

Покажи где

ух ты... а пацаны то не знают...

Это ж мотоцикл!

Спасибо за инфу! Только это - способ вручную,а я думал,что есть автоматический перевод.Типа нажал кнопку - код уже в Delphi . А нужно это потому ,что преподаватель слишком принципиальный: считает,что Дельфи по всем критериям лучше ,чем Visual C++ и требует писать прогу на ней. Говорит,что для решения прикладных задач лучше Дельфи языка нет.



В новой версии Дельфи (кажется в Delphi 2005) такая возможность есть (по крайней мере так препод говорит)

Зачем бы тогда существовало столько языков программирования? Был бы какой нибудь один...
Думаю, что он ошибался или ты его не правильно понял

А еще он ходит в набедренной повязке и размахивает каменным топором...прикладные задачи удобно решать в Visual Studio 2008. На C#.
Уточни, может он поддержку .NET в Delphi имеет в виду. Тогда прогу, написанную на C# или Managed C++ можно расковырять ]]>Reflector]]>-ом и получить исходник для Delphi.NET.

Думаю всё к тому и идёт. Будет один универсальный язык,который возьмёт в себя лучшие черты всех языков.

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



Скорее всего именно это он и имел в виду.Речь шла о последних версиях Дельфи

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

Пипец какой-то. Интересно, препод то написал хоть одну серьезную программу на С++? Хотя в свете недавних контрактов на поставки CodeGear 1 млн рабочих мест с Delphi и С++ Builder в российские школы ничего удивительного. Однако, на мой взгляд, учить нужно использовать различные языки, адекватно подходящие к задаче.

Ага, этакий сферический конь в вакууме

Ну так при чем здесь С++ и Java? Сначала бы уточнил, а потом спрашивал на форуме. А то услышат где-то звон и бегут на форум себя показывать

А разработчики всех остальных языков подают в суд на программистов, пишущих модули. Подсылают к ним убийц. Закрывают сайты с исходниками...препод, похоже, действительно не написал ничего серьезного, ни на дельфе, ни на других языках.
Лучше черты ассемблера, VB, Cobol, Perl, C++, Java, C#, List...как ты себе представляешь результат?

Голый асм? Развитие по спирали, так сказать...

Ой, нет... Лучше костяные программируемые счеты

Для: European
Палочки с насечками. Счеты - это уже хайтэк.

Artur1987, нет и не будет Потому как язык - рисования школьников, не когда не дойдет в своих возможностях до профессионального языка.

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

Для: Artur1987, Где учишься? Кто препод? Страна должна знать своих героев!

Для: ~/~евто/-/
Достойных много. Универсального нет.

Э-э-э,ну вы тут написали Учимся мы в МГУИЭ и создаём Системы Автоматизированного Проектирования. А тему эту я создал просто с целью убедиться,что язык С++ также,как и Delphi подходит для решения прикладных задач. Я имею в виду не системное программирование, а именно прикладное, то есть различные расчёты на прочность,устойчивость,анализ и т.д.

Программу пишу - дипломную,поэтому для меня это всё важно,не из праздного любопытства спрашиваю

Это как в единоборствах - бессмысленно сравнивать бокс и карате: сражаются ведь не стили, а бойцы.

тут можно и оспорить, таких турниров в мире - куча

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

Для: Artur1987
Различные расчёты на прочность,устойчивость,анализ - это область, а не дельфи C++. Дельфи - это прога для набрасывания "компонент" на кривые формы, орудие халтурщика. Хотя, все зависит от радиуса кривизны рук.

Интересно, а чем в этом плане лучше VS.NET? Чем у него формы и компоненты ровнее?

Да хотя бы тем, что VS не провоцирует строить все приложение в виде огромного синглтона, состоящего из кучи маленьких синглтончиков. Начинающего программера даже под VB.NET не шокирует мысль, что форму можно "создать динамически" и даже что можно показать 2 одинаковых формы.
А после того, как дельфи стало .net, оно вообще обречено вечно тащиться в хвосте студии.

Для: Pasha
1. Ты так и не ответил на мой вопрос "Чем у него формы и компоненты ровнее?" Речь не идет о внутренней структуре кода приложения.
2. В VS.NET можно также построить приложение, как и в Delphi - открыл форму, накидал контролов, двойной щелчок, получил обработчик, ввел код - то есть получить огромный синглтон, состоящий из кучи маленьких синглтончиков.
3. Приведи пример NET-приложения, которое можно сделать только в VS.NET (VB.NET) и нельзя сделать с использованием Delphi или VC++
4. В VS.NET у программиста зависимость от .NET Framework-классов не меньшая чем у Delphi-программера от компонентов. У кого мозги работают, тот сам свои классы (компоненты) пишет.

Я бы тут сказал в точности наоборот.
У кого мозги работают, тот свои "велики" не пишет.

Для: zubr
1,2. Речь как раз идет о той структуре кода приложения, которую генерит, или помогает генерить IDE, и о той модели управления ресурсами приложения, которая предлагается по умолчанию. Я просто не понимаю, почему, например, сокет в дельфи - это компонент.
3. Любое приложение, активно использующее фишки 3.0 фреймворка в студии написать намного проще. Приложение, использующее .net 3.5 и LINQ в Delphi вообще написать нельзя.
4. В VS.NET классы не набрасываются на форму, и не называются "компонентами". У кого мозги работают, тот использует стандартные классы и не создает проблем своим преемникам на проекте. И не изобретает колеса.

Да ну...? Неужели удается в любой задаче стандартными кубиками обходиться? Завидую вам.

Любой компонент в Delphi - это прежде всего класс, такой же как и класс в фреймворк. Его можно ложить на форму, а можно и подключать динамически. Компонент сокета в Delphi - это класс-оболочка к апишным функциям, а в фреймворке, что не так?

Приведи пример функциональных возможностей данных приложений.

Про компоненты и классы смотрите чуть выше. Большой разницы с фреймворком нет. И какая разница как это называется.

Во фреймворке его нельзя "положить на форму" и нельзя "подключить статически". Я понимаю, что сокет в дельфи - это класс. Я не понимаю зачем нужно было делать его компонентом и навязывать использование в качестве синглтона.
.NET 3.5 - вывод типов, лямбда-выражения. LINQ - операции над запросами, а не над их результатами. Возможность одинаково работать с запросами над SQL/XML/DataSet/Entities/Objects. Возможность вызывать хранимые процедуры как функции. Возможность писать условия выборки на C#/VB, а не на SQL. Дальше в гугл, там достаточно примеров. Вот, хотя бы ]]>http://weblogs.asp.net/scottgu/archive/200...sql-part-1.aspx]]>

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

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

Для: zubr
Дело не в том, можно ли создавать компонеты в дизайнере, а в том, что Delphi предлагает DesignTime по умолчанию, причем так активно, что многие дельфисты даже не догадываеются о возможности создания объектов только при необходимости. Использование компонентов в design time ускоряет разработку мелких приложений, а хоть что-то серьезное превращает в кучу форм с множеством квадратиков на них. И при запуске приложения все эти квадратики усиленно выжирают ресурсы и соединения, а при закрытии - усиленно их освобождают. А условий, когда использование ресурсов не критично, я еще не встречал.

Да ну, мы не ведем речь о ламерах, которые только умеют кидать компоненты на формы. Программист Delphi разрабатывающий сложные проекты, как правило использует и DesignTime и RunTime возможности.

Давай рассуждать: в любом Win-приложении (не консольном) есть главная форма (ну или окно, кому как удобно называть) и на ней множество контролов (буттоны, эдиты, чекбоксы и т. д.), большинство из которых существует все время жизни приложения, вопрос, зачем их создавать динамически, не проще ли визуально спроектировать данную форму в DesignTime. Что мешает контролы, котрые не существуют все время жизни приложения подгружать-выгружать на форму динамически? Также у многих приложений есть различные дополнительные формы, диалоговые окна, опять таки в большинстве случаев с постоянными контролами. Что мешает не загружать их при открытии приложения (галочка в Options проекта), а загружать и выгружать по необходимости. В этом случае все данные по формам находятся только в ресурсе exe-файла, но не в оперативной памяти, что несколько увеличивает размер экзешника (по сравнению с вариантом динамического создания ресурсов) - но на сегодняшний день размер экзешника не критичен, имхо. Да и к фреймворковскому экзешнику зачастую надо еще сам фреймворк поставлять, что не есть удобно.

У нас речь шла о невозможности написать определенную программу в Delphi, а не разнице в удобствах определенных классов различных программных сред.

почитал я это все. легче уж на апи писать

Я не предлагаю создавать визуальные контролы в DesignTime. Элементы пользовательского интерфейса ес-но проще создавать в дизайнере. Я говорю именно о невизуальных компонентах - сокетах, соединениях с базой данных, запросах, таблицах. И о ресурсах не в смысле embedded resources, а о открытых соединениях с базой, User/GDI объектах, памяти, и времени на инициализацию кучи синглтонов.
На ассемблере под win32 можно написать те же приложения, что и на последнем .net, толко при этом придется изобрести очень много велосипедов. Речь идет именно об удобстве базовой функциональности для приложений.
Если Delphi превратилось в среду разработки под .net, то теперь важна именно поддержка всех фишек фрэймворка. А на Delphi 2007 for Win32 очень тяжело нарисовать что-то вроде приаттаченого сэмпла.Нажмите для просмотра прикрепленного файла

На апи лучше вообще ничего прикладного писать, только зря время потратишь и багов наплодишь.

Для: gamecreator
Да ну? Большой проект охренеешь на API писать. Применять API в процедурах, классах да, а писать на чистом API - ну его на фиг.
Кстати, в .NET использовать API-функции достаточно гиморно, что ему не делает +.

Pasha, мы уже начинаем повторяться. Упомянутые тобой компоненты, прежде всего классы, которые имеют конструктор, дестрктор, метод Free - освобождения памяти. Не надо их кидать на форму, создавай их динамически. Стиль программирования - ложить компонент на форму или работать с ним динамически, это уже другая тема. Просто у многих Delphi-программеров есть стереотип разработки в DesignTime, но причем здесь сама среда?

Ну эта фишка просто готовый кубик, который есть в фреймворк и нет в Delphi. Вся беда в том, что Microsoft перекупила хороших программеров у Borland и теперь новые кубики они рисуют для мелкомягких.

Да, я тоже хочу поучаствовать в холивар!!!


В Delphi есть замечательная штука - DataModule - контейнер для невизуальных объектов, например, соединений с БД. Таких DataModule может быть множество, создавать/уничтожать их можно в любое время, и ещё и привесить обработчики на события класса. Причем объекты, содержащиеся в нём можно сделать доступным из любого места программы. И такое:

получается только у косоруких, что, впрочем, не редкость

Для: zubr
Стереотип "накидать компонентов" не возникает сам по себе. Каждый дельфист сначала привыкает накидывать их на форму, а потом узнает что их можно создать динамически. Или так и не узнает.
Это не "кубик фрэймворка", это уже больше года часть операционки. Довольно странно что дельфи до сих пор не позволяет использовать все возможности винды. Хотя, оно всегда отличалось самописными базовыми контролами, которые даже темы нормально не поддерживали.
А перекупка прграммеров - это беда Borland-а, а не остальных разработчиков.
Для: Azrael
От использоваиня DataModule смысл не меняется. Вместо того, чтобы просто создавать и использовать объекты, Delphi провоцирует работать с ними как с компонентами-синглтонами, пусть даже с возможностью управления временем жизни. Глобальные переменные форм, доступность из любого места программы - структурное программирование в чистом виде, со всеми его недостатками.
Такое в определенный момент начинает получатся у любого программера И ему приходится переучиватся, читать основы ООП/ООД, писать ровный код. Вот только у дельфистов этот момент наступает тогда, когда написанной софтиной уже кто-то пользуется, и кто-то ее поддерживает. IMHO, лучше как в VC++ и C#, не давать программеру дойти до такой стадии.

Это что в висте такие контролы? Висту еще не юзал.

Скорее монопольная политика майкрософт. Цель простая - уничтожить конкурентов, чтобы все пользовались только продуктами майкрософт. А продукты мелкомягких - зачастую такая убогость и баги на багах. Один осел (IE) чего стоит.

Ага, странно все это, пуркуа па?


И че с ним не так? Ох уж эти мастаки ... типа сами круче написали ... или предъявите прогу без изьян?

Зато все спецы "политика майкрософт" ...


Поэтому всега говорю, за такое "мы вас будем убивать хахаха"

Эти контролы в влюбой винде с установленным .net 3.0, который уже больше года назад всем с апдейтами пришел. А еще они же есть в silverlight под винду/linux/макось, который MS в последнее время усиленно пропихивает.
В висте из явно родных заточенных под .net вещей есть Windows Activation Services для хостинга WCF-сервисов. Ну и хорошая хардварная поддержка для красивых контролов. В новом W2K8 еще Power Shell добавился, теперь админам придется .net изучать.Цель мелкософта - создать хорошие условия для разработчиков под винду и тем самым увеличить ее продажи. А вовсе не написать меганабор "все в одном", как макось. Для конторы, написавшей офис и студию, IE - жалкая поделка. Вот только зачем МС-у собственный крутой бесплатный браузер, если они за него не получают денег, да еще и вынуждены судиться за сам факт его существования.

sax_ol, Pasha явно вам БГ приплачивает.

Для: zubr
Емае, ... прочему не заметно? Надо письмо написать, а то виш отлынивает, я тут понимаш ... а он ... фсе пишу письмо.

Для: Pasha
ура, мы победили самого zubr' a, и так бует скаждым ...
Для: zubr
надеюсь юмар вам не претит?

Для: zubr
Он не приплачивает. Он обеспечивает нас работой