Autoit and the serious (comercial) project

[DoctorSLO]

Hi.

I just want to ask if any of you guys do some serius projects with autoit? If yes, what are your experiences?

And are you satisfied with autoit or would you prefer another programming language?

I'm about to start some project, but I don't know what to choose ... autoit or C# ?

Have a nice day

[GEOSoft]

It depends on just what the project is, some are suited to AutoIt while others should use a lower level language and C# would not be my choice there. The .NET framework is just far too cumbersome and slow.

[monoceres]

It depends on just what the project is, some are suited to AutoIt while others should use a lower level language and C# would not be my choice there. The .NET framework is just far too cumbersome and slow.

Wait a minute. In many ways C# is on a higher level and the execution speed of the clr is far superior to that of autoit.

To answer the OP's question what is best to slice a piece of bread, a kitchen knife or a chain saw?

[GEOSoft]

When I was toying with C# some time back I found that GUIs were particularily slow. C# is definitly slower that C++ which in turn is slower than pure C, so again it depends on what the OP wants to do.

[Richard Robertson]

If your libraries are compiled correctly, C# runs at the same speed as C++.

[Shafayat]

Personally I like to work with autoit as it is very simple and I've automatically memorized (I DID NOT try to memorize them. They just got memorized as they are fairly easy.) which is certainly not the case with c++ as I occassionally have to look in the msdn lib for information.

Then again there are times when autoit lacks. For example scite based project management for bigger projects is absolutely lousy compared to that of visual studio. Besides when you must make a win32 dynamic link library, you haven't really got a choice.

[Mat]

What I found was that for making your own GUI's and using them, C# wins by miles. However, trying to manipulate other windows is a pain and usually means going back to winapi again. Hotkeys are not built into c#. c# needs a runtime. c# is much more structured for larger projects. Classes are invaluable and make code so pretty.

So... What do you want to do?

[jvanegmond]

The language doesn't matter much. The developer is more important. If you can do the same job in AutoIt in 5 minutes that would take you 2 hours in C#, then AutoIt wins by 1 hour and 55 minutes.

Edited June 4, 2010 by Manadar

[czardas]

Yes some of my projects are serious. AutoIt's speed limitations are sometimes an issue. I particularly wish that AutoIt had built in sound wave functions. I don't really have enough time to devote to learning lots of new programming languages. I have targeted learning php as my next endeavour.

[Richard Robertson]

AutoIt needs a runtime too. It's just included in the final exe file. You can do that to C# too and compile in all your libraries to native code. The .Net framework just isn't meant for that kind of thing.

[Kip]

When I was toying with C# some time back I found that GUIs were particularily slow. C# is definitly slower that C++ which in turn is slower than pure C, so again it depends on what the OP wants to do.

That's not true at all. C++ isn't slower than C

C++ should be just as fast as C. If it isn't, there's something horribly wrong with your C++ compiler.

Edited June 7, 2010 by Kip

[monoceres]

That's not true at all. C++ isn't slower than C

C++ should be just as fast as C. If it isn't, there's something horribly wrong with your C++ compiler.

Writing C++ as you should write C++ makes C++ a slower language.

STL, objects (especially virtual method calls), RTTI and exceptions are all featurs that makes C++ slower than C.

But you're right that using C++ as C will make it just as fast.

Edited June 7, 2010 by monoceres

[evilertoaster]

As opposed to one language being faster than another, in practice it's more so about the style of programming. C++ being objected oriented often has real-word penalties to performance over a strictly procedural method of programming.

I'd recommend this slide show: http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf to anyone who has interest in the subject. It was introduced in a Stackoverflow "article" about a optimization:

http://stackoverflow.com/questions/2932515/effective-optimization-strategies-on-modern-c-compilers

[GEOSoft]

That's not true at all. C++ isn't slower than C

C++ should be just as fast as C. If it isn't, there's something horribly wrong with your C++ compiler.

You might want to research that Kip. C++ is slower than C and monoceres was correct in his assessment.

[Kip]

A piece of C code should run just as fast when compiled with a C++ compiler.

Using the default C++ library it's probably slightly slower. But the language C++ on it's own isn't slower than C. It's just the functions you are using and how you're using them.

Edited June 7, 2010 by Kip

[monoceres]

A piece of C code should run just as fast when compiled with a C++ compiler.

But C!=C++ so what's you point? If you're not using anything of the things I mentioned above you're not writing C++.

[Valik]

What's your point indeed? I ask what's your point to all of you involved in this absurd debate? If you want speed write assembly so you control every single instruction. Otherwise, who gives a fuck about the miniscule speed differences between C and C++ under certain circumstances? I'd rather write 30 lines of C++ and have it irrelevantly slower than write 90 lines of equivalent code in C.

Incidentally, if you think you can make a blanket "C++ is slower" statement you're a fool. For example, did you know that the calling convention can affect speed? Are you aware that equivalent C++ objects and C functions taking pointers to structures can produce equivalent code - or faster C++ code due to optimizations? Yes, there are features of C++ that slow things down, exceptions particularly. However a blanket "C++ is slower" statement is just plain stupid.

[jchd]

Kip, keep (oops) in mind that the very first C++ "compilers" were in fact simple (or not so simple) C++ preprocessors and the output fed to a standard C compiler. Of course the C++ language was at that time much less complete/complex than it is now. The evolutions of the C++ language specifications make it now plain impossible to simply preprocess C++ that way because the underlying structures have no equivalent in C.

The point is that any C++ compiler I know of has the ability to compile C code (modulo some option) the same way a C-only compiler would do. But in reality it's just a C compiler hidden there. That's what monoceres said to you: a piece of C code is ... well, C whatever the nickname the compiler bears. Look at which libraries get linked and you'll see that C is still C.

Now the actual burden resides in C++ constructs when your whole application uses an OO design. You may not notice much difference if you take a working C application and change it a little to simply use one native C++ construct or object in some part of your code. It's only when you build a complete OO design, typically with some large object library with multiple inheritance, that you notice that operations are significantly slower. OTOH you must admit to get more robustness, more power to send object to a display grid or sophiticated printing layout without caring at all how things work internally.

[monoceres]

My point is this (and I've had to correct people on this loads of times): Using C++ as C is not writing C++. That's all. Kip's statement indicated that the features I listed are just optional additions to the language, while in fact they're the heart of C++.

I know that the difference is small, and the difference is getting less and less relevant with modern computers, but keep in mind that time critical systems are still very much implemented in C. Operating systems and languages such as Python quickly comes to mind.

And yes, I rather too write in C++ than C. I personally think that C++ is the best language out there (close competition with Java).

[bo8ster]

Going back to the original question, it is pointless to argue which is the better language without knowing more about the 'project'.

When a project is started it goes through the project planning phase where the best tools and language is selected based off their particular strengths and weakness.

To properly do this you must first define the project you want to create. How large, GUI or cmd? More detail is required.

I have created commercial testing solutions using AutoIt but that was after I did a lot of research, looking at other tools. Based on my requirements I chose AutoIt.

ATM I am consulting on automated web service and web based testing, due to the requirements of each, AutoIt may not be the best solution. The business is currently looking other solutions to get the best fit.