Здравствуйте, gloomy rocker, Вы писали:
GR>Здравствуйте, AlexK, Вы писали:
GR>Справедливое замечание, НО! GR>Разрабатывать компоненты бизнес-логики стало намного приятней. И именно в этом контексте я имел в виду лаконичность. GR>Попробуй например на C++ напиши что-то типа GR>
GR>my_object.MyMethod(new MyParam1(...), new MyParam2(...));
GR>
GR>Проблемы гарантированы!
А в чем проблемы?
GR>Попробуй на каждый чих проверять возвращаемое значение. Тут ты с воплями (ushort)1 — rules!!! прескочишь на C#.
Это не проблема языка, а особенность Win32 API, которые должны быть вызываемы из C. Возьми winstl, например, и жизнь станет проще.
А попробуй из C# Win32 функции повызывать, тоже возвращаемое значение проверять прийдется. От этого никуда не деться.
GR>А как меня достал бардак со строками в C++ GR>Надо тебе BSTR на подстроки, разделяемые запятой, разбить — нужно сконвертить его например в CStringW, GR>а потом последовательно вызывать метод Tokenize, пока подстроки не закончатся. GR>Бррр... жуть!!! А на C# это записывается ЛАКОНИЧНО GR>
GR>string[] str_parts = my_string.Split(...);
GR>
Бардак в COM программировании опять же, а не в C++. А ты возьми comstl, и жизнь... сам знаешь
А в C++ со строчками все хорошо: std::string.
GR>Еще примеры придумать? GR>interop, например, намного приятней, чем #import в С++.
Зато из C# нельзя создать COM объекты, не реализующие IDispatch.
GR>И таких приятных мелочей в C# полно.
Пока что C# выигрывает только тем, что библиотека .NET для него доступна, а для (native) C++ нет (C++ with managed extensions — это очень грусно). Но прийдет другое время... (http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx смотри раздел про Visual C++).
Здравствуйте, alexkro, Вы писали:
A>А в чем проблемы?
Проблема в управлении памятью. В указанном примере MyMethod обязан будет освободить память, а это в ощем случае плохо,
поскольку не исключено такое использование этого метода в С++:
MyParam1* prm1 = new MyParam1(...);
MyParam2* prm2 = new MyParam2(...);
my_object.MyMethod(prm1,prm2);
prm1->DoSomething();
prm2->DoSomething();
А в .Net сбощик мусора все подберет.
A>Это не проблема языка, а особенность Win32 API, которые должны быть вызываемы из C. Возьми winstl, например, и жизнь станет проще.
А я на С++ и не наезжаю. Я утверждаю, что на C# компоненты разрабатывать намного приятней.
A>А попробуй из C# Win32 функции повызывать, тоже возвращаемое значение проверять прийдется. От этого никуда не деться.
Да, здесь есть проблемы, но для многих функций существуют высокоуровневые классы.
A>Бардак в COM программировании опять же, а не в C++. А ты возьми comstl, и жизнь... сам знаешь
Что такое comstl? Или так теперь называется ATL?
A>А в C++ со строчками все хорошо: std::string.
Ну не хочу я в ATL-проект, в котором уже используются CComBSTR, _bstr_t и CStringW цеплять еще и std::string
A>Зато из C# нельзя создать COM объекты, не реализующие IDispatch.
Чушь!!!
Я не поленился — проверил эту гипотезу.
Вот работающий код:
// Class1.h : Declaration of the CClass1#pragma once
#include"resource.h"// main symbols#include"COMObject.h"// CClass1class ATL_NO_VTABLE CClass1 :
public CComObjectRootEx<CComSingleThreadModel>,
public CComCoClass<CClass1, &CLSID_Class1>,
public IClass1
{
public:
CClass1()
{
}
DECLARE_REGISTRY_RESOURCEID(IDR_CLASS1)
BEGIN_COM_MAP(CClass1)
COM_INTERFACE_ENTRY(IClass1)
END_COM_MAP()
DECLARE_PROTECT_FINAL_CONSTRUCT()
HRESULT FinalConstruct()
{
return S_OK;
}
void FinalRelease()
{
}
public:
STDMETHOD(Test)(BSTR bsInput, BSTR* bsOutput);
};
OBJECT_ENTRY_AUTO(__uuidof(Class1), CClass1)
// Class1.cpp : Implementation of CClass1#include"stdafx.h"#include"Class1.h"#include".\class1.h"// CClass1
STDMETHODIMP CClass1::Test(BSTR bsInput, BSTR* bsOutput)
{
// TODO: Add your implementation code here
CComBSTR bsOut(L"CClass1::Test called with bsInput = ");
bsOut.AppendBSTR(bsInput);
*bsOutput = bsOut.Detach();
return S_OK;
}
// COMObject.idl : IDL source for COMObject
//
// This file will be processed by the MIDL tool to
// produce the type library (COMObject.tlb) and marshalling code.
import "oaidl.idl";
import "ocidl.idl";
[
object,
uuid(C0D727C9-97C0-4BA6-A0A4-7D046BA70A22),
helpstring("IClass1 Interface"),
pointer_default(unique)
]
interface IClass1 : IUnknown{
[helpstring("method Test")] HRESULT Test([in] BSTR bsInput, [out,retval] BSTR* bsOutput);
};
[
uuid(8F9408DE-6912-4B57-A42B-C9DE88BE88A0),
version(1.0),
helpstring("COMObject 1.0 Type Library")
]
library COMObjectLib
{
importlib("stdole2.tlb");
[
uuid(BECA4E65-71A5-4947-BC78-8CA6623AAD7E),
helpstring("Class1 Class")
]
coclass Class1
{
[default] interface IClass1;
};
};
using System;
using COMObjectLib;
namespace SharpCaller
{
/// <summary>
/// Summary description for Class1.
/// </summary>class Class1
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
Class1Class cls1 = new Class1Class();
string str_rer = cls1.Test("test");
}
}
}
A>Пока что C# выигрывает только тем, что библиотека .NET для него доступна, а для (native) C++ нет (C++ with managed extensions — это очень грусно). Но прийдет другое время... (http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx смотри раздел про Visual C++).
Пока я вижу у вас только нежелание принять что-то новое.
Для некоторых задач C# — действительно не лучший выбор, но уж те задачи,
для которых он предназначен, решать на нем одно удовольствие!
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, GarryIV, Вы писали:
GIV>>В дереве от называется "Демагогия программирования" в форме модерирования и внутри него самого написано "Священные войны".
ВВ>В дереве это глюк. И над ним уже работают
fixed.
ура-ура!
... << RSDN@Home 1.1 beta 2 >>
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Здравствуйте, gloomy rocker, Вы писали:
GR>Здравствуйте, alexkro, Вы писали:
A>>А в чем проблемы? GR>Проблема в управлении памятью. В указанном примере MyMethod обязан будет освободить память, а это в ощем случае плохо,
Высосано из пальца. Ты будешь утверждать, что нужно обязательно объекты параметров создавать в куче и передавать голые указатели? Как будто это единственный способ.
... A>>Зато из C# нельзя создать COM объекты, не реализующие IDispatch. GR>Чушь!!!
Какой ты несдержанный . Долго злился, когда проверял? Так было в 1.0. Если в 1.1 поправили, то хорошо.
GR>Я не поленился — проверил эту гипотезу. GR>Вот работающий код:
...
A>>Пока что C# выигрывает только тем, что библиотека .NET для него доступна, а для (native) C++ нет (C++ with managed extensions — это очень грусно). Но прийдет другое время... (http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx смотри раздел про Visual C++). GR>Пока я вижу у вас только нежелание принять что-то новое. GR>Для некоторых задач C# — действительно не лучший выбор, но уж те задачи, GR>для которых он предназначен, решать на нем одно удовольствие!
Здравствуйте, Terber, Вы писали:
T>Так вот, попробовал тут C#, после MFC все кажется очень легко, прям Visual Basic — ом попахивает....
Если все кажется слишком легко, значит на слишком примитивной задаче пробовал. Если система предназначена для решения на порядок более сложных задач (чем С++ и MFC) значит на них и надо ее применять.
T>Как вы считаете, можно ли отнести C# программеров к первой категории и почему?
Хороших можно, плохих нет. И при чем здесь сравнение с Delphi и VB, на дельфях разрабатывали в основном гуй и для этого нужны специалисты по дизайну и организации логики гуя. Это не програмирование но немного с ним пересекается.
.NET и C# предназначены для другого.
M>Давайте посмотрим на корову с другого бока. А как на счет сравнения возможностей VB и C#. Пожалуй, C# в этом отношении помощнее будет.
Здесь неоднозначность. Нужно уточнять, который VB ты имеешь ввиду, потому что есть два кардинально разных языка:
VB (до версии 6.0 включительно)
VB.NET
Между ними — пропасть.
P.S. Кстати, VB.NET и C# сравнивались уже многократно, и отличия на самом деле есть, но незначительные (вещи вроде отсутствия inline XML документации в VB.NET и отличия с делегатами MS обещает устранить в следующей версии).
Поэтому лично я считаю языки VB.NET (2003) и C# (2003) функционально эквивалентными.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, Terber, Вы писали:
T>>Так вот, попробовал тут C#, после MFC все кажется очень легко, прям Visual Basic — ом попахивает....
S_>Если все кажется слишком легко, значит на слишком примитивной задаче пробовал. Если система предназначена для решения на порядок более сложных задач (чем С++ и MFC) значит на них и надо ее применять.
T>>Как вы считаете, можно ли отнести C# программеров к первой категории и почему?
S_> Хороших можно, плохих нет. И при чем здесь сравнение с Delphi и VB, на дельфях разрабатывали в основном гуй и для этого нужны специалисты по дизайну и организации логики гуя. Это не програмирование но немного с ним пересекается. S_>.NET и C# предназначены для другого.
Здравствуйте, alexkro, Вы писали:
A>Здравствуйте, gloomy rocker, Вы писали:
GR>>Здравствуйте, alexkro, Вы писали:
A>>>А в чем проблемы? GR>>Проблема в управлении памятью. В указанном примере MyMethod обязан будет освободить память, а это в ощем случае плохо,
A>Высосано из пальца. Ты будешь утверждать, что нужно обязательно объекты параметров создавать в куче и передавать голые указатели? Как будто это единственный способ.
A>... A>>>Зато из C# нельзя создать COM объекты, не реализующие IDispatch. GR>>Чушь!!!
A>Какой ты несдержанный . Долго злился, когда проверял? Так было в 1.0. Если в 1.1 поправили, то хорошо.
Ну погорячился малось
Я проверял действительно на 1.1. На нем работает.
1.0. просто под рукой нет, а то тоже проверил бы.
GR>>Я не поленился — проверил эту гипотезу. GR>>Вот работающий код:
A>...
A>>>Пока что C# выигрывает только тем, что библиотека .NET для него доступна, а для (native) C++ нет (C++ with managed extensions — это очень грусно). Но прийдет другое время... (http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx смотри раздел про Visual C++). GR>>Пока я вижу у вас только нежелание принять что-то новое. GR>>Для некоторых задач C# — действительно не лучший выбор, но уж те задачи, GR>>для которых он предназначен, решать на нем одно удовольствие!
A>Зачем мне принимать что-то новое, в котором нет половины возможностей старого? Мне больше по душе вот это: http://www.gotdotnet.com/team/PDC/4064/TLS310.ppt
Что первое приходит в голову — множественное наследование, отсутствие optional параметров.
Но это и не обязательно. Можно обойтись агрегацией и перегорузкой методов. Я думаю, так даже правильней.
Чего вам еще не хватает? По пунктам пожалуйста. Что было и чего не стало.
Здравствуйте, gloomy rocker, Вы писали:
GR>VBS все методы через IDispatch.Invoke вызывает. GR>Так почему он не хочет вызывать методы разных интерфейсов? GR>Или он умеет вызывать только методы default интерфейса?
Так и есть. Дело в том что в обжекте реализация диспатча особо хитрая. Потому видны только метода одного интеофейса. Каждый раз приводит к типу и кастить очень геморно.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Здравствуйте, gloomy rocker, Вы писали:
GR>>VBS все методы через IDispatch.Invoke вызывает. GR>>Так почему он не хочет вызывать методы разных интерфейсов? GR>>Или он умеет вызывать только методы default интерфейса?
PE>Так и есть. Дело в том что в обжекте реализация диспатча особо хитрая. Потому видны только метода одного интеофейса. Каждый раз приводит к типу и кастить очень геморно.
Здравствуйте, alexkro, Вы писали:
A>Бардак в COM программировании опять же, а не в C++. А ты возьми comstl, и жизнь... сам знаешь A>А в C++ со строчками все хорошо: std::string.
В КОМ говоришь? Проблема в том, что с С++ так сплошь и рядом. С++ — язык где сплошь и рядом нужно полагаться на те или иные патерны кодирования. Приемущество Шарпа не в том, что в нем ошибки обрабатывать проще, а в том, что Шарп практически не требует от программиста соблюдения неких джентельменских соглашений для получения работоспособного кода. Единсвенным серьезным код-патернов в Шарпе является using(). В общем, Шарп спроектирован так, чтобы уберигать программиста от граблей за счет строгости и сбалансированности языка (и рантайма), а не патернов кодирования. С++ же несоблюдения многих джентельменских соглашений тут же приводит к серьезнийшим проблемам.
A>Зато из C# нельзя создать COM объекты, не реализующие IDispatch.
Может не стоит говорить об областях в котороых не разбираешся?
GR>>И таких приятных мелочей в C# полно.
Больше конкретики.
A>Пока что C# выигрывает только тем, что библиотека .NET для него доступна, а для (native) C++ нет (C++ with managed extensions — это очень грусно). Но прийдет другое время... (http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx смотри раздел про Visual C++).
Извини, но это банальный фанатизм. Шарп выигрывает по очень многим параметрам. Главные из них — это простота и безопасность. С++ несомненно мощьный язык, но содержащий слишком огромное количество граблей. STL так же далека от совершенсва. Думаю даже после появления С++ for CLI все равно основная масса народа будет выбирать Шарп. А кое-кто вообще Васик.нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alexkro, Вы писали:
A>Высосано из пальца. Ты будешь утверждать, что нужно обязательно объекты параметров создавать в куче и передавать голые указатели? Как будто это единственный способ.
Вот многие не могут понять зачем нужен язык в котором для получения корректного кода все нужно десять раз обернуть в шаблоны. Наверно они уроды.
A>Какой ты несдержанный . Долго злился, когда проверял? Так было в 1.0. Если в 1.1 поправили, то хорошо.
Так небыло никогда. Это просто твое незнание предмета. На Шарпе (как и на других языках дотнета) всегда можно было как использовать, так и создавать КОМ-объекты не реализующие диспатч.
A>Зачем мне принимать что-то новое, в котором нет половины возможностей старого?
Затем, что в нем (в новом) нет 99% граблей (так искосно разоженных создателями С++) и не нужно напрягаться, чтобы написать корректный код. Как результат скорость создания ПО выростает на пордки. А надежность увеличивается.
Сравни как нибудь на досуге функциональность std::vector-а и IList<T>. А потом ответь зачем std::vector нужен в дотнете?
В общем, это догматизм. STL далек от севершенства и имеется достойные замены ему. С другой стороны если тебе хочется использовать СТЛ — используй. Получишь тормоза в дотнете, но удовлетворение от использования чего-то "родного". Если оно того стоит, то почему бы и нет?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gloomy rocker, Вы писали:
GR>Здравствуйте, Terber, Вы писали:
... GR>Я считаю, что для разработки GUI и бизнес-логики C# — то что доктор прописал
Абсолютно согласный. У C# очень хорошая и ёмкая ниша вырисовывается. Причем, решения для этой ниши не будут страдать тормознутостью, как в классическом Бейсике.
VD>В КОМ говоришь? Проблема в том, что с С++ так сплошь и рядом. С++ — язык где сплошь и рядом нужно полагаться на те или иные патерны кодирования. Приемущество Шарпа не в том, что в нем ошибки обрабатывать проще, а в том, что Шарп практически не требует от программиста соблюдения неких джентельменских соглашений для получения работоспособного кода. Единсвенным серьезным код-патернов в Шарпе является using().
Это также и минус. С++ дисциплинирует писателя, а С# — нет. На шарпе иногда появляются такие выгибоны, на которые в здравом уме мало кто пойдет, а все потому, что слишком просто на нам нагнать код.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Здравствуйте, VladD2, Вы писали:
VD>>В КОМ говоришь? Проблема в том, что с С++ так сплошь и рядом. С++ — язык где сплошь и рядом нужно полагаться на те или иные патерны кодирования. Приемущество Шарпа не в том, что в нем ошибки обрабатывать проще, а в том, что Шарп практически не требует от программиста соблюдения неких джентельменских соглашений для получения работоспособного кода. Единсвенным серьезным код-патернов в Шарпе является using().
PE>Это также и минус. С++ дисциплинирует писателя, а С# — нет.
Дисциплирироваться нужно было в школе или в институте. А после обучения писать нужно. Да и некто не мешает натрахаться на С++ чтобы потом писать на Шарпе. Я так сам предпочитаю тех кто знаком с С++. Это как бы лишнее доказательство развитости человека как программиста. Но вот к минусам языка это отнести вряд ли можно.
PE> На шарпе иногда появляются такие выгибоны, на которые в здравом уме мало кто пойдет, а все потому, что слишком просто на нам нагнать код.
Согласен. Но это и есть собстенно проблемы обучения и формирования личности.
Вот сколько есть людей не умеющих связать по-русски двух слов? Это же не значит, что русский плох?
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Terber, Вы писали:
T>Читал уже достаточно давно форум на сайте. Там поднималась проблема квалификация VB & Delphi программистов. T>Так вот, попробовал тут C#, после MFC все кажется очень легко, прям Visual Basic — ом попахивает.... T>Как вы считаете, можно ли отнести C# программеров к первой категории и почему?
По секрету скажу, в жизни любого программиста наступает момент, когда уже не важно на чём ты пишешь или когда-либо писал
Здравствуйте, Mishka, Вы писали:
M>По секрету скажу, в жизни любого программиста наступает момент, когда уже не важно на чём ты пишешь или когда-либо писал
[Skipped] A>Бардак в COM программировании опять же, а не в C++. А ты возьми comstl, и жизнь... сам знаешь A>А в C++ со строчками все хорошо: std::string.
Ага, если только пользуешься одним компилером. А когда придется создавать код, работающий после компиляции разными компилерами, будешь писать свою реализацию STL или кучу дефайнов плодить
S_> Хороших можно, плохих нет. И при чем здесь сравнение с Delphi и VB, на дельфях разрабатывали в основном гуй и для этого нужны специалисты по дизайну и организации логики гуя. Это не програмирование но немного с ним пересекается. S_>.NET и C# предназначены для другого.
При чем туту гуй? Ниши у C#/Delphi совпадают почти на 100%.
Я некоторое время назад пользовался одним софтовым DVD-плеером, очень симпатичным и функциональным (DVDDirect). Очень удивился, но он оказался написан на Delphi, вместе с DS-фильтрами.
