Prev: Assignment operator definition required in case of reference data member why?
Next: Converting from int** to vector< vector<int> >&
From: Hakusa on 19 May 2010 07:25 On May 18, 5:55 pm, Deep_Feelings <doctore...(a)gmail.com> wrote: > 1- the length of source code is in the magnitude of few hundreds to > few thousands lines of code. > 2- not a low level (driver / OS level) program. Since you don't yet know what language you'll use, how can you guarantee this magnitude? Perhaps in one language, a library does already 90 percent of what you need, but in c++ you have to do all the work. It could be the other way around. > question : since developing my program in ruby or python will be much > faster(i assume) what are the reason(s) why i should consider using c+ > + over ruby /python for such project ? It kind of sounds like you don't know Ruby/Python, but are considering doing a large project with it. Consider that Python at least (i'm unfamiliar with Ruby) can be embedded into a C++ application and the Python interpreter can be extended with C. Consider using Boost::python. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: DeMarcus on 19 May 2010 07:24 On 2010-05-18 23:55, Deep_Feelings wrote: > I read all over the web about how scripting programming languages > (like ruby or python) are fast for writing programs quickly. so i > would like you to consider a programming project that is : > > 1- the length of source code is in the magnitude of few hundreds to > few thousands lines of code. > 2- not a low level (driver / OS level) program. > > question : since developing my program in ruby or python will be much > faster(i assume) what are the reason(s) why i should consider using c+ > + over ruby /python for such project ? > > sharing your practical experience will be greatly appreciated. > > thank you > If you have a waiting customer it could be an idea to start with a scripting language to get something up running for them fast. When your customer now has something to work with you can start discuss future development. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Öö Tiib on 19 May 2010 07:42
On May 19, 7:14 pm, Dan McLeran <danmcle...(a)yahoo.com> wrote: > On May 18, 8:03 pm, �� Tiib <oot...(a)hot.ee> wrote: > > On 19 mai, 00:55, Deep_Feelings <doctore...(a)gmail.com> wrote: > > > > > sharing your practical experience will be greatly appreciated. > > > Practical experience is that prototypes, tools and plug-ins are > > initially often written as scripts to save development time. Core > > application logic is written as C++ to save end-user time. When > > product evolves then some scripts are often replaced with C++ to > > improve performance and some may remain scripts forever. > > In my experience, Python's speed is plenty good for most code. The domains and so requirements for speed vary. Often it is pure C++ that needs (and can, and is paid for) to be made just somewhat faster or less resource consuming. When application is idleing mostly waiting behind some other bottleneck like external or user I/O the speed of python is plenty. These are unfortunately also the places from where the dirty/malicious/hostile data is entering your software. > In my > last major software effort, I used Python where I could and C++ where > I had to for speed reasons. Check out the ctypes module for a great > way to call into C++ dlls, provided you provide a calling interface > using C types extern C linkage. Thanks, i prefer Boost.Python. Provides better interface between python and C++ than C. Of course even that is matter of taste and depends on other context, too. I still view Python code as temporary throw-me-away-later or leave-me- for-developers-only. You need 100% code coverage with tests, to be sure that it is all at least valid code. If python is really meant to stay as user interface then hire armies of user interface testers to try it branch by branch in python code. Or amounts of automatic test scripters. Or both. That makes the point about "development costs" moot. If no one ever cares if it is valid code and stable product then the whole project smells like job security for maintainers of it. I would turn down calls to participate in making such things (but again goals of people vary). -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |