Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #8515 > unrolled thread

Why use C++?

Back to article view | Back to comp.lang.c++

Contents

  Why use C++? Miro <nickbergeronsemail@gmail.com> - 2011-08-06 14:00 -0700
    Re: Why use C++? jt@toerring.de (Jens Thoms Toerring) - 2011-08-06 22:29 +0000
    Re: Why use C++? SG <s.gesemann@gmail.com> - 2011-08-12 02:11 -0700
      Re: Why use C++? James Kanze <james.kanze@gmail.com> - 2011-08-21 16:44 -0700
        Re: Why use C++? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-23 01:47 -0700
          Re: Why use C++? Dombo <dombo@disposable.invalid> - 2011-08-23 20:01 +0200
            Re: Why use C++? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-01 02:08 -0700
          Re: Why use C++? James Kanze <james.kanze@gmail.com> - 2011-08-26 08:25 -0700
            Re: Why use C++? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-01 02:43 -0700
              Re: Why use C++? James Kanze <james.kanze@gmail.com> - 2011-09-01 15:51 -0700
    Re: Why use C++? Krice <paulkp@mbnet.fi> - 2011-08-13 01:09 -0700
      Re: Why use C++? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-23 02:08 -0700
      Re: Why use C++? Michael DOUBEZ <michael.doubez@free.fr> - 2011-08-23 03:33 -0700
    Re: Why use C++? Noah Roberts <roberts.noah@gmail.com> - 2011-08-27 12:38 -0700
      Re: Why use C++? "Duga Chernobyl" <duga_c3@gmx.com> - 2011-08-28 14:37 +0200
        Re: Why use C++? James Kanze <james.kanze@gmail.com> - 2011-08-29 04:11 -0700
          Re: Why use C++? Noah Roberts <roberts.noah@gmail.com> - 2011-08-29 16:25 -0700
            Re: Why use C++? Juha Nieminen <nospam@thanks.invalid> - 2011-08-30 05:57 +0000
        Re: Why use C++? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-01 02:45 -0700
      Re: Why use C++? Alexei Zakharov <alexeiz+usenet@gmail.com> - 2011-08-28 17:52 -0400
        Re: Why use C++? Nobody <nobody@nowhere.com> - 2011-08-29 07:06 +0100
          Re: Why use C++? James Kanze <james.kanze@gmail.com> - 2011-08-29 04:17 -0700

Page 1 of 2  [1] 2  Next page →

#8515 — Why use C++?

I've made the title too provocative. What I mean is, why use C++ for
small ( > 1000 lines ) coding jobs?
It doesn't make much sense to me as...

C++ syntax requires a lot more typing, debugging and memory,
Compilation time can be irksome,
C++ is devoid of the plethora of features you find on Python, Ruby or
our dear Swiss Army Chainsaw.

Don't get me wrong, I don't dislike C++, nor am I trying to rile up
the great gurus among us, however, I fail to see a practical reason to
use this language much as I go about my hacking life.
I understand that it compiles directly into binary and can be from
there run without an interpreter, but that seems a small price to pay
for a five line ( in good practice ) hello world.

Miro

[toc] | [next] | [standalone]

#8522

Miro <nickbergeronsemail@gmail.com> wrote:
> I've made the title too provocative. What I mean is, why use C++ for
> small ( > 1000 lines ) coding jobs?

I guess you meant "< 1000 lines"...

> It doesn't make much sense to me as...

> C++ syntax requires a lot more typing, debugging and memory,

C++ syntax doesn't need memory, and debugging only required if
you made mistakes (which is not so much different from a script
written in an interpreted language, I think).

> Compilation time can be irksome,
> C++ is devoid of the plethora of features you find on Python, Ruby or
> our dear Swiss Army Chainsaw.

> Don't get me wrong, I don't dislike C++, nor am I trying to rile up
> the great gurus among us, however, I fail to see a practical reason to
> use this language much as I go about my hacking life.
> I understand that it compiles directly into binary and can be from
> there run without an interpreter, but that seems a small price to pay
> for a five line ( in good practice ) hello world.

Well, you can have a "hello world" program in two-to-five lines
of C++, depending on the way you lay-out things;-) And if all
you do is writing "hello world" programs then it is rather ir-
relevant which language you use.

Otherwuse your question is comparing apples to bananas. In
many cases load and compilation/interpretation times aren't
of much concern. Then use the language you feel most at home
with to get the job done and which is most expressive (i.e.
that requires the least typing and gives you the least chance
of making mistakes - like I would not dream of writing a C++
program when I have to e.g. convert the format of a few data
file when it can be done in Perl or sed or something similar
I am familiar with in a one-liner).

On the other hand some programs that need to be run very often
can be a lot faster when written in a compiled language since
the overhead of starting the interpreter and having it inter-
pret the script tends to be a lot higher than starting a short
compiled program (even if the actual task requires only a rather
small number of lines of code). I often start by writing such
things in an interpreted language I know well enough but when
I find that they are becoming a bottleneck I rewrite them in
C or C++.

Then there are programs that require all the speed you can squeeze
out of your machine or that need all the memory available etc.
(and that is not necessarily directly related to number of lines
of code). Those are the ones I wouldn't consider writing in an
interpreted language (except perhaps for a proof-of-concept im-
plementation).

And, of course, there are also quite a number of cases where
the parts that really need to be fast and make the most effi-
cient use of memory can be written in a compiled language like
C++ and the other parts in an interpreted language. So there's
really no one-is-better-than-the-other but an (hopefully edu-
ctated) choice of what to use in a certain situation.

                             Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#8701

On 6 Aug., 23:00, Miro wrote:
> I've made the title too provocative. What I mean is, why use C++ for
> small ( > 1000 lines ) coding jobs?
> It doesn't make much sense to me as...
>
> C++ syntax requires a lot more typing, debugging and memory,
> Compilation time can be irksome,
> C++ is devoid of the plethora of features you find on Python, Ruby or
> our dear Swiss Army Chainsaw.

Since I just recently wrote a small tool in C++ (around 300 lines of
code) that simply transforms one text-like file to another file, I'll
try to explain why I did this in C++:

 - I know C++ well enough and appreciate the higher level
abstractions.
   They make this sort of thing fairly easy to write. I don't think a
   Python solution to this problem is significantly smaller in terms
of
   source code size.
 - I don't know any scripting language well enough to do the job,
   although I was planning to get more accustomed to Python
eventually.
 - I like static typing. I don't like assigning random sh*t to other
   random sh*t and hoping that it all works out at runtime.
 - C++ doesn't require you to install a VM or interpreter.

Cheers!
SG

[toc] | [prev] | [next] | [standalone]

#9147

On Aug 12, 10:11 am, SG <s.gesem...@gmail.com> wrote:
> On 6 Aug., 23:00, Miro wrote:

> > I've made the title too provocative. What I mean is, why use C++ for
> > small ( > 1000 lines ) coding jobs?
> > It doesn't make much sense to me as...

> > C++ syntax requires a lot more typing, debugging and memory,
> > Compilation time can be irksome,
> > C++ is devoid of the plethora of features you find on Python, Ruby or
> > our dear Swiss Army Chainsaw.

> Since I just recently wrote a small tool in C++ (around 300 lines of
> code) that simply transforms one text-like file to another file, I'll
> try to explain why I did this in C++:

>  - I know C++ well enough and appreciate the higher level
> abstractions.
>    They make this sort of thing fairly easy to write. I don't think a
>    Python solution to this problem is significantly smaller in terms
> of
>    source code size.

I've yet to see anything that wouldn't be shorter in Python than
in C++.  More significantly, it's generally easier to develop
iteratively in an interpreted language, simply because the
turn-around time is much, much shorter.  And the "bad"
techniques, like just typing in code without having done any
design, don't really make such a difference in very small
programs.  Historically, I've used AWK for anything up to about
500 lines; I've recently shifted to Python (mainly because
Python will be installed on all development machines, where as
there are only three or four of us who have AWK on our Windows
machines).

>  - I don't know any scripting language well enough to do the job,
>    although I was planning to get more accustomed to Python
> eventually.
>  - I like static typing. I don't like assigning random sh*t to other
>    random sh*t and hoping that it all works out at runtime.

It's not a question of "liking": static typing saves you from
all kinds of problems once the program gets a bit bigger.

>  - C++ doesn't require you to install a VM or interpreter.

But it does require you to install a compiler on the machine you
develope on:-).  (Until about two years ago, I worked
exclusively in Unix environments.  A shell was always present,
with awk, sed, and the like.  Which meant that scripts could be
used portably, without installing anything special.)

--
James Kanze

[toc] | [prev] | [next] | [standalone]

#9221

On Aug 22, 12:44 am, James Kanze <james.ka...@gmail.com> wrote:
> On Aug 12, 10:11 am, SG <s.gesem...@gmail.com> wrote:
> > On 6 Aug., 23:00, Miro wrote:


> > > I've made the title too provocative. What I mean is, why use C++ for
> > > small ( > 1000 lines ) coding jobs?
> > > It doesn't make much sense to me as...
> > > C++ syntax requires a lot more typing, debugging and memory,
> > > Compilation time can be irksome,
> > > C++ is devoid of the plethora of features you find on Python, Ruby or
> > > our dear Swiss Army Chainsaw.
> >
> > Since I just recently wrote a small tool in C++ (around 300 lines of
> > code) that simply transforms one text-like file to another file, I'll
> > try to explain why I did this in C++:
> >  - I know C++ well enough and appreciate the higher level
> > abstractions.
> >    They make this sort of thing fairly easy to write. I don't think a
> >    Python solution to this problem is significantly smaller in terms
> > of source code size.
>
> I've yet to see anything that wouldn't be shorter in Python than
> in C++.

me too.


> More significantly, it's generally easier to develop
> iteratively in an interpreted language, simply because the
> turn-around time is much, much shorter.

I know this is like a cliche in software development; but is it
*actually* true. A 300 line program is going to take no time at all to
compile and running a Python interpreter up doesn't take no time at
all. Yes Basic beat COBOL hands down but I no longer have to be nice
to the key punch girls to get faster turn-around!

I've used Python and I lie it but I'm not convinced that interpreters
are that much quicker to develop with no matter how often they tell me
so. And C++ comes with a debugger...


> And the "bad"
> techniques, like just typing in code without having done any
> design, don't really make such a difference in very small
> programs.

I still sort of desing I just don't write it down.

> Historically, I've used AWK for anything up to about
> 500 lines; I've recently shifted to Python (mainly because
> Python will be installed on all development machines, where as
> there are only three or four of us who have AWK on our Windows
> machines).
>
> >  - I don't know any scripting language well enough to do the job,
> >    although I was planning to get more accustomed to Python
> > eventually.
> >  - I like static typing. I don't like assigning random sh*t to other
> >    random sh*t and hoping that it all works out at runtime.
>
> It's not a question of "liking": static typing saves you from
> all kinds of problems once the program gets a bit bigger.

not entirely convinced. I suppose with dynamic typing you have to make
sure all the code has executed so thre isn't some time bomb hiding in
your code. But your C++ code should have pretty thourogh test coverage
anyway.


> >  - C++ doesn't require you to install a VM or interpreter.
>
> But it does require you to install a compiler on the machine you
> develope on:-).  (Until about two years ago, I worked
> exclusively in Unix environments.  A shell was always present,
> with awk, sed, and the like.  Which meant that scripts could be
> used portably, without installing anything special.)

[toc] | [prev] | [next] | [standalone]

#9248

Op 23-Aug-11 10:47, Nick Keighley schreef:
> On Aug 22, 12:44 am, James Kanze<james.ka...@gmail.com>  wrote:
>> On Aug 12, 10:11 am, SG<s.gesem...@gmail.com>  wrote:
>>> On 6 Aug., 23:00, Miro wrote:
>
>
>>>> I've made the title too provocative. What I mean is, why use C++ for
>>>> small (>  1000 lines ) coding jobs?
>>>> It doesn't make much sense to me as...
>>>> C++ syntax requires a lot more typing, debugging and memory,
>>>> Compilation time can be irksome,
>>>> C++ is devoid of the plethora of features you find on Python, Ruby or
>>>> our dear Swiss Army Chainsaw.
>>>
>>> Since I just recently wrote a small tool in C++ (around 300 lines of
>>> code) that simply transforms one text-like file to another file, I'll
>>> try to explain why I did this in C++:
>>>   - I know C++ well enough and appreciate the higher level
>>> abstractions.
>>>     They make this sort of thing fairly easy to write. I don't think a
>>>     Python solution to this problem is significantly smaller in terms
>>> of source code size.
>>
>> I've yet to see anything that wouldn't be shorter in Python than
>> in C++.
>
> me too.
>
>
>>   More significantly, it's generally easier to develop
>> iteratively in an interpreted language, simply because the
>> turn-around time is much, much shorter.
>
> I know this is like a cliche in software development; but is it
> *actually* true. A 300 line program is going to take no time at all to
> compile and running a Python interpreter up doesn't take no time at
> all. Yes Basic beat COBOL hands down but I no longer have to be nice
> to the key punch girls to get faster turn-around!
>
> I've used Python and I lie it but I'm not convinced that interpreters
> are that much quicker to develop with no matter how often they tell me
> so.

My experience is that for little quick-and-dirty applications (for my 
own use) Python is definitely quicker, even though I'm much more fluent 
in C++ than Python. It is not only the language but also the quite 
extensive library that comes with Python that makes me more productive.

> And C++ comes with a debugger...

As does Python. In fact one can argue whether C++ 'comes' with a 
debugger. There is nothing in the standard that mandates that.

>>   And the "bad"
>> techniques, like just typing in code without having done any
>> design, don't really make such a difference in very small
>> programs.
>
> I still sort of desing I just don't write it down.
>
>>   Historically, I've used AWK for anything up to about
>> 500 lines; I've recently shifted to Python (mainly because
>> Python will be installed on all development machines, where as
>> there are only three or four of us who have AWK on our Windows
>> machines).
>>
>>>   - I don't know any scripting language well enough to do the job,
>>>     although I was planning to get more accustomed to Python
>>> eventually.
>>>   - I like static typing. I don't like assigning random sh*t to other
>>>     random sh*t and hoping that it all works out at runtime.
>>
>> It's not a question of "liking": static typing saves you from
>> all kinds of problems once the program gets a bit bigger.
>
> not entirely convinced. I suppose with dynamic typing you have to make
> sure all the code has executed so thre isn't some time bomb hiding in
> your code. But your C++ code should have pretty thourogh test coverage
> anyway.

Especially with dynamically typed languages it is not just about code 
coverage, but about covering every possible execution flow which is much 
harder to achieve. Simply having all lines of a function executed once 
means just about nothing in a dynamically type language, you must have 
executed all lines of the function with every combination of types of 
variables the function might use to catch errors that a C++ compiler 
would have caught during compile time.

>>>   - C++ doesn't require you to install a VM or interpreter.
>>
>> But it does require you to install a compiler on the machine you
>> develope on:-).

The fact that with Python users must install Python first is a reason 
for me not to use Python. The other one is that it is dynamically typed, 
which is a good thing if you just want to throw things together quickly, 
but a bad thing if you want things to be reliable. Once a Python script 
gets beyond a couple of hundreds of lines, the lack of static typing 
starts to bite.

[toc] | [prev] | [next] | [standalone]

#9588

On Aug 23, 7:01 pm, Dombo <do...@disposable.invalid> wrote:
> Op 23-Aug-11 10:47, Nick Keighley schreef:
> > On Aug 22, 12:44 am, James Kanze<james.ka...@gmail.com>  wrote:
> >> On Aug 12, 10:11 am, SG<s.gesem...@gmail.com>  wrote:
> >>> On 6 Aug., 23:00, Miro wrote:

<snip>

> >>   More significantly, it's generally easier to develop
> >> iteratively in an interpreted language, simply because the
> >> turn-around time is much, much shorter.
>
> > I know this is like a cliche in software development; but is it
> > *actually* true. A 300 line program is going to take no time at all to
> > compile and running a Python interpreter up doesn't take no time at
> > all. Yes Basic beat COBOL hands down but I no longer have to be nice
> > to the key punch girls to get faster turn-around!
>
> > I've used Python and I [like] it but I'm not convinced that interpreters
> > are that much quicker to develop with no matter how often they tell me
> > so.
>
> My experience is that for little quick-and-dirty applications (for my
> own use) Python is definitely quicker, even though I'm much more fluent
> in C++ than Python. It is not only the language but also the quite
> extensive library that comes with Python that makes me more productive.

did you read what I wrote? I don't doubt python is quicker for many
q&d applications, particularly because of its extensive library. /But/
I'm not convinced that the INTERPRETATION makes the difference. I was
commenting on this "...it's generally easier to develop iteratively in
an interpreted language, simply because the turn-around time is much,
much shorter". Because I think this is accepted uncritically.

<snip>

[for using C++ over python]
> >>>   - I don't know any scripting language well enough to do the job,
> >>>     although I was planning to get more accustomed to Python
> >>> eventually.
> >>>   - I like static typing. I don't like assigning random sh*t to other
> >>>     random sh*t and hoping that it all works out at runtime.
>
> >> It's not a question of "liking": static typing saves you from
> >> all kinds of problems once the program gets a bit bigger.

another myth that's repeated more often than it's evidenced.


> > not entirely convinced. I suppose with dynamic typing you have to make
> > sure all the code has executed so thre isn't some time bomb hiding in
> > your code. But your C++ code should have pretty thourogh test coverage
> > anyway.
>
> Especially with dynamically typed languages it is not just about code
> coverage, but about covering every possible execution flow which is much
> harder to achieve. Simply having all lines of a function executed once
> means just about nothing in a dynamically type language, you must have
> executed all lines of the function with every combination of types of
> variables the function might use to catch errors that a C++ compiler
> would have caught during compile time.

the Static Dynamic Wars make the War of The Ring look like tiddly
winks match.


> >>>   - C++ doesn't require you to install a VM or interpreter.
>
> >> But it does require you to install a compiler on the machine you
> >> develope on:-).
>
> The fact that with Python users must install Python first is a reason
> for me not to use Python. The other one is that it is dynamically typed,
> which is a good thing if you just want to throw things together quickly,
> but a bad thing if you want things to be reliable. Once a Python script
> gets beyond a couple of hundreds of lines, the lack of static typing
> starts to bite.

INYHO

[toc] | [prev] | [next] | [standalone]

#9343

On Aug 23, 9:47 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On Aug 22, 12:44 am, James Kanze <james.ka...@gmail.com> wrote:

    [...]
> > And the "bad"
> > techniques, like just typing in code without having done any
> > design, don't really make such a difference in very small
> > programs.

> I still sort of desing I just don't write it down.

You don't "know" something until you've written it down.  It's
too easy to cut corners otherwise.

    [...]
> > It's not a question of "liking": static typing saves you from
> > all kinds of problems once the program gets a bit bigger.

> not entirely convinced. I suppose with dynamic typing you have to make
> sure all the code has executed so thre isn't some time bomb hiding in
> your code. But your C++ code should have pretty thourogh test coverage
> anyway.

Static typing results in a compile time error on the exact line
where the error occurs.  Dynamic typing requires running the
program.  On large programs, that takes more time, and the
resulting error message is generally less precise (although I'll
admit that Python can give fairly good error messages in this
case).  There's an old saying that every step you go through
until the error appears multiplies the cost by 10; an error
caught by the compiler is 10 times cheaper to fix than one
caught in unit tests (or 100, if you count linking as a separate
step).  The factor has obviously been pulled out of thin air,
but there is something to the general principle: an error found
by the compiler is cheaper to fix than one found in code review,
or one found in unit tests.

Note that on very large projects, a type error in the interface
between subsystems may not show up until integration, and
resolving errors which first appear in integration can be very
expensive.

Most of my experience has been on large projects, in large
teams, and on systems which were more or less critical.  All of
which argues in favor of very strict static typing.  (IMHO, C++
isn't strict enough.)  On the other hand, in all of these
projects, there's been a lot of support code---code and
documentation generators, verification programs, test suite
generators, etc.---and these have largely been written in the
Bourne shell, with intensive use of AWK.

--
James Kanze

[toc] | [prev] | [next] | [standalone]

#9593

On Aug 26, 4:25 pm, James Kanze <james.ka...@gmail.com> wrote:
> On Aug 23, 9:47 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
> wrote:
> > On Aug 22, 12:44 am, James Kanze <james.ka...@gmail.com> wrote:

> > > And the "bad"
> > > techniques, like just typing in code without having done any
> > > design, don't really make such a difference in very small
> > > programs.
>
> > I still sort of [design] I just don't write it down.
>
> You don't "know" something until you've written it down.  It's
> too easy to cut corners otherwise.

The Source Code IS The Design!

http://www.developerdotstar.com/mag/articles/reeves_design.html

I was really talking about 300 line filters. I do think about their
structure but I don't draw a UML diagram or anything.

<snip>

[toc] | [prev] | [next] | [standalone]

#9627

On Sep 1, 10:43 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On Aug 26, 4:25 pm, James Kanze <james.ka...@gmail.com> wrote:

> > On Aug 23, 9:47 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
> > wrote:
> > > On Aug 22, 12:44 am, James Kanze <james.ka...@gmail.com> wrote:
> > > > And the "bad"
> > > > techniques, like just typing in code without having done any
> > > > design, don't really make such a difference in very small
> > > > programs.

> > > I still sort of [design] I just don't write it down.

> > You don't "know" something until you've written it down.  It's
> > too easy to cut corners otherwise.

> The Source Code IS The Design!

The source code is an implementation of a design (or of a lack
of design).

> http://www.developerdotstar.com/mag/articles/reeves_design.html

> I was really talking about 300 line filters. I do think about their
> structure but I don't draw a UML diagram or anything.

A design doesn't have to be a UML diagram.  Depending on the
program's complexity, it might not be much more than a man page,
stating exactly what the program is going to do.

--
James Kanze

[toc] | [prev] | [next] | [standalone]

#8768

On 7 elo, 00:00, Miro <nickbergeronsem...@gmail.com> wrote:
> I understand that it compiles directly into binary and can be from
> there run without an interpreter, but that seems a small price

It's a big issue to me. Python is especially notorious for not
being backwards compatible so you need the specific version
installed to run a program. In the end you have loads of
python versions which take huge amount of disk space.

If there is a better language that compiles stand alone
programs and has better (easier) access to hardware like
file handling then please let me know.

[toc] | [prev] | [next] | [standalone]

#9222

On Aug 13, 9:09 am, Krice <pau...@mbnet.fi> wrote:
> On 7 elo, 00:00, Miro <nickbergeronsem...@gmail.com> wrote:
>
> > I understand that it compiles directly into binary and can be from
> > there run without an interpreter, but that seems a small price
>
> It's a big issue to me. Python is especially notorious for not
> being backwards compatible so you need the specific version
> installed to run a program. In the end you have loads of
> python versions which take huge amount of disk space.
>
> If there is a better language that compiles stand alone
> programs and has better (easier) access to hardware like
> file handling then please let me know.

Chicken Scheme   :-)
(not a serious suggestion but it /does/ have both a compiler and an
interpreter and there are libraries to handle directories)

[toc] | [prev] | [next] | [standalone]

#9228

On 13 août, 10:09, Krice <pau...@mbnet.fi> wrote:
> On 7 elo, 00:00, Miro <nickbergeronsem...@gmail.com> wrote:
>
> > I understand that it compiles directly into binary and can be from
> > there run without an interpreter, but that seems a small price
>
> It's a big issue to me. Python is especially notorious for not
> being backwards compatible

Is it ? Except from the leap between 2.x to 3.x, I have not noticed
much compatibility issues provided you have the last version.

> so you need the specific version
> installed to run a program.

I think SG refers to py2exe which produces executable files (for MS)
that do not require python to be installed. I have made a few and,
although it produces BIG exe, it works quite well.

> In the end you have loads of
> python versions which take huge amount of disk space.


> If there is a better language that compiles stand alone
> programs and has better (easier) access to hardware like
> file handling then please let me know.

The D programming language has a decent standard library regarding
this.
http://www.d-programming-language.org/phobos/std_file.html

--
Michael

[toc] | [prev] | [next] | [standalone]

#9365

On Aug 6, 2:00 pm, Miro <nickbergeronsem...@gmail.com> wrote:

> Don't get me wrong, I don't dislike C++, nor am I trying to rile up
> the great gurus among us, however, I fail to see a practical reason to
> use this language much as I go about my hacking life.

Hackers should stay away from C++.  They'll just hurt themselves.  Let
the developers, engineers, and other adults do the C++.  Stick to Perl
or something where what you're making isn't expected to be readable by
anyone anyway, including yourself in 3 days.

[toc] | [prev] | [next] | [standalone]

#9397

Dnia 27-08-2011 o 21:38:55 Noah Roberts <roberts.noah@gmail.com>  
napisał(a):

> On Aug 6, 2:00 pm, Miro <nickbergeronsem...@gmail.com> wrote:
>
>> Don't get me wrong, I don't dislike C++, nor am I trying to rile up
>> the great gurus among us, however, I fail to see a practical reason to
>> use this language much as I go about my hacking life.
>
> Hackers should stay away from C++.  They'll just hurt themselves.  Let
> the developers, engineers, and other adults do the C++.  Stick to Perl
> or something where what you're making isn't expected to be readable by
> anyone anyway, including yourself in 3 days.

For hackers is pure assembler ;-)

Anyway: c is structural, c++ is object oriented. You choose want you want.  
C is not worse than c++. In c you can do as much as in c++. It is only  
different way of thinking and programming. C - callbacks, C++  
constructor/destructors ;-)

Assembler is procedural ;-) (but some compilers f.e. nasm supports  
structures)

[toc] | [prev] | [next] | [standalone]

#9432

On Aug 28, 1:37 pm, "Duga Chernobyl" <duga...@gmx.com> wrote:
> Dnia 27-08-2011 o 21:38:55 Noah Roberts <roberts.n...@gmail.com>
> napisał(a):

    [...]
> Anyway: c is structural,

C is procedural (according to the usual definition).

> c++ is object oriented.

C++ is a multipardigm language.  It, too, is basically
procedural, but it has additional features to support OO or
generic programming.

Both C and C++ do allow a limited amount of functional
programming (e.g. using ?: and recursion), but extended
functional programming seems unnatural in either.

> You choose want you want.
> C is not worse than c++. In c you can do as much as in c++. It is only
> different way of thinking and programming. C - callbacks, C++
> constructor/destructors ;-)

The most important difference remains the existance of
public/private in C++.  As a C programmer, you define a struct,
and a number of functions which manipulate the struct, and you
cross your fingers that no one accesses the members of the
struct other than through your functions.  In C++, the compiler
enforces this---you don't have to cross your fingers.

--
James Kanze

[toc] | [prev] | [next] | [standalone]

#9453

On Aug 29, 4:11 am, James Kanze <james.ka...@gmail.com> wrote:

> The most important difference remains the existance of
> public/private in C++.  As a C programmer, you define a struct,
> and a number of functions which manipulate the struct, and you
> cross your fingers that no one accesses the members of the
> struct other than through your functions.  In C++, the compiler
> enforces this---you don't have to cross your fingers.

Actually, encapsulation is one of the easiest C++ features to
implement in C.  You just declare a typedef to a non-defined struct,
which only has full definition inside of the c file that implements
its behavior.  IE:

header.h:

typedef struct my_object MyObject;

MyObject* createMyObject();
void freeMyObject(MyObject* obj);

etc...

cfile.c

struct my_object
{
  private members...
};

... etc...

One can declare another struct of the same general shape and get
access to its insides, but you can do that to C++ too.

[toc] | [prev] | [next] | [standalone]

#9462

Noah Roberts <roberts.noah@gmail.com> wrote:
> Actually, encapsulation is one of the easiest C++ features to
> implement in C.  You just declare a typedef to a non-defined struct,
> which only has full definition inside of the c file that implements
> its behavior.

  At the cost of increased memory usage and decreased performance.
(Allocating objects individually on the heap is significantly heavier
than allocating them on the stack. This heavyness is "inherited" by
any other type or data container that wants to use it.)

  I always find it amusing when (some) C hackers believe the urban
legend that C++ is slower than C, yet time and again they demonstrate
how C results in the more inefficient code for the same functionality.

[toc] | [prev] | [next] | [standalone]

#9591

On Aug 28, 1:37 pm, "Duga Chernobyl" <duga...@gmx.com> wrote:
> Dnia 27-08-2011 o 21:38:55 Noah Roberts <roberts.n...@gmail.com>  
> napisał(a):
>
> > On Aug 6, 2:00 pm, Miro <nickbergeronsem...@gmail.com> wrote:
>
> >> Don't get me wrong, I don't dislike C++, nor am I trying to rile up
> >> the great gurus among us, however, I fail to see a practical reason to
> >> use this language much as I go about my hacking life.
>
> > Hackers should stay away from C++.  They'll just hurt themselves.  Let
> > the developers, engineers, and other adults do the C++.  Stick to Perl
> > or something where what you're making isn't expected to be readable by
> > anyone anyway, including yourself in 3 days.
>
> For hackers is pure assembler ;-)
>
> Anyway: c is structural, c++ is object oriented. You choose want you want.  
> C is not worse than c++. In c you can do as much as in c++.

this is trivially true for any Turing Complete langauge. Since I can
write a C++ compiler in C any C++ can be written in C. So what?


> It is only  
> different way of thinking and programming. C - callbacks, C++  
> constructor/destructors ;-)
>
> Assembler is procedural ;-) (but some compilers f.e. nasm supports  
> structures)

[toc] | [prev] | [next] | [standalone]

#9419

On 2011-08-27 15:38:55 -0400, Noah Roberts said:

> Hackers should stay away from C++.  They'll just hurt themselves.  Let
> the developers, engineers, and other adults do the C++.  Stick to Perl
> or something where what you're making isn't expected to be readable by
> anyone anyway, including yourself in 3 days.

Funny you should mention Perl.  I don't consider myself a hacker, but I 
do some Perl programming once in a while.  What I noticed is that 
programming in Perl allows me to express algorithms in a most pure and 
simple manner.  You would think that a language like C++ would be best 
for that kind of job.  But it turns out a good high-level scripting 
language with excelent support for basic data structures is better.  I 
know other people had the same kind of experience with Python (and 
Lisp).  Now, C++ could be a good programming language for expressing 
algorithms too.  You just need to stop thinking about C++ as low level 
language.  With the right libraries providing high level abstractions, 
programming in C++ can be bliss.  But usually people don't realize it 
until they encounter a programming language that comes with high level 
abstractions out of the box.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web