C++ and the future of C 
Author Message
 C++ and the future of C



Quote:
>I have also learned C++, but I have not as yet had
>either the need or the opportunity to write any non-trivial programs with
>it. I didn't dislike it as much as I thought I would

That's an odd attitude. Why did you think you'd dislike it?

Quote:
>(I still insist that OOP and C++ in particular are not ideal
>tools for _all_ problems

Why would you have to insist on this? Have you ever heard anyone say that
OOP and C++ are "ideal tools for all problems"?

Quote:
>and that C++ creates almost as much new potential
>for error as it eliminates

It does sound like you think using C++ would give you a net gain in this
area, though. :)

Quote:
>My concern is that the market for C programmers seems to be shrinking,
>thanks in part to C++.

I think that there are a lot of programmers who still program in C, even
though they use a C++ compiler to do that with. My advice would be to move
to a C++ compiler yourself, and add in the C++ features that you want and/or
need.


Thu, 29 Jun 2000 03:00:00 GMT  
 C++ and the future of C

I'm going to post this question here rather than in comp.lang.c++ because I
already know the answer I'll get on any C vs. C++ question over _there_.

I've been a C programmer for five years now, and although software
development has never been my primary responsibility, I've written a lot of
mission-critical code, and I've gotten to feel pretty confident about my
programming skills. I have also learned C++, but I have not as yet had
either the need or the opportunity to write any non-trivial programs with
it. I didn't dislike it as much as I thought I would, and in fact, I think
it's a pretty interesting language and a good tool for solving certain kinds
of problems. (I still insist that OOP and C++ in particular are not ideal
tools for _all_ problems, and that C++ creates almost as much new potential
for error as it eliminates.) Nevertheless, I greatly enjoy programming in C,
and new opportunities are arising for me in my job to do more coding than
before.

My concern is that the market for C programmers seems to be shrinking,
thanks in part to C++. My question is, firstly, if this is actually the
case, and secondly, in what areas or niches is C likely to persist in the
longest. The company I work for is a small media firm, and therefore has
about the same projected lifespan as a restaurant, so I need to be planning
my next career move before it is abruptly thrust upon me.

Crow



Fri, 30 Jun 2000 03:00:00 GMT  
 C++ and the future of C

Quote:

> >My concern is that the market for C programmers seems to be shrinking,
> >thanks in part to C++.

> I think that there are a lot of programmers who still program in C, even
> though they use a C++ compiler to do that with. My advice would be to move
> to a C++ compiler yourself, and add in the C++ features that you want and/or
> need.

There is still a market for C programmers.  While many companies are
shifting to C++, there are a good many still using C.  For the most
part, that's due to a lack of C++ knowledge among their employees.  Most
of the strongest C++ programmers, at least in my area, are consultants.
The company wants applications that they can maintain themselves, which
will be C applications if too few of their employees are C++ ignorant.

BTW, the same argument is frequently used about JAVA, that Java is
shrinking the C++ market.  I'm a consultant who specifializes in C++.  I
haven't seen it.  There has been an increase of jobs using Java, but the
C++ work is still there.

Ace



Fri, 30 Jun 2000 03:00:00 GMT  
 C++ and the future of C



Quote:
>>I have also learned C++, but I have not as yet had
>>either the need or the opportunity to write any non-trivial programs with
>>it. I didn't dislike it as much as I thought I would

>That's an odd attitude. Why did you think you'd dislike it?

Chiefly because its syntax is messy. One of the things I like best
about C is how clean and consistent its syntax is. Perhaps because of
Stroustrup's goal of keeping C compatible with C++, the syntax of C++
is anything but clean and consistent; it is a Frankenstein monster
consisting of C's body with some other language's head crudely bolted
onto it.

That, and since C++ is the language of the day, it has more than its
fair share of language bigots. Just an instinctive reaction, I guess.
I did try to keep an open mind about it, though, and I *do* like some
parts of the language.

Quote:
>>(I still insist that OOP and C++ in particular are not ideal
>>tools for _all_ problems

>Why would you have to insist on this? Have you ever heard anyone say that
>OOP and C++ are "ideal tools for all problems"?

Non-OO programming tends to get pretty vociferously deprecated in OOP
textbooks. I have yet to see one that lists any situations where OOP
would be a sub-optimal solution. On Bjarne Stroustrup's website, in
response to the suggestion that C might be better than C++ for small
projects, he says, "I never saw a project for which C was better than
C++ for any reason but the lack of a good C++ compiler. "

Quote:
>>and that C++ creates almost as much new potential
>>for error as it eliminates

>It does sound like you think using C++ would give you a net gain in this
>area, though. :)

To be sure. I've been working on a Perl-like function library written
in C for a while now, and I'm beginning a port to C++ because I simply
can't provide the user with Perl's ease of use without resorting to
custom data types. What I do like about C++, its fundamentally crusty
syntax aside, is that it is syntactically cleaner to have a data
structure encapsulated in an object than it is to deal with pointers
to structs. And, since I like to fiddle with underlying data
structures until I achieve the greatest speed/size efficiency that I
can, being able to hide implementation details from the user is a
boon.

I just have to wonder if all the time saved by type safety and
encapsulation/inheritance/polymorphism isn't largely offset by the
time spent designing and managing complex object hierachies. My
compiler IDE doesn't provide me with a graphical chart of calling
dependencies for my C functions, but it *does* provide graphical
charts for my object hierarchies in C++ mode.

Crow



Fri, 30 Jun 2000 03:00:00 GMT  
 C++ and the future of C


Quote:

>I just have to wonder if all the time saved by type safety and
>encapsulation/inheritance/polymorphism isn't largely offset by the
>time spent designing and managing complex object hierachies. My

The time is traded off somewhat evenly, no doubt, if you only consider the
original developer's time. But if you consider the time spent maintaining the
stuff for years afterward, the picture may be different.

Complex object hierarchies often arise during maintenance of the software.
It's not like you sit down to do an object oriented design and purposely
design a complex inheritance hierarchy upfront! :)

Object-oriented programs can start out as simple, small systems that work
and iteratively evolve into large systems that don't work. Or
something like that. I'm obviously not good at absorbing hype.



Fri, 30 Jun 2000 03:00:00 GMT  
 C++ and the future of C

Quote:

>Chiefly because [C++'s] syntax is messy.

Could you give an example (preferably with a suggested improvement)?

Quote:
>On Bjarne Stroustrup's website, in
>response to the suggestion that C might be better than C++ for small
>projects, he says, "I never saw a project for which C was better than
>C++ for any reason but the lack of a good C++ compiler. "

I tend to agree with him, actually, although I'd add that C is a better
choice if you (and/or your colleagues) don't know C++. :)

Quote:
>What I do like about C++, its fundamentally crusty
>syntax aside, is that it is syntactically cleaner to have a data
>structure encapsulated in an object than it is to deal with pointers
>to structs

I would say it's semantically cleaner, as well.

. And, since I like to fiddle with underlying data

Quote:
>structures until I achieve the greatest speed/size efficiency that I
>can, being able to hide implementation details from the user is a
>boon.

This really is a good feature of OOP, I agree. Somewhat along the same
lines, I like encapsulation because it lets me write _bad_ code. If it turns
out to be too slow later, I can fix it up without bothering the rest of the
program. If not, I've saved myself the trouble of optimizing where it wasn't
necessary.

Quote:
>I just have to wonder if all the time saved by type safety and
>encapsulation/inheritance/polymorphism isn't largely offset by the
>time spent designing and managing complex object hierachies. My
>compiler IDE doesn't provide me with a graphical chart of calling
>dependencies for my C functions, but it *does* provide graphical
>charts for my object hierarchies in C++ mode.

I think both are quite useful.


Fri, 30 Jun 2000 03:00:00 GMT  
 C++ and the future of C

 I put this in the wrong thread.  It is a response to the top of the thread.
I was about to compose almost the exact same question.
My concern though is that eventually all of the thrust towards C++ will
eventually actually lead somewhere that I have to be
(programmatically) and then I will be forced to catch up.
Right now C++ is definitely not a + for me.  (A limit of 2 arrogant and 1 {*filter*}
attacking answer is allotted to this post) Thank
you.



Fri, 30 Jun 2000 03:00:00 GMT  
 C++ and the future of C

Quote:

> I'm going to post this question here rather than in comp.lang.c++ because I
> already know the answer I'll get on any C vs. C++ question over _there_.

Aw, John, they're no so bad "over there." <g>

Quote:
> I've been a C programmer for five years now, and although software
> development has never been my primary responsibility, I've written a lot of
> mission-critical code, and I've gotten to feel pretty confident about my
> programming skills. I have also learned C++, but I have not as yet had
> either the need or the opportunity to write any non-trivial programs with
> it. I didn't dislike it as much as I thought I would, and in fact, I think
> it's a pretty interesting language and a good tool for solving certain kinds
> of problems. (I still insist that OOP and C++ in particular are not ideal
> tools for _all_ problems, and that C++ creates almost as much new potential
> for error as it eliminates.) Nevertheless, I greatly enjoy programming in C,
> and new opportunities are arising for me in my job to do more coding than
> before.

Once again, I'll open myself up for criticism, since I'm currently in academia.
Inherently, I don't necessarily see anything "better" in C++ vs. C. A
well-structured, well-abstracted program design in C will accomplish as much as
a similar program in C++. (In fact, I think it would "look" much the same.)

From an organizational point of view, it might be better to create a common
library of C++ objects, but then a similar library could be created in C with
abstract datatypes and functions.

Inheritance is where an object oriented language gains an advantage... IMHO its
much easier to extend the capabilities of an object (building upon its existing
properties and methods) than it is to extend a "C-type" ADT.

Quote:
> My concern is that the market for C programmers seems to be shrinking,
> thanks in part to C++. My question is, firstly, if this is actually the
> case, and secondly, in what areas or niches is C likely to persist in the
> longest. The company I work for is a small media firm, and therefore has
> about the same projected lifespan as a restaurant, so I need to be planning
> my next career move before it is abruptly thrust upon me.

I'll get flamed for career advice in a language standards newgroups, but here
goes... (I'm stating this from the traditonal academic position of immunity: I
have tenure, I can teach Word and Excel till I retire <g>).

If you want to cover all bets, become at least minimally proficient in C, C++,
and Java. Many employers don't really know the difference, especially between C
and C++. They think if their programmers are using Visual C++ they must be
programming in C++. In fact, they're using a couple of C++ capabilities, such as
cin and cout, but really just using C++ as a "better" C.

I have no real idea just what a media firm would use C for, etc.,  so I have no
idea whether C or the other languages will continue to be strong in them. I
suspect that "straight C" will always be strong in things like real time
controllers for specific platforms, where portability isn't an issue.

Set-top boxes from the cable company look like they're going Java, although
whether it's "Pure Java" or MS Jscript looks to to be 50-50 bet at this point.
(Years ago, there was a saying you'll never get fired for buying Big Blue...
today, you could say the same about Microsoft.)

Now, here's where I really put on my "advisor's" hat... If you can at all avoid
it, never do something that you don't enjoy doing. (It took me 20 years to learn
this lesson <g>) If you really like C, and don't like C++, work yourself into a
field where C is still the standard. But realize that that decision may require
relocation, shifting of industries, or in the type of programming you do. And,
depending upon how old you are, you might eventually have to "adapt" to the OOP
paradigm anyway.

At one time, programmers started with machine or assembly languages, and then
advanced to higher level languages (Cobol, Fortan, Algol). Today, we're using
Visual Basic or C as "first level" programming languages, and I imagine within
five years that something like C++ or Java will be the entry level programming
languages. Which presents you with the dilemma of "catching the wave" of next
generation languages, or being known as the last remaining C guru.

Dave

--
David R. Ballentine, Assistant Professor, Computer Technology
Westmoreland County Community College, Youngwood PA USA 15697

http://www.westol.com/~ballendr
Remove XXX from Reply-to address



Fri, 30 Jun 2000 03:00:00 GMT  
 C++ and the future of C

Quote:

> Once again, I'll open myself up for criticism, since I'm currently in academia.
> Inherently, I don't necessarily see anything "better" in C++ vs. C. A
> well-structured, well-abstracted program design in C will accomplish as much as
> a similar program in C++. (In fact, I think it would "look" much the same.)

> From an organizational point of view, it might be better to create a common
> library of C++ objects, but then a similar library could be created in C with
> abstract datatypes and functions.

> Inheritance is where an object oriented language gains an advantage... IMHO its
> much easier to extend the capabilities of an object (building upon its existing
> properties and methods) than it is to extend a "C-type" ADT.

To me it seems that C++ adds libraries that one MUST study extensively and carefully
in order to use them.  And extremely carefully in order to extend their
capabilities. I often don't have them time to do this for the programs I must
write.  It also means getting involved in someone else's style of programming to the
extreme.  Styles of programming seem almost like politics to me and I often "hate"
certain styles.
As far as actually inventing classes, I would be out of business if I spent months
inventing classes for my customers.  They want results.
C++ has to grow up much more.  Never mind Java which as of now does nothing for my
kind of real programming.


Fri, 30 Jun 2000 03:00:00 GMT  
 C++ and the future of C

Quote:

>To me it seems that C++ adds libraries that one MUST study extensively and
carefully
>in order to use them.  And extremely carefully in order to extend their
>capabilities. I often don't have them time to do this for the programs I
must
>write.

That's the great thing that holds back code reuse: attitudes such as yours
that it takes more time to understand someone else's code than it does to
write something from scratch. I think that in the real world, it's just as
important to be able to work with other people's code (which is indeed
difficult sometimes) as it is to write good code of one's own.

You say you don't have time to understand other people's code. I say you
don't have time _not_ to, unless you plan to reinvent every wheel that was
ever conceived.

Quote:
> It also means getting involved in someone else's style of programming to
the
>extreme.  Styles of programming seem almost like politics to me and I often
"hate"
>certain styles.

Get over it. Programming shouldn't be that emotional.

Quote:
>As far as actually inventing classes, I would be out of business if I spent
months
>inventing classes for my customers.  They want results.

Why in the world do you think OOP advocates write classes? Just to give
themselves something to do when there's nothing on TV? Clue: it's so they
can write (and debug) something once and be able to reuse it later without
problems. Reuse == faster results.

Quote:
>C++ has to grow up much more.

Are you saying you don't think its implementation of OOP is mature? What
would you change?

Quote:
>Never mind Java which as of now does nothing for my kind of real

programming.

Yeah, that automatic garbage collection stuff is a real waste of time, isn't
it? And who needs threads in the _real_ world? :)



Fri, 30 Jun 2000 03:00:00 GMT  
 C++ and the future of C

Quote:

> At one time, programmers started with machine or assembly languages, and then
> advanced to higher level languages (Cobol, Fortan, Algol). Today, we're using
> Visual Basic or C as "first level" programming languages, and I imagine within
> five years that something like C++ or Java will be the entry level programming
> languages. Which presents you with the dilemma of "catching the wave" of next
> generation languages, or being known as the last remaining C guru.

> Dave

At which point programmers who still know assembler/Forth/C/etc. will be
in great
demand for whatever that era has as an equivalent to ignition modules,
calculators, tool controllers, etc. :-).
--
Larry Blanchard - Old roses, old motorcycles, and old trains

I have found that all ugly things are made by those who strive to make
something beautiful and that all beautiful things are made by those who
strive to make something useful.    Oscar Wilde



Fri, 30 Jun 2000 03:00:00 GMT  
 C++ and the future of C

Hmm...
I assume then that the work you do does not involve creating a data
structure and then functions whch operate on them? Your apps do not have any
type of structs or functions which operate on those structs?

If this isn't correct (and I really think I'm wrong in the above
assumption ) then these structures could becomes classes very easily.

Does something like the SL take time to learn and understand? Yes. The
payoff is quite nice though, since you don't have to duplicate the work.

It doesn't have to take any more time to design a library of structs and
functions which work with those structs than it would for a class library.

Dennis

Quote:

>> Once again, I'll open myself up for criticism, since I'm currently in
academia.
>> Inherently, I don't necessarily see anything "better" in C++ vs. C. A
>> well-structured, well-abstracted program design in C will accomplish as
much as
>> a similar program in C++. (In fact, I think it would "look" much the
same.)

>> From an organizational point of view, it might be better to create a
common
>> library of C++ objects, but then a similar library could be created in C
with
>> abstract datatypes and functions.

Some nice thing about C++ is the ability to
a) mark a class' data as private, to prevent inadvertent changes and
b) overloaded operators.

The overloaded operators are prticularly useful for math libraries and such,
as they will retain the conventional precedence ordering. If there are just
functions which implement the operations, they'll be called at the
"function-call" precedence. Just my two cents.

- Show quoted text -

Quote:

>> Inheritance is where an object oriented language gains an advantage...
IMHO its
>> much easier to extend the capabilities of an object (building upon its
existing
>> properties and methods) than it is to extend a "C-type" ADT.

>To me it seems that C++ adds libraries that one MUST study extensively and
carefully
>in order to use them.  And extremely carefully in order to extend their
>capabilities. I often don't have them time to do this for the programs I
must
>write.  It also means getting involved in someone else's style of
programming to the
>extreme.  Styles of programming seem almost like politics to me and I often
"hate"
>certain styles.
>As far as actually inventing classes, I would be out of business if I spent
months
>inventing classes for my customers.  They want results.
>C++ has to grow up much more.  Never mind Java which as of now does nothing
for my
>kind of real programming.



Fri, 30 Jun 2000 03:00:00 GMT  
 C++ and the future of C

Quote:


> > Which presents you with the dilemma of "catching the wave" of next
> > generation languages, or being known as the last remaining C guru.

> At which point programmers who still know assembler/Forth/C/etc. will be
> in great
> demand for whatever that era has as an equivalent to ignition modules,
> calculators, tool controllers, etc. :-).

Not to mention maintenance and extension of all the "legacy" systems
being written now.  Why do you think fortran and COBOL programmers are
still around?  One of the jobs I interviewed for when I graduated last
year was for an insurance company that was in the process of
moving their system over from assembly to COBOL.  (The recruiter was
quite proud of it, in fact. 8)
--

------------------------------------------------------------------------------
"Running Windows on a Pentium is like having a brand new Porsche but only
  [being] able to drive backwards with the handbrake on." (unknown)


Fri, 30 Jun 2000 03:00:00 GMT  
 C++ and the future of C

Quote:

> That's the great thing that holds back code reuse: attitudes such as yours
> that it takes more time to understand someone else's code than it does to
> write something from scratch. I think that in the real world, it's just as
> important to be able to work with other people's code (which is indeed
> difficult sometimes) as it is to write good code of one's own.

> You say you don't have time to understand other people's code. I say you
> don't have time _not_ to, unless you plan to reinvent every wheel that was
> ever conceived.

But you have passed over my point in jumping to make yours.  Of course I respect
all that other code, but I find that almost all of the programming work I do
requires unique solutions to problems and these are very rarely found in the C++
code that exists.  Sure linked lists and many other things, but those libraries
already existed in C.  Are you saying that all of the C code that came before
C++ was poorly written code.  I don't think so.

Quote:
> > It also means getting involved in someone else's style of programming to
> the
> >extreme.  Styles of programming seem almost like politics to me and I often
> "hate"
> >certain styles.

> Get over it. Programming shouldn't be that emotional.

Programming is not math.  There is no final absolute way to do it.  There are
styles and they make a difference.  As I'm sure you in another context would be
the first to admit.

Quote:

> >As far as actually inventing classes, I would be out of business if I spent
> months
> >inventing classes for my customers.  They want results.

> Why in the world do you think OOP advocates write classes? Just to give
> themselves something to do when there's nothing on TV? Clue: it's so they
> can write (and debug) something once and be able to reuse it later without
> problems. Reuse == faster results.

They can advocate whatever they like.  I just don't see them deriving classes
every time a customer wants some unique program or prototype.

Quote:

> >C++ has to grow up much more.

> Are you saying you don't think its implementation of OOP is mature? What
> would you change?

I have never seen as much teeth gnashing (except over pointers but not as
intense) as among C++ programmers trying to figure out how to handle C++.  I
realize there are good programmers who can use C++ well and I am sure I could be
one of them, but the language is extremely convoluted.  It is turning itself
inside out and I think that is because it is trying to do things that C was
deliberately set up not to do although that is a very general statement and I
certainly wouldn't get into defending it specifically.

Quote:

> >Never mind Java which as of now does nothing for my kind of real
> programming.

> Yeah, that automatic garbage collection stuff is a real waste of time, isn't
> it? And who needs threads in the _real_ world? :)

That's great stuff.  But where am I going to run it.  Do you program for a
living?When Java runs almost as good and as fast as a bad Windows program that
would be a start.  Secondly, I wish as much as anyone that Java was anything
like a cross-platform solution.  It's not yet.  I hope it becomes one.


Fri, 30 Jun 2000 03:00:00 GMT  
 C++ and the future of C

Quote:

> Hmm...
> I assume then that the work you do does not involve creating a data
> structure and then functions whch operate on them? Your apps do not have any
> type of structs or functions which operate on those structs?

> If this isn't correct (and I really think I'm wrong in the above
> assumption ) then these structures could becomes classes very easily.

> Does something like the SL take time to learn and understand? Yes. The
> payoff is quite nice though, since you don't have to duplicate the work.

> It doesn't have to take any more time to design a library of structs and
> functions which work with those structs than it would for a class library.

> Dennis

> C++ as I see it would help a C programmer write programs that in many ways
> would be better.  But if one writes C programs carefully, as one must to get
> decent results, then using a class instead of a struct  is not really much
> different.  After all moving the functions into the class definition, making
> data private etc, are actually things that are done implicity by all C
> programs.  They are just not abstracted in the way C++ is.

In other words if I as a C programmer, know that my data is should be accessed
only in certain ways (C++ partially protects me from accessing it ), I know that
certain functions act on certain data (C++ mostly forces it to only act on
certain data).

I still remember when C programmers laughed when Basic programs added to strings
together with a + sign.  Now its sacred, but I do fine with strcat.



Fri, 30 Jun 2000 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Newbie: separate big .cs file into small .cs files

2. Need C++ text for non cs major course

3. Future of C++ and Windows Programming :: C++

4. FUTURE SOFTWARE FUTURES

5. How to show/call Form2.cs from Form1.cs ?

6. Include code in other Cs files

7. Reuse of cs files, namespace, arch advice pls

8. word - automatic numbering/bold/underline/italics

9. How to Generate .cs file at Runtime

10. newbe/cs student, need help w/ code

11. Serial.cs

12. Compile CS source code using ICodeCompiler

 

 
Powered by phpBB® Forum Software