Как технарю из России стать программером в США за 150К

[Zombie416]

Кстати новый язык "D" тоже не имеет множественного наследования.
http://en.wikipedia.org/wiki/D_(programming_language)
Как Вы думаете почему?

Ну таких новых языков навалом, 99% заканчивают жизнь в корзине. Почему? Такой дизайн.

Одиночное наследование проще в понимании и реализации. Правда, совсем уйти от него не получилось, и часть проблем решается интерфейсами. Но при этом все равно теряется существенная часть функциональности и выразительности, и то что в C++ аккуратно получается с темплейтами, на C/C#/Java/... приходится решать средствами Copy/Paste или препроцессором. Ну и, в сравнении с C++, C# - овское решение с отложенными деструкторами, которое склонировали с Java, чревато протеканием ресурсов, сюрпризами с потоками, кучей ненужных try/finally и прикручиванием постфактум ржавыми болтами всяких "critical finalizers".

А так, практически все что можно написать на C, можно написать на C#. И многое из того что пишется на C++, тоже можно написать на C#. Не "в принципе", а эквивалентный код практически построчно. И с близкой производительностью причем. Драйвера писать вполне можно (и пишут).

[Zombie416]

В любом случае C# это язык для другой ниши, а не язык следующего поколения который должен заменить C++.

Это язык для той же ниши, и в огромном количестве случаев он заменяет C++ очень успешно. Естественно, не в 100%. Как и ассемблер хоронят уже десятилетиями.

Чем проект больше, компонентов, людей/кода в нем больше, тем преимущества С#/Java над C++, C++ над C, C над ассемблером, становятся очевиднее.

[ddv]

Это язык для той же ниши, и в огромном количестве случаев он заменяет C++ очень успешно. Естественно, не в 100%. Как и ассемблер хоронят уже десятилетиями.
Чем проект больше, компонентов, людей/кода в нем больше, тем преимущества С#/Java над C++, C++ над C, C над ассемблером, становятся очевиднее.

Ничего он не заменяет...не надо сравнивать языки которые компилируются в байт код и языки компилируемые в NATIVE код. И уровень производительности у них совсем разные...И не надо меня убеждать что 15 мегабайт оперативной памяти для Hello World приложения на C# это нормально. Мне уже хватает убогих ATI утилит которые с переходом на .NET невозможно использовать из за огромного объема используемой памяти и ресурсов. А уж про скорость я вообще молчу...когда на каждом шагу вы создаете десятки объектов, проверяете сотню типов на соответствие и т.п.
А GUI приложения на Java под Windows это вообще только для энтизиастов типа ORACLE....с каждым приложением приходится ставить отдельную Java машину, потому что их десятки не совместимых между собой разновидностей.

[ddv]

А так, практически все что можно написать на C, можно написать на C#. И многое из того что пишется на C++, тоже можно написать на C#. Не "в принципе", а эквивалентный код практически построчно. И с близкой производительностью причем. Драйвера писать вполне можно (и пишут).

Вы вообще C++ то знаете??? Какое можно??? Там нет ни темплейтов, ни множественного наследования, ни указателей...Я могу вам скинуть пример на C++ который вы фиг переведете на C# без полного его переписывания.
Ну и приведите мне пример ДРАЙВЕРА который написан на C#.

[Zombie416]

Вы вообще C++ то знаете??? Какое можно??? Там нет ни темплейтов, ни множественного наследования, ни указателей...Я могу вам скинуть пример на C++ который вы фиг переведете на C# без полного его переписывания.
Ну и приведите мне пример ДРАЙВЕРА который написан на C#.

Вообще-то знаю, да. А Вы про C#, похоже, где-то слышали.

Есть в С# и темплейты, и указатели, и примитивное множественное наследование через интерфейсы (что, конечно, неудобно т.к. не позволяет наследовать более одной реализации, но часто достаточно), и указатели на функции (ака delegates), и структуры с известным расположением полей в памяти (что полезно для interop-а), и лямбды, и еще целая куча всего. И более того, работаю в проекте где есть идентичный код на C++ + STL и на C#, совпадающий практически построчно, причем производительность имеет значение.

А драйвера, если уж на то пошло, имеется масса оснований писать именно на managed языках. Примеры драйверов на Sing#, что есть C# подпиленный напильником, можно в http://singularity.codeplex.com/ посмотреть.

[ddv]

Есть в С# и темплейты, и указатели, и примитивное множественное наследование через интерфейсы.

Есть темплейты??? Поэтому вы и программируете на C# что даже не можете понять чем отличаются темплейты от generics которые есть в c#. http://blogs.msdn.com/b/csharpfaq/archi ... lates.aspx

C++ templates are sometimes used for a technique known as template metaprogramming. There is no way to do this in C#.

[ddv]

И более того, работаю в проекте где есть идентичный код на C++ + STL и на C#, совпадающий практически построчно, причем производительность имеет значение.

STL на C# совпадающий построчно???? Пример использования std::vector,std::list,std::map на C# в студию . В месте с benchmark..

[Zombie416]

Ничего он не заменяет...не надо сравнивать языки которые компилируются в байт код и языки компилируемые в NATIVE код. И уровень производительности у них совсем разные...

Вообще-то CLR байт-код компилируется в нативный код перед исполнением. И при аналогичном качестве оптимизатора (сравнивая MS VC++ и MS VC++/CLR), скорость исполнения практически идентична, как ни удивительно (правда так было не всегда).

У C# выразительные средства победнее, наличие reflection и отсутствие const-ов выкручивает оптимизатору руки, и в итоге получается помедленнее процентов на 50-100%, если писал человек знающий особенности обоих языков. Что для очень многих приложений, которые не занимаются чисто вычислительной работой, а в основном ждут ответа у моря/пользователя/базы данных, некритично совершенно. Ну и да, с C++ часто больше оптимизационных возможностей, т.е. есть шанс сделать good enough до того как плюнуть и начинать писать на ассемблере.

Повторюсь, преимущества C#/Java начинают проявляться не в программе hello world, а когда есть множество библиотек и интерфейсов, которые надо собирать в кучу.

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

Где-то такие же аргументы и про C++ можно послушать от людей которые ну не осилили...

Как написано, так и будет. Можно создавать, можно не создавать. Если сравнивать код на C# написанный идиотом который и про boxing-unboxing не слыхивал, и чем отличается struct от class в C# не слыхивал, и то же написанное человеком представляющим что он делает, то отличия в производительности будут на порядки.

[Zombie416]

STL на C# совпадающий построчно???? Пример использования std::vector,std::list,std::map на C# в студию . В месте с benchmark..

List<T>, LinkedList<T>, Dictionary<T> . Бенчмарки идентичные практически, я проверял, и вы тоже можете.

Примерно теже заблуждения, из серии "мне рабинович напел", про C# и Java у меня тоже когда-то были. Проходят с изучением матчасти тыскыть hands on. Если человек умеет и знает что делает - то и на C#/Java будет быстро работать в 90% случаев. А если не умеет - будет жаловаться что язык не тот, и ОС не та, и компилятор плох, и вообще невиноватая я... Для чего и надо, собственно, C++/C с указателями учить. И ассемблер тоже.

[Zombie416]

Есть темплейты??? Поэтому вы и программируете на C# что даже не можете понять чем отличаются темплейты от generics которые есть в c#. http://blogs.msdn.com/b/csharpfaq/archi ... lates.aspx

Да куда уж мне понять-то... Я на C/C++ всего-то лет как 20 пишу...

[ddv]

Вообще-то CLR байт-код компилируется в нативный код перед исполнением. И при аналогичном качестве оптимизатора (сравнивая MS VC++ и MS VC++/CLR), скорость исполнения практически идентична, как ни удивительно (правда так было не всегда).

Вы действительно не понимаете разницу между оптимизатором Native кода при компиляции, и тем что CLR компилятор оптимизирует BYTE CODE, а не Native!!!! А у JIT компилятора просто нет необходимой информации для нормальной оптимизации. Кроме того, CLR делает слишком много ненужных действий, которые не уберет ни один оптимизатор.

Повторюсь, преимущества C#/Java начинают проявляться не в программе hello world, а когда есть множество библиотек и интерфейсов, которые надо собирать в кучу.

Библиотек для C++ на порядок больше. Единственное приимущество .NET - RAD среда разработки...Без нее C# в GUI был бы бесполезен.

[ddv]

STL на C# совпадающий построчно???? Пример использования std::vector,std::list,std::map на C# в студию . В месте с benchmark..

List<T>, LinkedList<T>, Dictionary<T> . Бенчмарки идентичные практически, я проверял, и вы тоже можете.

Это уже даже не смешно...У вас совпадают построчно это когда совпадает количество строчек????

[Zombie416]

Это уже даже не смешно...У вас совпадают построчно это когда совпадает количество строчек????

Я не старался вас повеселить, уж извините. Конечно это не смешно. Это работает.

"Совпадают построчно", да, когда примерно совпадает количество строчек, как и свойства объектов, и глядя на измения в коде на C++ очевидно где, что и на что править в C# коде, и наоборот. К сожалению, хороших автоматических средств для подобного не существует.

А необходимость в подобной логике имеется. К примеру, если вам нужна идентичная поддержка довольно сложных двоичных структур данных (архив, к примеру), как cross-platform C++, так и Silverlight.

[Zombie416]

Вы действительно не понимаете разницу между оптимизатором Native кода при компиляции, и тем что CLR компилятор оптимизирует BYTE CODE, а не Native!!!! А у JIT компилятора просто нет необходимой информации для нормальной оптимизации. Кроме того, CLR делает слишком много ненужных действий, которые не уберет ни один оптимизатор.

"Вы действительно не понимаете" о чем говорите, но это пройдет.

Бла-бла это здорово, но вы попробуйте. Вот прямо своими руками. Могут быть очень интересные сюпризы. У меня были.

Библиотек для C++ на порядок больше. Единственное приимущество .NET - RAD среда разработки...Без нее C# в GUI был бы бесполезен.

Ну да, ну да... GUI - дело десятое (хотя Visual Studio штука хорошая, безусловно). Преимущество .NET/Java именно в легкости интеграции разных модулей, написанных разными людьми, в разное время, в том числе на разных языках, в кучу.

[Boriskin]

Очередной holy-war, гы!

Мне лично по барабану, на чем писать - С/С++/Java/ObjС, за бабки я только на С# не писал, и, походу, врядли буду (в силу многих причин). По моим субъективным ощущениям, за плюсы платят больше; студентов оным сейчас особо не учат; индусы в оные тоже не рвутся; большого и сложного легаси кода на них - до жопы... Так что по совокупности перечесленного - я свои личные перспективы рассматриваю весьма положительно. На тему грыдушего замещения плюсов жабой, шарпом, и прочими ХеЗ языками - уж сколько лет замещают (10 - 20), да никак заместить не могут. "Нехай брешут" (с)

[ddv]

Бла-бла это здорово, но вы попробуйте. Вот прямо своими руками. Могут быть очень интересные сюпризы. У меня были.

Ну попробовал...Сделал 2 консольные програмки на C++ и C#

Code: Select all

#include "stdafx.h"
#include <Windows.h>
#include <iostream>
#include <list>


int _tmain(int argc, _TCHAR* argv[])
{
	std::list<int>  list;
	timeBeginPeriod(1);
	DWORD time_start = timeGetTime();
	for (int i = 0; i < 1000; i++)
		for (int j = 0; j < 1000; j++)
			list.push_back(i + j);

	for (int i = 0; i < 1000; i++)
		for (int j = 0; j < 1000; j++)
			list.pop_front();

	DWORD time_end = timeGetTime();
	std::cout << "Time elapsed " << (time_end - time_start) << std::endl;
	timeEndPeriod(1);
	return 0;
}

Code: Select all

using System;
using System.Collections.Generic;
using System.Text;

namespace test_clr
{
    class Program
    {
        static void Main(string[] args)
        {
            List<Int32> list = new List<Int32>();
            int time_start = Environment.TickCount;
            for (int i = 0; i < 1000; i++)
                for (int j = 0; j < 1000; j++)
                    list.Add(i + j);

            for (int i = 0; i < 1000; i++)
                for (int j = 0; j < 1000; j++)
                        list.RemoveAt(0);

            int time_end = Environment.TickCount;
            Console.WriteLine("Time elapsed " + (time_end - time_start));
        }
    }
}

Так вот...CLR код работает около 164 секунд. А C++ вариант работает 60 МИЛЛИСЕКУНД!!! Это в 2733 раза быстрее!
Только запускать надо не из под отладчика, а из консоли. Под отладчиком C++ вариант работат 40 секунд (что все равно в 4 раза быстрее CLR), потому что отладчик ему мешает.

[Zombie416]

Так вот...CLR код работает около 164 секунд. А C++ вариант работает 60 МИЛЛИСЕКУНД!!! Это в 2733 раза быстрее!

Какой интересный тест... Вот о подобных выводах и речь. И ведь даже не удивились почему-то.

Начать можно с того что List<T> ~ std::vector<T>, и естессно удаление первого элемента массива в миллион элеметов с копированием всех остальных будет ээ... несколько помедленнее. Ну примерно в тысячи раз. Закончить тем, что выяснить где там CLR overhead, где реализация конкретной коллекции и ее стратегии выделения памяти, где C# vs C++ оптимизатор. Часть можно выяснить откомпилировав с С++/CLR .

А там уже и выводы какие-то делать. А потом можно и еще какой-нить более практический тест сделать.

[ddv]

Какой интересный тест... Вот о подобных выводах и речь. И ведь даже не удивились почему-то.Начать можно с того что List<T> ~ std::vector<T>

Нет...у std::vector нету pop_front()...Кроме того std::vector БЫСТРЕЕ std::list, и если заменить на std::vector и pop_back() то работать будет не 60, а 5 мс.

А там уже и выводы какие-то делать. А потом можно и еще какой-нить более практический тест сделать.

Нет уж теперь не отрекайтесь...сначала вы пишете то что у вас на C# аналогичный STL код работает так же быстро, а когда я вам доказал что он работает в 2733 раз медленнее, то вы сразу запели песню, что если использовать в несколько сот раз меньше элементов, то на глаз это не заметно. НЕВАЖНО сколько элементов...он все равно работает в 2733 раз медленнее...и не важно что с 10 элементами на глаз это не заметно.

[Zombie416]

Нет...у std::vector нету pop_front()...Кроме того std::vector БЫСТРЕЕ std::list, и если заменить на std::vector и pop_back() то работать будет не 60, а 5 мс.

Бугага. Ну вы попробуйте если это неочевидно так. Hint: у std::vector есть vector.erase(vector.begin()). Делает примерно то что list.RemoveAt(0).

А аналог std::list называется LinkedList<T>.

Нет уж теперь не отрекайтесь...сначала вы пишете то что у вас на C# аналогичный STL код работает так же быстро, а когда я вам доказал что он работает в 2733 раз медленнее, то вы сразу запели песню, что если использовать в несколько сот раз меньше элементов, то на глаз это не заметно. НЕВАЖНО сколько элементов...он все равно работает в 2733 раз медленнее...и не важно что с 10 элементами на глаз это не заметно.

Вы почитайте что я написал еще раз. На код свой посмотрите. И начнете удивляться КАК можно получить 2733 раза на таком коде, и нет ли тут каких других объяснений кроме в тысячи раз overhead-а CLR

Бенчмарк напишите нормальный. Тестирующий разное. Не double-linked список целых чисел (такое ни на C++, ни на .NET не бывает, и да на .NET будет медленнее из-за unboxing, но не в 2733 раза).

[ddv]

Бугага. Ну вы попробуйте если это неочевидно так. Hint: у std::vector есть vector.erase(vector.begin()). Делает примерно то что list.RemoveAt(0)

Вот об этом я и говорю...вы даже не понимаете в чем разница vector.erase(vector.begin()) и pop_front() в list и почему этого метода НЕТ у vector...А его нет потому что vector не предназначен для использования как связанный список с произвольным удалением элементов. Вам не приходило в голову, что vector это аналог массивов в CLR и удаление любого элемента кроме последнего приводит к необходимости КОПИРОВАНИЯ ВСЕХ оставшихся за ним элементов.

Теперь я понимаю почему у вас С++ работает с тойже скоростью что и C#.

[Zombie416]

Теперь я понимаю почему у вас С++ работает с тойже скоростью что и C#.

Потому что я понимаю чем std::vector отличается от std::list, а List<T> от LinkedList<T>, что они представляют из себя внутри, и т.д.

А вы - нет, даже после объяснений и совершенно невероятных результатов собственного кривого тестирования. Как грится, что и требовалось доказать. Язык ничто, человек - все.

[zzhou]

Ни разу за 10+ лет не приходилось такое делать. Но вот как надо извращатся в С чтобы XML разобрать или до БД добраться - это я видел.

Потому C он такой и компактный, что все фичи в библиотеках.

Правильно. В разных библиотеках разной степени кривизны. Но настоящие Сишники всё равно будут руками с нуля писать - чтобы не мучатся с чужими багами.

Аналог Hibernate на С++ насколько зрелый есть? Или какой-нибуть JSF.

XML и БД на C# и Яве - часть основной библиотеки. Без них не бывает.

[nightmare2]

Бла-бла это здорово, но вы попробуйте. Вот прямо своими руками. Могут быть очень интересные сюпризы. У меня были.

Ну попробовал...Сделал 2 консольные програмки на C++ и C#

Code: Select all

#include "stdafx.h"
#include <Windows.h>
#include <iostream>
#include <list>


int _tmain(int argc, _TCHAR* argv[])
{
	std::list<int>  list;
	timeBeginPeriod(1);
	DWORD time_start = timeGetTime();
	for (int i = 0; i < 1000; i++)
		for (int j = 0; j < 1000; j++)
			list.push_back(i + j);

	for (int i = 0; i < 1000; i++)
		for (int j = 0; j < 1000; j++)
			list.pop_front();

	DWORD time_end = timeGetTime();
	std::cout << "Time elapsed " << (time_end - time_start) << std::endl;
	timeEndPeriod(1);
	return 0;
}

Code: Select all

using System;
using System.Collections.Generic;
using System.Text;

namespace test_clr
{
    class Program
    {
        static void Main(string[] args)
        {
            List<Int32> list = new List<Int32>();
            int time_start = Environment.TickCount;
            for (int i = 0; i < 1000; i++)
                for (int j = 0; j < 1000; j++)
                    list.Add(i + j);

            for (int i = 0; i < 1000; i++)
                for (int j = 0; j < 1000; j++)
                        list.RemoveAt(0);

            int time_end = Environment.TickCount;
            Console.WriteLine("Time elapsed " + (time_end - time_start));
        }
    }
}

Так вот...CLR код работает около 164 секунд. А C++ вариант работает 60 МИЛЛИСЕКУНД!!! Это в 2733 раза быстрее!
Только запускать надо не из под отладчика, а из консоли. Под отладчиком C++ вариант работат 40 секунд (что все равно в 4 раза быстрее CLR), потому что отладчик ему мешает.

Попробуйте вот этот код.
У меня работает очень быстро.

Code: Select all

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace test
{
	class Program
	{
		static void Main(string[] args)
		{
			LinkedList<int> list = new LinkedList<int>();
		
			int time_start = Environment.TickCount;
			for (int i = 0; i < 1000; i++)
				for (int j = 0; j < 1000; j++)
					list.AddLast(i + j);
			
			for (int i = 0; i < 1000; i++)
				for (int j = 0; j < 1000; j++) {
					list.RemoveFirst();
				}

			int time_end = Environment.TickCount;
			Console.WriteLine("Time elapsed {0}", (time_end - time_start));

			Console.ReadLine(); 
		}
	}
}

.NET библиотека очень богатая, чего тут только нет.

[ddv]

А аналог std::list называется LinkedList<T>.

Вот с этого и надо было начинать...не все же знают что массив можно обозвать списком. Да ...теперь разница меньше - 2.5 раза...но и это далеко от одинаковой производительности...и даже от 50%-100% озвученных вами.

[nightmare2]

А аналог std::list называется LinkedList<T>.

Вот с этого и надо было начинать...не все же знают что массив можно обозвать списком. Да ...теперь разница меньше - 2.5 раза...но и это далеко от одинаковой производительности...и даже от 50%-100% озвученных вами.

Согласитесь, что это критично только для очень узкого круга задач.
Зато C# могут выучить все, а C++ только особо одаренные.
Программистов надо много, на всех спец мозгов не хватает.
Это как коробка автомат, для гонок не подходит, но до места довезет с комфортом.