• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Quick C question

S

Stupendous

[H]ard|Gawd
Joined
Aug 29, 2000
Messages
1,370
I can't remember if C would zero and NULL this memory for me. See the code excerpt for details and question

Code: 
typedef struct list_type
{
  node_ptr head;
  node_ptr tail;
  uint     size;
} list, *list_ptr;

int main(void)
{
  list l;

  // will l.head and l.tail == NULL and will l.size always be 0?
  // or do I need to do the following
  l.head = NULL;
  l.tail = NULL;
  l.size = 0;
}
 
Local variables and members of local variables are not zero-initialized or NULL-initialized.

C sucks. Use C++. Constructors own the hizouse.
 
Originally posted by STL
Local variables and members of local variables are not zero-initialized or NULL-initialized.

C sucks. Use C++. Constructors own the hizouse.
Click to expand...

For my OS course. Despite the fact that C++ is used in OS development we are stuck with C. Plus they just now added a C++ course but it's only 1 credit and its experimental so that says a lot about what my CS dept. thinks about C++ =\
 
:-<

You can say:

list l = { NULL, NULL, 0 };

if memory serves correctly. That makes it more dependent on the structure of the list class, though.
 
It's been a long time since I had to use straight C but from what I remember this will vary with the compiler.

I do remember specifically some of the compilers I used set all unitialized pointers to non NULL values.

To make a long story short you should manually initialize all the values in your nodes when you make them.

And I think it would also be considered justifiable homicide for killing whoever in your CS department said that C++ was expiramental. :D
 
And I think it would also be considered justifiable homicide for killing whoever in your CS department said that C++ was expiramental
Click to expand...

I don't think he was saying that his CS department said that C++ was experimental, but the class was. Our CSCI department has been mulling over the decision from switching from a C++ learning environment to a Java environment for teaching the basics of programming. Luckily, I won't have to go through that.
 
Originally posted by Daemon1313
And I think it would also be considered justifiable homicide for killing whoever in your CS department said that C++ was expiramental. :D
Click to expand...

Probably in the context of the CMPT curriculum. To have an accredited Computer Science program, there are a large number of criteria that must be satisfied. Once an established curriculum is in place and approved, it can take a long time to get it changed.

A large part of Computer Science has nothing to do with what language you are using, but rather the principles behind them. Once you understand all of these concepts, learning a language should not be difficult.
 
[Daemon1313]
> I do remember specifically some of the compilers I used set all
> unitialized pointers to non NULL values.

Don't depend on that.

> To make a long story short you should manually initialize all the
> values in your nodes when you make them.

Yes.

[Cverick]
> Our CSCI department has been mulling over the decision from
> switching from a C++ learning environment to a Java environment for
> teaching the basics of programming.

Mlar.
 
I agree that a large part of computer science is language independant, but it is a little difficult to educate students in modern OOA/OOD principles when all the classes are still based in C.

It is just annoys me how badly behind some computer science departments get.
 
Modern? Ha. Object oriented programming is from the 1980s.

Genericity is modern; it's a 1990s/2000s thing.

Of course, most programmers aren't even competent at data abstraction, and that's a 1970s thing.
 
Originally posted by STL
[Daemon1313]
> I do remember specifically some of the compilers I used set all
> unitialized pointers to non NULL values.

Don't depend on that.

> To make a long story short you should manually initialize all the
> values in your nodes when you make them.

Yes.
Click to expand...

That's one of the things that messes you up unless you're consciously aware of it. For my one course, I used gcc for all of the assignments, then took the code to school and recompiled in visual studio. Things that would work at home wouldn't work at school. Until I realized what was going on, I was completely confused. Turns out gcc does initialize everything for you, and VS.net doesn't.

Always, always, always initialize anything. Make no assumptions about what values they have initially.
 
> Turns out gcc does initialize everything for you, and VS.net
> doesn't.

Not in my experience (there's a reason the uninitialized rule exists: it's for performance).

I just watched a gcc-compiled program being debugged today, and it definitely didn't zero out variables.

Of course, it may be version/proc/optimization dependent.
 
Originally posted by STL
Local variables and members of local variables are not zero-initialized or NULL-initialized.
Click to expand...

This varies with compiler. My Borland C compiler will zero and null local variables, my special embedded PowerPC compiler from Green Hills Software will zero and null local variables, but my GNU compiler will not.

I believe the ANSI standard allows for them to be zeroed, but doesn't require it. However, to maintain the best code portability, it is good practice to always initialize variables.

C sucks. Use C++. Constructors own the hizouse.
Click to expand...
Meh... I always grate my teeth when you go off spouting this stuff. It depends on what you're doing that makes a certain language more applicable to a certain situation. The company I work for (a very succesful company, mind you) uses C for everything.

Why?

These are all embedded systems. The extra overhead of C++ over C is one less detail we'd rather not deal with. Our firmware is already within bytes of the limit of our processors memory, so any efficiency for space we can gain is very important. C++ just doesn't produce as efficient of compiled code for similar tasks and all the extra stuff C++ gives you over C is absolutely not necessary.

So, C does not suck for what we use it for, embedded system firmware and verification and validation software.
 
[UICompE02]
> This varies with compiler.

When I say, "Not X", I usually mean, "The Standard does not guarantee X".

> I believe the ANSI standard allows for them to be zeroed, but
> doesn't require it.

Correct.

> Meh... I always grate my teeth when you go off spouting this stuff.

I'm sorry that you're annoyed by the truth.

No I'm not.

> It depends on what you're doing that makes a certain language more
> applicable to a certain situation.

C++ supersedes C in almost all situations (low-level ones being the major exception).

> The company I work for (a very succesful company, mind you) uses C
> for everything.

And GCC and the Linux kernel are written in C. Halo too.

> These are all embedded systems.

Well, there you go.

For application programming, C++ destroys C.
 
Originally posted by STL
I just watched a gcc-compiled program being debugged today, and it definitely didn't zero out variables.

Of course, it may be version/proc/optimization dependent.
Click to expand...


That would have been with no optimization :).
 
as far as I'm concerned.. If you don't need anything from C++ for your app, why add it? Running a low level program where every bit of memory counts... use C and assembler.. writign a large app, use c++. The way I treat it is if a problem is complicated enough that I start thinking about objects, I'll use them.. If its just a quickie app, I'll use C. Of course this is coming from someone who has to program BASIC on a d3 database and then have it talk through xml to a c# webpage :( oh my pain... my pain.. my pain :) I'm starting to think that as punishment for people in prison, we should make them write algorithms for extremely large and complicated xml files in BASIC. If I have to feel the pain... so should they :)
 
[schapman]
> as far as I'm concerned.. If you don't need anything from C++ for
> your app, why add it? Running a low level program where every bit
> of memory counts... use C and assembler..

C++ can be just as efficient as C, modulo some small things.

And if you really need to, you can code core inner loops in assembler and write some small C translation units. C++ and C link together real nicely.

> if a problem is complicated enough that I start thinking about
> objects, I'll use them.. If its just a quickie app, I'll use C.

When I think about, oh, opening files, or concatenating strings, the thought of using C fills me with horror.

I wrote a quickie regex renamer in C++ using Boost Regex. It owns. I have no clue why a regex renamer isn't already a GNU utility.
 
for the c to c++ comparison for efficiency, I was talking more about OO ovehead (function tables and the like), but I do realize that well written c++ code can be as efficient (and in some ways more efficient) than C
 
Originally posted by STL
[schapman]C++ can be just as efficient as C, modulo some small things.

And if you really need to, you can code core inner loops in assembler and write some small C translation units. C++ and C link together real nicely.
Click to expand...

Most of the performance comparisons I've seen fo C, C++, Java(yea, yea, mlar... :) ), and other languages have concentrated on execution speed. Any idea, other than what the VM adds in bytecode languages, how the memory efficiency of common languages/programming paradigms match up?

I'd guess that well structured C code and assembler would probably show a larger advantage there than in execution speed over OO C++ code, but it's still not nearly enough to discard C++ because of that.
 
> I'd guess that well structured C code and assembler would probably
> show a larger advantage there than in execution speed over OO C++
> code, but it's still not nearly enough to discard C++ because of
> that.

C++ is basically as efficient as C, and sometimes significantly moreso, thanks to functor inlining. Space efficiency is essentially the same.
 
Originally posted by STL
C++ is basically as efficient as C, and sometimes significantly moreso, thanks to functor inlining. Space efficiency is essentially the same.
Click to expand...

Aren't space efficiency and and inlining mutually exclusive? If I'm not mistaken, inlining puts the function right in place, instead of having a JMP to the other function... Right?
 
I think one of the areas where c++ can be much more efficient is in program design. poorly designed programs will run slow, and c++ provides many design bonuses that can help design large scale programs to run faster.
 
[fat-tony]
> Aren't space efficiency and and inlining mutually exclusive?

Nope. Consider what happens when the inlined function is smaller than the code needed to call the function.

Inlining can increase or decrease code size, can increase or decrease instruction cache pressure, can increase or decrease locality, and can increase or decrease performance. You don't know without profiling.

C++ also rocks because of header-only libraries. C89, what with its lack of the "inline" keyword, can't do this.
 
Originally posted by schapman
I think one of the areas where c++ can be much more efficient is in program design. poorly designed programs will run slow, and c++ provides many design bonuses that can help design large scale programs to run faster.
Click to expand...

Unfortunately, those features are also abused all to hell when people don't bother to learn how to use them appropriately. This is true of nearly any language, of course.
 
You must log in or register to reply here.
Back
Top