why should you use c++ in such project ?
in [C++]
|
Prev: Assignment operator definition required in case of reference data member why?
Next: Converting from int** to vector< vector<int> >&
From: Deep_Feelings on 18 May 2010 06:55 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 -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Öö Tiib on 18 May 2010 11:03 On 19 mai, 00:55, Deep_Feelings <doctore...(a)gmail.com> wrote: > 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 ? Depends what you value. Your time or time of users of your software. Between C++ and python it is difference between half a second or five. If there is any possibility to choose then users will therefore pick the product written in C++. > 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. One should write big part of code for unknown domain with intent to throw it away later. Scripts make throwing it away simpler. So there are no antagonism and competition between compiled and scripted languages that you imagine there is. Scripts make continuous integration lot easier and you have lot sooner to show something to possible users or to the people who pay for development. Modern software product is not something like 100 or 1000 lines of code. It is usually like 100 000 lines or bigger. Being agile is therefore very important. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Dan McLeran on 19 May 2010 01:14 On May 18, 8:03 pm, �� Tiib <oot...(a)hot.ee> wrote: > On 19 mai, 00:55, Deep_Feelings <doctore...(a)gmail.com> wrote: > > > 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 ? > > Depends what you value. Your time or time of users of your software. > Between C++ and python it is difference between half a second or five. > If there is any possibility to choose then users will therefore pick > the product written in C++. > > > 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. 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. > One should write big part of code for unknown domain with intent to > throw it away later. Scripts make throwing it away simpler. So there > are no antagonism and competition between compiled and scripted > languages that you imagine there is. > > Scripts make continuous integration lot easier and you have lot sooner > to show something to possible users or to the people who pay for > development. Modern software product is not something like 100 or 1000 > lines of code. It is usually like 100 000 lines or bigger. Being agile > is therefore very important. > -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Nick Hounsome on 19 May 2010 01:18 On 18 May, 22:55, Deep_Feelings <doctore...(a)gmail.com> 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. This is "begging the question". Lines of what? C or python? > 2- not a low level (driver / OS level) program. Not specific enough. Is it GUI? Is it string manipulation? These will typically be much shorter in scripting languages whereas lots of mathematical processing wont be. > > 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 ? There are really only 2/3: Better performance is possible but nowhere near as important as most people make out because the biggest performance problems are often bad design or simple I/O limitations which can't be improved much. Compile time checking - The C++ compiler will prevent many errors that will only turn up at runtime in scripting languages. For the same level of correctness you will therefore typically need to write more tests for a scripted app. Integration - C/C++ integrates with everything. scripting languages only integrate via C or COM. In particular you face some difficult choices if you want to use a scipting lanuage and Java or .NET -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Kenneth 'Bessarion' Boyd on 19 May 2010 01:31
On May 18, 4:55 pm, Deep_Feelings <doctore...(a)gmail.com> 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. This isn't nearly enough for a software analyst to actually give a definitive answer. For purposes of discussion, let us assume that a line of code is at most 79 characters of screen width (i.e. fits conveniently in a vi editor window). [Note: I don't use vi as my dominant editor, and I do let lines sprawl out to at least 210 characters without blinking in my in-house projects. But I do think of a 210-character line as imparting as much source code complexity as three standard vi-friendly lines of code.] > question : since developing my program in ruby or python will be much > faster(i assume) The absence of reasonable compile-time errors in scripting languages is responsible for maybe 33% of my billable time on webserver application maintenance and development. [Note that there is no real option for using a compiled language in that environment, so this is acceptable overhead. It's not a 33% loss of productivity because it really does require less lines of code to express what to do in a major scripting language, when you're exploiting the syntactical idiosyncrasies of the scripting language to the hilt.] > what are the reason(s) why i should consider using c++ over ruby /python for such project ? I won't speak about Ruby as I haven't intensively used it, but I have used Python when it was a better fit. [And why not mention the more widely used scripting languages PHP and Perl while we're at it?] There are two reasons why, given a target environment that actually permitted choosing between C++ and Python for implementing a program, that merely knowing the program would be 1000 or more lines of code would almost dictate using C++ rather than Python, if I was the project manager and had a programming team equally skilled in both C++ and Python. 1) It's faster to find bugs at compile-time than run-time. Assuming: * "sufficiently large" program (threshold for me personally is somewhere between 100 and 1000 lines of code excluding comments, Your Mileage May Vary) * closely comparable programmer team fluency in the languages of choice * closely comparable fit of program domain to the language one should favor the language that provides extensive compile-time errors for real bugs. Note that "program domain" is very important here. If the proposed application is simply a huge text processor *and* there's good reason to think the application can be written in Python to avoid creating and destroying Python-immutable values thousands of times per second, then the problem domain favors Python tremendously, and the lack of compile-time errors won't matter until the program is somewhat larger. [Not to mention that the lines of code count in Python just went down by a factor of two simply because it's a text-processor being implemented.] If it's a heavily numerical application, then not even the PyNum library will save you -- the problem domain is stacked towards C, C++, and FORTRAN. [The main reason to favor C++ over C is the Standard Library. There really is no reason to take any schedule risk with debugging the most noxious C bugs (I/O and memory) in C++.] Also, fluency in the language (within the programming team) matters. A programmer that is looking up intermediate-skill language structures every five minutes just isn't going to be as productive as one who has those learned intensively. [This reduces my productivity in Python, relative to C++, by about 50%.] 2) C++ inherits, from C, the assert macro for run-time assertions. This makes implementing Design by Contract moderately feasible by checking function preconditions and postconditions at runtime. Whether magic constants are defined reasonably can be checked at compile time even in C++98 or C90. This gets much easier with proper static assertion support from one of the Boost libraries, or a compiler that supports C++0X static assertions. (C1X also has static assertions but the syntax is a little different.) Just *don't* define the NDEBUG macro for testing (to get the run-time assertions), and *do* define the NDEBUG macro for release (to get the performance back). Design by Contract slows initial development down slightly -- but there's nothing like trying to bring up a new feature, running a test suite, and *immediately* getting the exact location where the first trace of a data structure integrity bug is visible for development time. It's most useful exactly when compiler errors become highly useful : those 1000+ lines of code projects. (Of course, C++ and C aren't the only languages that support Design By Contract -- but I know first-hand that none of Python, Perl, or PHP do. Making those debugging checks disappear requires changing the source code in those languages.) -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |