Двунаправленные связанные списки
#1
Отправлено 27 апреля 2009 - 13:33
В C++ есть библиотека STL (стандартная библиотека шаблонов), где есть возможность создавать "листы", т.е. двунаправленные связанные списки...
Нет ли чего-нибудь подобного в рэшнл роботе?
#2
Отправлено 28 апреля 2009 - 06:26
Доброго времени суток, уважаемые коллеги!
В C++ есть библиотека STL (стандартная библиотека шаблонов), где есть возможность создавать "листы", т.е. двунаправленные связанные списки...
Нет ли чего-нибудь подобного в рэшнл роботе?
Насчет библиотеки не скажу, но если вам нужны двунаправленные связанные списки, то можно вместо них использовать массивы.
#3
Отправлено 28 апреля 2009 - 07:35
Доброго времени суток, уважаемые коллеги!
В C++ есть библиотека STL (стандартная библиотека шаблонов), где есть возможность создавать "листы", т.е. двунаправленные связанные списки...
Нет ли чего-нибудь подобного в рэшнл роботе?
Если нужно что-то специфическое, можно сделать .DLL (C++, VB, C#,...) и из Rational Robot вызвать функцию.
Declare Sub MySub Lib "MyDll"(ByVal x As Integer, y As String)
Сам использую C# (COM)
Set MyObject= CreateObject("MyNamespace.MyClass")
Result = MyObject.MyFunction(Param1 ,Param2 )
#4
Отправлено 29 апреля 2009 - 09:03
списки мне нужны как раз для того, чтобы избавиться от массивовНасчет библиотеки не скажу, но если вам нужны двунаправленные связанные списки, то можно вместо них использовать массивы.
#5
Отправлено 29 апреля 2009 - 09:21
У Rational Robot настолько убогий встроенный язык, что реализовать на нем двунаправленные списки не представляется возможным, или я чего-то не понимаю?
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#6
Отправлено 30 апреля 2009 - 06:08
Убогий по сравнению с чем? RR обладает схожим набором языков программирования, как и другие инструменты такого класса (QTP, TC).Можно дилетантский вопрос?
У Rational Robot настолько убогий встроенный язык, что реализовать на нем двунаправленные списки не представляется возможным, или я чего-то не понимаю?
#7
Отправлено 30 апреля 2009 - 09:25
В роботе есть возможность работать с указателями?
Можно ли создавать классы?
#8
Отправлено 30 апреля 2009 - 09:40
Можно дилетантский вопрос?
У Rational Robot настолько убогий встроенный язык, что реализовать на нем двунаправленные списки не представляется возможным, или я чего-то не понимаю?
Можно реализовать, но нужна немножко напрячься.
Насколько я знаю, готового решения нет.
#9
Отправлено 30 апреля 2009 - 09:53
Теперь я задам очередные свои дилетантские вопросы:
В роботе есть возможность работать с указателями?
Можно ли создавать классы?
Нельзя
#10
Отправлено 30 апреля 2009 - 12:15
По сравнению с нормальными языками программирования (C/C++, Java, C#, etc). Вообщем понятно, не более убог чем остальные уродцы :).Убогий по сравнению с чем? RR обладает схожим набором языков программирования, как и другие инструменты такого класса (QTP, TC).
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#11
Отправлено 30 апреля 2009 - 13:02
По сравнению с нормальными языками программирования (C/C++, Java, C#, etc). Вообщем понятно, не более убог чем остальные уродцы :).Убогий по сравнению с чем? RR обладает схожим набором языков программирования, как и другие инструменты такого класса (QTP, TC).
Молотком нельзя дрова колоть. И что, из-за этого молоток убогий инструмент?
Просто для решения задачи нужно выбирать подходящие средства.
А плохому танцору, как говорится…
#12
Отправлено 04 мая 2009 - 13:01
Мне кажется что и молотком можно успешно колоть дрова, если молотком стучать по топору сверху!Молотком нельзя дрова колоть. И что, из-за этого молоток убогий инструмент?
Просто для решения задачи нужно выбирать подходящие средства.
А плохому танцору, как говорится…
Ведь с помощью DLL можно использовать возможности более мощных языков:
Вот хочу научиться как создавать dll в C++Если нужно что-то специфическое, можно сделать .DLL (C++, VB, C#,...) и из Rational Robot вызвать функцию.
Declare Sub MySub Lib "MyDll"(ByVal x As Integer, y As String)
Сам использую C# (COM)
Set MyObject= CreateObject("MyNamespace.MyClass")
Result = MyObject.MyFunction(Param1 ,Param2 )
#13
Отправлено 04 мая 2009 - 16:23
Вот хочу научиться как создавать dll в C++
http://ru.wikipedia.....BE.D1.82.D1.8B
можно еще погуглить и найти как создавать в VisualStudio
#14
Отправлено 04 мая 2009 - 16:43
Встраивать в тулы "нормальные языки программирования" никто и не собирался... там вобще другой принцип работы.По сравнению с нормальными языками программирования (C/C++, Java, C#, etc). Вообщем понятно, не более убог чем остальные уродцы :).
Скриптовые языки для того и нужны, чтобы "быстро, без заморочек + весь ужас-ужас!! за нас уже сделали..." (углубляться не буду).
А платить приходиться отсутствием удобств, доступных в нормальных языках, потому что местами их просто не реализовать.
#15
Отправлено 05 мая 2009 - 04:59
Личное мне некоторых удобств в роботе очень не хватает, например, Code Explorer-а как в TestComplete. Иногда в роботе меня напрягает искать нужную функцию или процедру в коде, особенно когда этих функций много.Встраивать в тулы "нормальные языки программирования" никто и не собирался... там вобще другой принцип работы.По сравнению с нормальными языками программирования (C/C++, Java, C#, etc). Вообщем понятно, не более убог чем остальные уродцы :).
Скриптовые языки для того и нужны, чтобы "быстро, без заморочек + весь ужас-ужас!! за нас уже сделали..." (углубляться не буду).
А платить приходиться отсутствием удобств, доступных в нормальных языках, потому что местами их просто не реализовать.
#16
Отправлено 05 мая 2009 - 12:57
Компилируемость и/или интерпретируемость не есть свойство языка и никак не связано с его убогостью. Убогость в том, что в языках используемых в авто тулах, некоторые очень простые вещи не получаются быстро-быстро и без заморочек. Богаством стандартных и не очень библиотек они тоже не отличаются. Данная тема это показывает.Встраивать в тулы "нормальные языки программирования" никто и не собирался... там вобще другой принцип работы.По сравнению с нормальными языками программирования (C/C++, Java, C#, etc). Вообщем понятно, не более убог чем остальные уродцы :).
Скриптовые языки для того и нужны, чтобы "быстро, без заморочек + весь ужас-ужас!! за нас уже сделали..." (углубляться не буду).
А платить приходиться отсутствием удобств, доступных в нормальных языках, потому что местами их просто не реализовать.
Если хотите могу продолжить список интерпертируемыми языками Python, Ruby, Perl, Lua.
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#17
Отправлено 05 мая 2009 - 22:00
Компилируемость и/или интерпретируемость не есть свойство языка и никак не связано с его убогостью. Убогость в том, что в языках используемых в авто тулах, некоторые очень простые вещи не получаются быстро-быстро и без заморочек. Богаством стандартных и не очень библиотек они тоже не отличаются. Данная тема это показывает.
Если хотите могу продолжить список интерпертируемыми языками Python, Ruby, Perl, Lua.
Есть еще всякие факторы: совместимость, надежность, поддержка старого кода юзеров, уровень знаний, скорость разработки и т.п... Выбирают какой-то минимум для обслуживания своих незатейливых по типам параметров функций, а умным предлагают самовыражаться через COM.
Мне, например, интересно посмотреть, что задумали с двунаправленными связанными списками в тестировании GUI, и какой выигрыш ожидают получить в сухом остатке :)
#18
Отправлено 06 мая 2009 - 19:10
Что задумали...Есть еще всякие факторы: совместимость, надежность, поддержка старого кода юзеров, уровень знаний, скорость разработки и т.п... Выбирают какой-то минимум для обслуживания своих незатейливых по типам параметров функций, а умным предлагают самовыражаться через COM.
Мне, например, интересно посмотреть, что задумали с двунаправленными связанными списками в тестировании GUI, и какой выигрыш ожидают получить в сухом остатке :)
Пишу универсальные функции для тестирования ПО в своей компании, в процессе чего мне потребовалось хранилище данных, количество элементов в котором может быть самое разное, иногда не большое, иногда очень большое. В одном скрипте этих хранилищь может создаваться очень много. Элементы хранишища представляют собой тип:
Type Element a1 as string a2 as string a3 as string a4 as string a5 as string a6 as string a7 as stringEnd TypeЕсли в качестве хранилища использовать массив, то для него нужно будет заранее задавать достаточно большой размер, чтобы хватило места для добавления всех элементов, т.е. каждое хранилище будет забирать заранее определенное фиксированное количество памяти. Если в каждом скрипте будет создаваться много хранилищь, да еще если на одном компе будет запущено несколько виртуальных машин выполняющих один и тот же скрипт, то может и памяти не хватить.
Если в качестве хранилища использовать связанные списки, думаю "в сухом остатке" :) удасться выиграть некоторое количество виртуальной памяти, так как тут уже размер каждого хранилища будет зависеть от количества элементов....
#19
Отправлено 06 мая 2009 - 22:10
Что задумали...
Пишу универсальные функции для тестирования ПО в своей компании, в процессе чего мне потребовалось хранилище данных, количество элементов в котором может быть самое разное, иногда не большое, иногда очень большое. В одном скрипте этих хранилищь может создаваться очень много. Элементы хранишища представляют собой тип:Type Element a1 as string a2 as string a3 as string a4 as string a5 as string a6 as string a7 as stringEnd TypeЕсли в качестве хранилища использовать массив, то для него нужно будет заранее задавать достаточно большой размер, чтобы хватило места для добавления всех элементов, т.е. каждое хранилище будет забирать заранее определенное фиксированное количество памяти. Если в каждом скрипте будет создаваться много хранилищь, да еще если на одном компе будет запущено несколько виртуальных машин выполняющих один и тот же скрипт, то может и памяти не хватить.
Если в качестве хранилища использовать связанные списки, думаю "в сухом остатке" :) удасться выиграть некоторое количество виртуальной памяти, так как тут уже размер каждого хранилища будет зависеть от количества элементов....
В SQABasic, судя по документации, есть ReDim, позволяющий изменить длину массива.
И еще хочу затронуть некоторые моменты в Вашем ответе - может и получу в итоге познавательную для себя дискуссию, т.к. тема универсальности весьма интересна :)
Для тестирования GUI используется не так уж много наборов данных, и акцент идет на разную длину строк, на данные, которые открывают какие-то новые формы, и делается все для одного пользователя. Запуск на виртуальных машинах похож на нагрузочное тестирование, но честно говоря, никогда не получалось получить серьезную нагрузку, используя тесты для GUI.
При нагрузочном тестировании на практике у меня все сводилось к вычислениям: в памяти болтаются массивы с "индексами" важных объектов, позволяющие их однозначно определить, а все свойства/связи зависят от порядкового номера/счетчика/условий/"и т.п.". Из преимуществ могу обозначить, что не надо лепить километры данных при увеличении числа пользователей или объектов, можно исследовать различные ситуации, просто поменяв некоторые константы (больше одного, меньше другого).
Как-то так, если кратенько.
Честно говоря, с универсальностью особо и не сталкивалась, но интересно.
#20
Отправлено 21 мая 2009 - 07:16
Спасибо!В SQABasic, судя по документации, есть ReDim, позволяющий изменить длину массива.
Решил отказаться от создания двунаправленных списков:
Dim W() As Element Dim ElemCount As Integer 'размер массива ElemCount=0
Увеличиваем размер массива на 1:
ElemCount=ElemCount+1 ReDim Preserve CurElem(ElemCount) 'в этом случае данные которые уже содержал массив, сохраняются
Вот хочу избавиться от ElemCount, а нет ли в RR функции, позволяющей узнавать размер массива? Смотрел хелп, но ничего не нашел :(
Количество пользователей, читающих эту тему: 2
0 пользователей, 2 гостей, 0 анонимных