list

[baldr]

В STL  есть такой шаблон (?) как list.
Приведите, пожалуйста, пример как юзать его. Мне нужно пробежаться по всем элементам коллекции, содержащей объекты, отнаследованные от какого-либо базового класса (впрочем, это неважно что там лежит!), получить значение какого-то атрибута у каждого объекта...
  Я понял, что это делается через итераторы, но как конкретно получить объекты - я не догоняю... Подскажите?
  MFC не использую, так что CList не предлагать, если что...

[Serega]

Код:

#include <list>
#include <iostream>
#include <algorithm>
#include <functional>

struct Interface
{
	virtual void DoSomething(int n) = 0;
};

struct A : public Interface
{
	void DoSomething(int n) 
	{
		std::cout << "A::DoSomething() with " << n << std::endl; 
	}
};

struct B : public Interface
{
	void DoSomething(int n) 
	{
		std::cout << "B::DoSomething() with " << n << std::endl; 
	}
};

class DoingSomething
{
	int n;
public:
	DoingSomething(int num) : n(num) {}
	void operator()(Interface* obj)
	{
		obj->DoSomething(n);
	}
};

void main()
{
	std::list<Interface*> myList;

	myList.push_back(new A);
	myList.push_back(new B);

	//Способ 1
	std::for_each( myList.begin(), myList.end(), DoingSomething(5) );

	//Способ 2
	std::for_each( myList.begin(), myList.end(), 
		std::bind2nd( std::mem_fun(Interface::DoSomething), 5 ) );
};

[Serega]

Код:

   std::list<Interface*> myList; 

   myList.push_back(new A); 
   myList.push_back(new B);

это конечно не хорошо, лучше оборачивать указатели в смартпойнтеры

[Sommer]

baldr,
а чего бы не использовать свой (созданный руками)односвязный список?...

[.]

mandela, Правильно, и работает быстрее!

[sas]

Код:

   std::list<Interface*> myList; 

   myList.push_back(new A); 
   myList.push_back(new B);

это конечно не хорошо, лучше оборачивать указатели в смартпойнтеры

Sorry for english, but which one? If you are talking about standard auto_ptr, then you are not right at all.

Thanks
--- sas

[sas]

В STL  есть такой шаблон (?) как list..

Better say container

Thanks
--- sas

[sas]

baldr,
а чего бы не использовать свой (созданный руками)односвязный список?...

Why do you want to reinvent the wheel? It is always better to learn something new and use standard staff. For most of the cases it will be more clear to other people, work faster, be more extensible etc. If you think that your list will be more effective then the standard one, then may be better to play with allocator for it or just change STL implementation library.

My 2 cents
--- sas

[Serega]

Sorry for english, but which one? If you are talking about standard auto_ptr, then you are not right at all.

Конечно же я имел ввиду не auto_ptr, он для других вещей
Мне нравятся пойнтеры из Loki

[Serega]

Why do you want to reinvent the wheel? It is always better to learn something new and use standard staff. For most of the cases it will be more clear to other people, work faster, be more extensible etc. If you think that your list will be more effective then the standard one, then may be better to play with allocator for it or just change STL implementation library.

My 2 cents
--- sas

Очень сложно людям которые всю жизнь писали каждую мелочь сами привыкнуть что есть очень много вещей давным давно уже написаных, причем людьми которые намного компетентнее в этих вопросах всех нас вместе взятых =)
А есть люди которым просто нравится еб..ть себе мозг над каждой мелочью, хотя я считаю что есть занятия намного интереснее изобретения велосипеда

[Sommer]

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

[Гром]

Насчет мелочей, общий темп класс или контейнер для связного списка писать самому я не буду.
А теперь маленький пример, есть сервер, в нем бежит поток принимающий данные на select и отправляющий пакеты приходящие over TCP от колиентов в очередь.
Есть второй поток -сортирующий эти пакеты распаковка там, еще прибамбасы + кэш само собой и ставится в другую очередь на отправку реальному серверу.

Третий поток отправляющий эти пакеты далее.

Итак типа прокси с своими внутренними заморочками.
Между клиентами и этим сервером свой простенький протокол, а дальше все бежит обычно ... по TCP

Задача - не просто написать такой сервер, а сделать его портируемым на системы от Unix Solaris Sun до WinXP... Включая Линуксы ФриБСД и др.

Ответте мне - поборники использования готовых примеров - какие же средства разработки вы возьмете...  :?:


А теперь для тех кто не догадался!!!!

Берется Berkly Sockets + C даже не С++.

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

А сервер еще требует не столько универсализма, сколько адаптации по скорости, он для этого и создается....
И решение найдено, для очередей и данных пишутся свои хэш таблицы, связные спискы, конечные автоматы не объектами даже , а их превестниками модулями в h файлах с кучей переопределенных common функций для совместимости.
И то получается довольно большая момрока с своместимлстью сокетов и потоков, так как и никсы от винды отличаются по реализации и того и другого как в работе селекта, так и в форках....

Итак где вы ребятушки - возражайте....  

[grozny]

Насчет мелочей, общий темп класс или контейнер для связного списка писать самому я не буду.
А теперь маленький пример, есть сервер, в нем бежит поток принимающий данные на select и отправляющий пакеты приходящие over TCP от колиентов в очередь.
Есть второй поток -сортирующий эти пакеты распаковка там, еще прибамбасы + кэш само собой и ставится в другую очередь на отправку реальному серверу.

Третий поток отправляющий эти пакеты далее.

Итак типа прокси с своими внутренними заморочками.
Между клиентами и этим сервером свой простенький протокол, а дальше все бежит обычно ... по TCP

Задача - не просто написать такой сервер, а сделать его портируемым на системы от Unix Solaris Sun до WinXP... Включая Линуксы ФриБСД и др.

Ответте мне - поборники использования готовых примеров - какие же средства разработки вы возьмете...  :?:


А теперь для тех кто не догадался!!!!

Берется Berkly Sockets + C даже не С++.

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

Итак где вы ребятушки - возражайте....  

почему берётся именно Berkly Sockets + C  и как это соотносится с использованием примеров - не понял. И даж на голом С есть масса заготовок, особенно под сокеты.

Ты ФОРТРАН или КОБОЛ брать не пробовал?  :twisted: Так с ними сокеты ещё бородатее.

Абсурд - всё писать своими руками. Такое моё мнение. Код надо реиспользовать по макимуму и писать стремиться писать максимально реиспользуемый код.

STLport/С++ - наш ответ. Знаю писателя и его движок, который раздаёт видео по коробочкам через кабель. В коробочках какая-то совсем кривая порезанная версия фряхи. И есть версия для десктопов (винды/линукс/фряха - пофигу). Написано на С++/STLport.  

А изобретать велосипед мне лично давно надоело. Только если стандартный ширпотреб не годится. Что случается всё реже и реже.

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

[Гром]

Любой универсализованный класс объект заготовка и т.д. априори перегружен ненужными в конкретном случае, действиями и работает на порядок медленне конкретного написанного и адаптированного под задачу. BSD сокеты сегодня единственные которые работают всегда и везде...
Причем тут Фортраны??? Сокеты этого типа наиболее универсальны...
Совершенно в этом твоих претензий не понимаю.

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

[baldr]

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

Код:

typedef list <myClass> myList;

myList sList;
...

myList::iterator f;
for (f=sList.begin(); f!=sList.end(); ++f)
{

}

Вот такой цикл работает... Пример, кажется, из MSDN... Но КАК внутри цикла получить значение текущего объекта?

[grozny]

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

с этим не спорю, это так. Вопрос в другом: где узкое место, какие метрики у проекта.
Если время написания - STL лучше практически всегда. Если размер и скорость - твой собственный код, заточенный под задачу, всегда будет оптимальнее общего случая как по размеру так и по скорости.

Меня удивил выбор инструментария - С и сокеты. Вместо С++, STL и сокеты. В то, что именно производительность STL была бы узким местом в приведённом тобой примере - не поверю. Только если речь идёт о гигабитных потоках на десяток клиентов. И то зависит от проца и размера памяти.

Опять-таки построить прототип системы с использованием STL, а потом вместо std::list<> подсунуть myveryfastandclever::list<> - нефиг делать.

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

безусловно. STL при всем при том одна из наиболее легко портируемых библиотек. Да и есть она везде. В отличие от сокетов вариаций от системы к системе очень мало.

[Гром]

Речь идет о производственном провайдерском сервере на диал-апе, так что клиенты исчисляются не десятками а сотнями и даже тысячами ...

В чем проблема Берклиевских сокетов - назови мне другойц тип сокетов подошедших бы к этому случаю.

С++ - не портируется с такой легкостью и проблема в реализации объектов и оптимизации кода - там боролись за миллисекунды.
Так что STL не только по времени и размеру была бы помехой но и портируемость - при всей ее легкости увеличивалась бы по времени.

[sas]

1) So according to your logic why to use BSD sockets lib? You can develop your own small and fast version which will work better (without all unneccessary stuff in it).  ). Regarding C lists you can find a lot of implementations which will work fine for you. Do not see neccessity to develop your own version especially for relatively small task. Again for thousands of clients single linked list is not so good  (element access time linear depend on the list's size).

2) Portablility: yes C++ especially with templates was not very portable, but situation is much better now. With latest MS and gcc compilers it will work almost on all platforms.

3) STL can be almost as efficient as plain C( btw in some cases good written Java code will be far more fast then bad written C/C++).

4) Again when programmer chooses what tools to use in development of the particular task depends on many factors: Time, money he's own language and tool knowledge, preferences etc.

Conclusion:

Do not want to participate in the flame wars about C/C++ (love both), but everybody will agree that libraries are written to:
a) speedup application development time
b) reduce number of errors
c) reduce maintenance burden

Also please do not forget that if you are using C++ it is better to use it's standard features (in our case STL) (not mandatory obviously, but...), since people who created all those libraries included in the standard already proved that their ideas are useful.

Please stop this childish stuff to measure who is bigger and stronger and smarter and ...

My 2 cents
---sas

[baldr]

Ребята! Не отвлекайтесь!  У меня все еще проблема с этим листом!

[grozny]

миллисекунды... doh! у нас драйвер борется за десятки нан... на С++.
Правда, STL не используем, но по уважительной причине - отсутствия С++ рантайм для ring0.

Да проблема не в Берклийских сокетах, а в том, что почему-то взят голый С. Не вижу, как BSD сокеты могут мешать использованию С++ и STL.

В теории STL должна справиться с твоей задачей:
Ну сам прикинь - тыща клиентов на диалап=50 мегабод. Пакет в 1к (условно), 50 к пакетов/сек. В чём проблема? Вставлять/вынимать 50 тыщ пакетиков за сек из списка? На ЦПУ 500 МГц у тебя будет 5000 тактов на пакет, что есть дофига даж для нешустрого STL. (я положил 5000 тактов на ОС и прочая). Даж если подвигать условия и сказать, что у нас 10000 юзеров - всё равно 500 тактов - дофига. Ну и процы счас не 500 МГц.

Да, портировать С++ всё ещё геморройно. Хотелось бы поспорить, но факт есть такой.

Честно говоря, для данной конкретной задачи я б тож обошёлся голым С   - список написать или вектор - это не map свалять и уж не потоковый ввод-вывод...

Что не есть повод утверждать, что stl надо позабыть как неэффективный инструмент. Вот не так давно у коллеги багульник вылез именно в его доморощенном списке. В редком, запущенном случае список не терминировался   ...

[Гром]

Что не есть повод утверждать, что stl надо позабыть как неэффективный инструмент.

Ну я этого не говорил.

Да проблема не в Берклийских сокетах, а в том, что почему-то взят голый С. Не вижу, как BSD сокеты могут мешать использованию С++ и STL.

И этого я не говорил, я написал выбор, а то что BSD сокеты мешали C++ тоже не писал.  8)

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

В общем неважно

[Serega]

Код:

typedef list <myClass> myList;

myList sList;
...

myList::iterator f;
for (f=sList.begin(); f!=sList.end(); ++f)
{

}

Вот такой цикл работает... Пример, кажется, из MSDN... Но КАК внутри цикла получить значение текущего объекта?

Код:

for(...)
{
    DoSomething(*f);
}

Гром выложи док по STL, хоть он немного старый, но концепции не меняются

[baldr]

мда...  

[sas]

Something like this:

Код:

#include <list>
#include <iostream>
#include <iterator>
#include <algorithm>

using namespace std;

const int START_INT = 15;
const int END_INT = 24;

int main()
{
    list<int> int_lst;

    for ( int i = START_INT; i <= END_INT; ++i ) 
        int_lst.push_back( i );
    // check our list contents...
    copy( int_lst.begin(), int_lst.end(), ostream_iterator<int>( cout, "\n" ) );
    
    cout << "ELEMENT ACCESS: _________________________________\n";
    list<int>::const_iterator it = int_lst.begin(), end_it = int_lst.end();
    for ( int i = 0; it != end_it; ++it, ++i )
        cout << "list el[ " << i << " ] = " << *it << "\n";

    return 0;
}

Code was not compiled, so sorry for possible errors

God luck
--- sas

[Гром]

Serega, где мне его взять??? Или ты имеешь ввиду твою статью - если второе так выложу - если что другое напиши название...

[Serega]

Гром, никто не говорит об использовании STL в любой программе
!!! НО !!! STL жестко регламентирует время работы своих алгоритмов
На мой взгляд единственное чем можно ускорить работу это изменить стратегию выделения памяти, т.к. по умолчанию используется new
Так-что если с умом подойти к написанию своего аллокатора, скорость работы будет близка к идеальной (конечно быстрее работать будет программа написанна на ассемблере, хотя это зависит от "ловкости рук" =)
По-моему в STL из C++ используются только классы, наследование и перегрузка операторов, ни одна из этих вещей не делает программу на C++ медленнее чем на C, но вот вопросы простоты, наглядности, скорости разработки встают сразу

[Serega]

Serega, где мне его взять??? Или ты имеешь ввиду твою статью - если второе так выложу - если что другое напиши название...

Я тебе много книг залил, среди них есть "Standard Template Library Programmer's Guide"

[baldr]

sas, спасибо!
И почему я просто не догадался разыменовать итератор?? ))

[Гром]

На мой взгляд единственное чем можно ускорить работу это изменить стратегию выделения памяти, т.к. по умолчанию используется new

Ьы не прав, однозначно - конкретная кольчевая очередь очень даже может быть адаптирована, а если есть система поиска так тем более....

Плюс алгоритмы добавки и удаления произвольных элементов, если скажем в очереди стоит 3-4 пакета а пришел запрос на закрытие сокета UBNORMAL TERMINATED, то что делать - куда передавать, надо найти и выкинуть такие пакеты, или ждать когда они сами выйдут из очереди и тогда выкинуть...

Ну и кстати мы таки использовали malloc + free а в Solaris побирали еще и билиотеки для нормальной работы.!!!!

Я тебе много книг залил, среди них есть "Standard Template Library Programmer's Guide"

Сегодня будет и твоя статья и эта книга - зуб даю

[Джон]

blard, Парни совсем съехали и про тебя забыли.

Ставлю на вид - вместо того, чтоб человеку помочь - устроили базар!
к Серёге (за последнее собщение - это не относится)

STL - люблю и уважаю, хотя бы потому, что это разработка нашего соотечественника и использую там где возможно. Хотя не часто.

представь по аналогии

int x[10], *pn;

for (pn=x; pn != x+10; pn++)
{
   pn - указатель на текущий объект
  *pn - сам объект
}

часто, если у тебя список указателей, то для

std::list<CMyClass*> m_lst;
std::list<CMyClass*>::iterator i = m_lst.begin();

доступ к членам класса
     (*i)->
а не:
     *i->

тк -> выполнится перед *