should i learn c?

[eminhanif]

hi
i've been thinking about learning c but was wondering if its worth it
as theres tonnes of c code out there(not to mention linux).

is it particularly hard if you already know c++?

 

[coal]

hi
i've been thinking about learning c but was wondering if its worth it
as theres tonnes of c code out there(not to mention linux).

is it particularly hard if you already know c++?

I wouldn't put too much effort into learning the parts of
C that are unique to it and not shared with C++. My guess is
Linux will either be rewritten in C++ or displaced by a new
operating system written in C++.

Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

"Then Samuel took a rock and set it up between Mizpah and Shen.
He named it Ebenezer [Rock of Help] and said, 'Until now the
L-RD has helped us.'"

 

[Rui Maciel]

I wouldn't put too much effort into learning the parts of
C that are unique to it and not shared with C++. My guess is
Linux will either be rewritten in C++ or displaced by a new
operating system written in C++.

It's the first time I ever heard such a thing. Could you please back up that statement?


Rui Maciel

 

[Rui Maciel]

i've been thinking about learning c but was wondering if its worth it
as theres tonnes of c code out there(not to mention linux).

is it particularly hard if you already know c++?

I don't believe it's that hard. It demands a different mental disposition but other than that it's not difficult to pick up. And of course,
don't expect to use some C++ language constructs and it's libraries.


Rui Maciel

 

[SG]

It's the first time I ever heard such a thing. Could you please back
up that statement?

Did you miss the "My guess is" qualifier?

Regarding "parts of C that are unique to it and not shared with C++":
this is not much in terms of language featues since C++ inherits
nearly every "feature" from C. Assuming Brian was talking about the
coding style I would say learning the "C coding style" isn't a bad
idea. If anything it makes you appreciate C++ a little more. ;-)

Cheers!
SG

 

[coal]

There's too much code to be written and maintained in a C-only project
like Linux. Lots of people think you have a better chance of
building
quality software with C++ than just C. I guess Linus T. and others
would disagree. Anyway, though, how many universities are teaching
C-only these days?

Did you miss the "My guess is" qualifier?

Regarding "parts of C that are unique to it and not shared with C++":
this is not much in terms of language featues since C++ inherits
nearly every "feature" from C.  Assuming Brian was talking about the
coding style I would say learning the "C coding style" isn't a bad
idea.  If anything it makes you appreciate C++ a little more. ;-)

I replaced a variable length array a few months ago that was lurking
in a C++ program. I think g++ supports VLAs as an extension so
almost
didn't notice it.

Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[Andrew Koenig]

is it particularly hard if you already know c++?

It's like making a scupture of an elephant: You start with a block of marble
and chip away everything that doesn't look like an elephant.

Similarly, if you know C++, you can program in C by writing in C++ but
avoiding any of the parts of C++ that aren't also part of C.

 

[eminhanif]

It's like making a scupture of an elephant: You start with a block of marble

is that hard or easy?
c has got a lot of weird lingo hasn't it,like
the void for parameterless functions?

 

[Bo Persson]

is that hard or easy?
c has got a lot of weird lingo hasn't it,like
the void for parameterless functions?

It is hard!

To program in C, you do it just like you would in C++, except you
cannot use containers or strings, or I/O streams, exceptions,
templates, or the standard algorithms. No classes of course, so no
member functions, constructors, or destructors. Oh, and no overloaded
functions or operators. Did I mention namespaces?

Other than that, it is just about the same. Except that some things
are different, like functions with no parameters.


Bo Persson

 

[Pascal J. Bourguignon]

"Then Samuel took a rock and set it up between Mizpah and Shen.
He named it Ebenezer [Rock of Help] and said, 'Until now the
L-RD has helped us.'"

That is a very bad guess.

What do you mean?

 

[Alf P. Steinbach]

* Pascal J. Bourguignon:

"Then Samuel took a rock and set it up between Mizpah and Shen.
He named it Ebenezer [Rock of Help] and said, 'Until now the
L-RD has helped us.'"

That is a very bad guess.

What do you mean?

He probably referred to the part you /didn't/ quote.

Cheers & hth.,

- Alf

 

[Cari Elf]

hi
i've been thinking about learning c but was wondering if its worth it
as theres tonnes of c code out there(not to mention linux).

is it particularly hard if you already know c++?

In my opinion it's worth it. There are a lot of useful functions in
the C runtime library that you might not otherwise be exposed to if
you've only used C++ and the STL, particularly dealing with string
handling. I've even used C functions to make equivalents for
std::string (I love sprintf). It's also useful if you're trying to
keep overhead to a minimum.

As far as if it's particularly hard, once you've learned one language,
it's much easier to learn another. Just try not to think about it as C
++, and maybe get an actual C compiler like one of the old (free)
Borland compilers so that you won't be able to mix and match.

 

[anon]

In my opinion it's worth it. There are a lot of useful functions in
the C runtime library that you might not otherwise be exposed to if
you've only used C++ and the STL, particularly dealing with string
handling. I've even used C functions to make equivalents for
std::string (I love sprintf). It's also useful if you're trying to
keep overhead to a minimum.

As far as if it's particularly hard, once you've learned one language,
it's much easier to learn another. Just try not to think about it as C
++, and maybe get an actual C compiler like one of the old (free)
Borland compilers so that you won't be able to mix and match.

Is this a joke or a troll?

 

[Pascal J. Bourguignon]

* Pascal J. Bourguignon:

On 2009-03-07 19:31:43 -0700, (e-mail address removed) said:

"Then Samuel took a rock and set it up between Mizpah and Shen.
He named it Ebenezer [Rock of Help] and said, 'Until now the
L-RD has helped us.'"
That is a very bad guess.

What do you mean?

He probably referred to the part you /didn't/ quote.

Which is exactly my point.

 

[Lionel B]

sprintf is in the C++ standard library, as well. In fact, almost the
entire C standard library is included in standard C++.

FWIW, there was also an interesting thread in this ng some months ago
(can't seem to find it at the mo) on using snprintf to format directly
into the (c-)string buffer of a std::string.

Note: snprintf, not sprintf - the latter is a buffer overflow waiting to
happen...

 

[Jorgen Grahn]

In my opinion it's worth it.

[snip praise for the C subset of the C++ standard library]

As far as if it's particularly hard, once you've learned one language,
it's much easier to learn another. Just try not to think about it as C++,
and maybe get an actual C compiler like one of the old (free)
Borland compilers so that you won't be able to mix and match.

Never use a C-and-C++ compiler where you cannot tell it which language
to compile, and/or disable extensions. You shouldn't have to use
obsolete compilers to avoid C++.

In fact, if I were to learn C today, I'd go for C99. Having to
declare all variables at the top of the block is (for some reason) the
main thing that drives me nuts when I have to maintain C89 code. The
'inline' keyword is also nice when you worry about efficiency.

Of course, C99 is still rare and you come across pre-ANSI C code
fairly often ...

/Jorgen

 

[coal]

Sun's guidelines for Java suggest that you declare the variables at the
top of the block, even though the language doesn't require it.  Java
also doesn't support inline.  It helps me to think of "setting up stack
frames," rather than "declaring variables," even when I realize that the
function I'm writing will probably be inlined automatically, and
therefore not require its own stack frame at all.

I agree with your implied point that one probably shouldn't be defining
variables before one is ready to initialize them.  However, if you find
yourself declaring variables in the middle of a block, it may be
worthwhile to factor that portion of the block into a separate function,
anyway.

I don't often like what I find out about Java, but that guideline is
not
too bad in my opinion. I find it useful to be able to define
variables
before initializing them in marshalling code that is computer-
generated.

For this input:

msg_manager
(short, bool, bool)
}

I get this output:

// Generated by the C++ Middleware Writer version 1.8

#include <Buffer.hh>

struct msg_manager
{
inline
msg_manager() {}
inline
~msg_manager() {}

inline
void
Send(Buffer* buf, const short abt1, const bool abt2, const bool abt3)
{
unsigned char boolRep;
buf->Receive(&abt1, sizeof(short));

boolRep = abt2;
buf->Receive(&boolRep, sizeof(boolRep));

boolRep = abt3;
buf->Receive(&boolRep, sizeof(boolRep));

buf->SendStoredData();
}

inline
void
Receive(Buffer* buf, short& abt1, bool& abt2, bool& abt3)
{
unsigned char boolRep;
buf->PersistentRead(&abt1, sizeof(short));

buf->PersistentRead(&boolRep, sizeof(boolRep));
(boolRep != 0) ? abt2 = true : abt2 = false;

buf->PersistentRead(&boolRep, sizeof(boolRep));
(boolRep != 0) ? abt3 = true : abt3 = false;

}

};


I find it preferable to keep track of whether any bools are involved
and
only define boolRep if needed. The alternative would be to have
multiple
boolRep variables defined -- boolRep1 and boolRep2. One reason to
favor
the above approach is the amount of stack space needed is not
dependent
on how many bools are used. We do something similar for strings with
a
variable that holds string lengths.

I should add that the output above is not currently available on line.
The on line version is 1.7 and this newer version that supports both
exceptions and return codes will hopefully be available on the site
before the end of the month.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[coal]

I don't often like what I find out about Java, but that guideline is
not
too bad in my opinion.  I find it useful to be able to define
variables
before initializing them in marshalling code that is computer-
generated.

For this input:

msg_manager
    (short, bool, bool)

}

I get this output:

// Generated by the C++ Middleware Writer version 1.8

#include <Buffer.hh>

struct msg_manager
{
inline
msg_manager() {}
inline
~msg_manager() {}



inline
void
Receive(Buffer* buf, short& abt1, bool& abt2, bool& abt3)
{
  unsigned char boolRep;
  buf->PersistentRead(&abt1, sizeof(short));

  buf->PersistentRead(&boolRep, sizeof(boolRep));
  (boolRep != 0) ? abt2 = true : abt2 = false;

  buf->PersistentRead(&boolRep, sizeof(boolRep));
  (boolRep != 0) ? abt3 = true : abt3 = false;

}
};

I find it preferable to keep track of whether any bools are involved
and
only define boolRep if needed.  The alternative would be to have
multiple
boolRep variables defined -- boolRep1 and boolRep2.  One reason to
favor
the above approach is the amount of stack space needed is not
dependent
on how many bools are used.  We do something similar for strings with
a
variable that holds string lengths.

Alternatively, I could do something like this hand-written and
untested code:

inline
void
boolSend(Buffer* buf, bool const bl)
{
unsigned char boolRep = bl;
buf->Receive(&boolRep, sizeof(boolRep));
}

and

inline
void
Send(Buffer* buf, const short abt1, const bool abt2, const bool abt3)
{
unsigned char boolRep;
buf->Receive(&abt1, sizeof(short));

boolSend(buf, abt2);

boolSend(buf, abt3);

buf->SendStoredData();
}


We could do it that way if that would be improve matters.


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[SG]

Sun's guidelines for Java suggest that you declare the variables at the
top of the block, even though the language doesn't require it.

What seems like a good idea in Java (though I don't agree with the
guideline) might not work in C++ as well. In Java the compiler warns
about uninitialized object references. So, there's little difference
in terms of safety between declaring object references early /
initializing them later and declaring and initializing them together
as late as possible. In C++, however, if you declare some object
variable with automatic storage it is constructed right away. As far
as the C++ compiler is concerned such objects (excluding built-in
types) are initialized already and there's no need to warn about any
kind of usage because the C++ compiler can't tell whether a default
constructed object is "logically initialized" (as it might not be the
case in two stage initializations, see std::ifstream, default-
constructor + ifstream:pen).

So, what I'm saying is that this guideline is a Java guideline that
doesn't transfer well to C++.

Cheers!
SG

 

[Alf P. Steinbach]

* Jeff Schwab:
Sorry for butting in, but this is the second article from you in just a few
minutes (it feels like, but I've had coffee in between!) that apparently hinges
on a terminological misunderstanding.

Namely, you assume that a word can only mean one thing, and you choose some
single meaning that /does not make sense/ in the context the other guy is using
it, that is, you choose some unnatural meaning, like thinking the final g in the
word "thinking" must be referring to the gravitational constant, then protesting
that "thinkin" is spelled incorrectly and anyway what's that to do with gravity?

Instead, consider choosing the/a meaning that does make sense in any particular
context. In fact, even the C++ standard library uses such a meaning of the word
'initialize', a meaning that would make sense in the article you responded to.
No matter that I think that particular place in the standard library is hairy
and smelly, but except for argumentation it's just ungood to out of several
available meanings pick the one that makes the least sense in context.


Cheers & hth.,

- Alf