strcpy(s1 + strlen(s1),s2)
действительно ограничивают количество повторного сканирования s1
с повторными вычислениями до дополнительной длины данного s2
в следующем раунде.
Но, IMO, вместо этого трюка лучше просто написать функцию, которая не требует какого-либо повторного сканирования:
char *
xstrcat(char *s1,const char *s2)
{
for (; *s1 != 0; ++s1);
for (; *s2 != 0; ++s1, ++s2)
*s1 = *s2;
*s1 = 0;
return s1;
}
void
func(char *s1,const char *s2,const char *s3,const char *s4)
{
s1 = xstrcat(s1,s2);
s1 = xstrcat(s1,s3);
s1 = xstrcat(s1,s4);
}
WCF является универсальным механизмом связи, который позволяет Вам устанавливать универсальную коммуникацию клиента/хоста между двумя сторонами. Аккуратная вещь о WCF, это, позволяет Вам настраивать свойства службы, такие как транспорт (http/pipes/tcp/Tibco EMS), модели обеспечения безопасности (любой из стандартов W3C), сжатие, кодирование, тайм-ауты, и т.д., не изменяя кода. Это мощно. Лучший из всех, можно настроить его так, чтобы у Вас могли быть сервис в C# и клиент в Java (или любой другой язык или наоборот), пока они оба разговор с помощью тех же механизмов.
можно создать стандартный HTTP веб-сервис SOAP с помощью WCF и однажды решить переключить его для использования более быстрых именованных каналов для местной связи. Можно создать веб-сервисы, которые обсуждают TibcoEMS и имеют легкую обработку отказа на уровне очереди. Можно создать файл, передающий потоком веб-сервис, который распределяет все виды изображений/видео к приложению.
Существует мало для добавления к ответам до сих пор, особенно тот от "siz".
Одна вещь добавить состоит в том, что WCF является текущим способом сделать веб-сервисы на платформе.NET. Это не "новый" путь, это - текущий путь. Веб-сервисы ASMX являются старым и едва-едва сохраняемым путем. Один сотрудник Microsoft публично заявил, что только критические исправления безопасности будут сделаны на платформу ASMX, поэтому если Вы предназначите для своих сервисов быть полезными больше чем год с этого времени, не используйте ASMX.
В дополнение к типичным вариантам использования "веб-сервиса", WCF обрабатывает нетипичные случаи, как двоичная коммуникация по именованным каналам, очередям сообщений, и т.д. К очень значительной степени, сервис, который Вы пишете для поддержки чего-то простого как SOAP по SSL, может также поддерживать эти другие протоколы без изменений в коде.
Существует много причин, почему это выгодно по классическим веб-сервисам ASP.NET (.asmx).
Несколько это первое, что пришло на ум:
способность иметь несколько привязки для того же служебного вызова означает, что сообщение не должно сериализировать в XML и назад если Вы просто хотите связаться в веб-ферме.
способ, которым определяются контракты, является намного более прощающим когда дело доходит до нескольких версий того же контракта.
По существу вариант использования - то, где Вы хотите, чтобы два отдельных приложения говорили друг с другом так или иначе, и их местоположения неизвестны (могла быть та же машина (но отличающийся домен приложения ), та же сеть или с другой стороны Интернета)
, можно легко встроить его в приложение Windows Forms . Это было хорошей вещью обнаружить. Это настолько легче, чем Дистанционная работа.NET также.