That's the funniest post today

Well, member functions are really not a whole lot different from functions you call with a pointer to a C struct instead. in fact, the difference is a single parameter. The fun comes from inheritence and overloaded operators/functions and templates and friends and such. Nothing you can't technically do in C, but C++ makes some things easier, like writing one template function rather than a function for every type you plan on passing it. You can do OOP in C, but C++ makes it easier IMHO.

Member functions get to operate in their own littke world where the class's member variables are treated like they're global. That's really the only difference.

Bob:

"That's on page 61, section 6.3.2.2 of the ANSI/ISO/IEC 9899 standard."

That is the C99 standard, no? I thought it was fairly obvious I was talking about C++.

So I'm right to use NULL (why NULL? Why not null?) and not 0, correct?

By value, and the entire object will be dumped on the stack AFAIK. Did you not know or are you testing me?

I take it you didn't read the GameDev thread I linked to

Yes, as stated quite explicitly in the aforementioned thread, the standard guarantees that the NULL macro will always evaluate to 0. But 0 is the null pointer constant. The null pointer constant can't be changed. NULL is just a macro. Remember, this is what I was originally replying to:

"isnt it a bad thing to make pointers equal to 0 instead of NULL in the case that in the future NULL is changed from 0 to something else?"

I was jokingly (notice the smiley?) pointing out that this logic is backwards.

Now as for why I think NULL is actually unsafe ... well, I am inherently wary of all macros. Also, if you use NULL, you better make sure that you include one of the aforementioned headers, and I have seen code where that was not the case (thus making the code non-standard).

Anyway, I have to go finish my Engr 240 technical report now ...

That's called bad coding.. not C

other than int main(), can't think of one..

I thought a vector was an STL class?
Perhaps I'm confused then..... but, when I was in my attempts to complete chris' article, a vector had so many different uses and functions (within it's class, right?).. it was insane. The only reason why that is "confusing" to me, is because I want to know what the heck they all do..

Chris, you shouldn't be intimidated by Sven (especially since I despise him).

Both

Fred* p = new Fred();

as well as

Fred* p = new Fred;

are equivalent (in this case).
The thing one SHOULD worry about is the difference between:

Fred p();

and

Fred p;

Ouch!

Here's one for the Book O' Flame Quotes:
Using C instead of C++ is like using K&R C instead of ANSI C.

Not true. In C, 0 can always be implicitly cast to a null pointer of any type. Even on systems where the bit pattern of a null pointer is not all zeros, the C compiler will convert the integer constant 0 into the correct null pointer.

What you have to be careful of is optional arguments. If you need to pass a null pointer as an optional argument, you MUST cast it appropriately:

void myfunc(int x, ...);

myfunc(x, (int *)0);

This problem applies equally to functions declared implicitly, but in very nearly all cases you shouldn't have to do this. I can only think of one case where you'd have to use implicit declarations, illustrated by the following quote from DJGPP's stdlib.h file:

/* These vary in expected prototype, so we just don't prototype them.
void            xfree(void *_ptr);
void *          xmalloc(size_t _size);
void *          xrealloc(void *ptr, size_t _size);
*/

It should be noted that these functions are not standard.

Under ANSI C, NULL is defined as one of the following:

#define NULL 0
#define NULL ((void *)0)

The latter will help protect you if you accidentally use NULL where an integer constant was wanted, e.g. as a NUL terminator (yes, one L!) on the end of a string. However it will not get around the optional arguments problem; you must cast.

This is covered in detail in the C FAQ. I can't comment on C++.

---

Quote:
-----------------------------------------

FOO *bar = malloc(sizeof(*FOO));
bar = realloc(bar,sizeof(*FOO) * 2);

-----------------------------------------

Wrong! First it should be sizeof(FOO) or sizeof(*bar), but that aside...

If realloc() cannot find enough memory for the new array, it will return NULL, without freeing the memory you've got already. Assign the same pointer like this and you've got a memory leak! The following would be correct code:

FOO *bar = malloc(sizeof(FOO));
FOO *baz = realloc(bar,sizeof(FOO) * 2);
if (!baz) {
    free(bar);
    return NULL;
}
bar = baz;

Rash despises Sven? Now that I didn't know. I thought crazy_k and I were the only victims.

Nah. Why do you think it's more advanced?
As bob said, it simply gives you syntactical sugar. There's no real improvement from c to c++.

The language itself hasn't changed much, so there can't be much of an improvemement. In fact, many of the gnu extensions to C are IMO more helpful than the c++ fluff.

And, regarding OO: If you think OO, and make a nice OOD the actual coding can be made in either c or c++.

Come on, guys, all these "linked list" threads here should be enough to convert even the most extremist C zealot.

P.S. I don't despise you two, Ben.

I hate to point something out here, but the logical argument of "realloc == vector" is false.

Let's say I load a 2MB file from disk. I take the data, and compress/alter it into a 500K block. Note that the data is not structured into an array format. It is structured data, but no C/C++ object can be wrapped around its entirty. Therefore, it cannot be a vector<char>.

Had I allocated this block of memory with "new char[size]", I would have to create a 500K block, copy the converted data into it, and delete the old one. I have now moved this memory to new addresses, and I therefore must go through my pointers into various pieces of this data and adjust them to compensate.

On the other hand, if I used "malloc", I could "realloc" that memory down, with full knowledge that it will not change the pointer itself.

The only trouble I have with things like this is that "new" and "malloc" are not interchangable. I have to somehow remember that some memory was allocated with "malloc" and some was allocated with "new". It's easy when it's just objects or arrays of objects. But, if it is just a buffer, it becomes more difficult. Therefore, I have implemented the convention that all "buffers" are allocated with "malloc", and everything else with "new".

As for the C/C++ debate yet again, I find it strange that seasoned programmers like Bob simply refuse to use C++ for no logical reason. Calling it "syntactic sugar" is simply infantile. OOP in C is error-prone, and there is no language facility you can use to prevent that. Instead, it all relies on faith. Faith that all the v-tables are initialized properly. Faith that everybody calls the initializer (over all elements of the array) when they create an object (or that they create all objects of that type through one function). Faith that the user will always destroy an object via a certain function or call a certain destructor beforehand.

I don't need faith when I use C++. I know the v-tables are all fine. Otherwise, I'd have gotten a compile error (unless the compiler is broken, in which case I'm SOL anyway). As long as I use the C++ new/delete to allocate/deallocate object, constructors and destructors will be called automatically. They'll even be called before the program begins for global objects.

Oh, I can trick C++. I can start casting things from one object to another and break it. But that's cheating and isn't expected to work anyway. The C version of OOP has no language support; it relies totally on programmers to follow a particular convention. In this maner, C++ is idiot-proof.

Not only that, if I use C++ dynamic casts to do all of that casting, the RTTI would have returned NULL instead of a valid pointer, thus causing a quick and obvious error. Your method has no such failsafes.

Languages are just tools for programmers. The only reason a programmer should select one over another is because it better fits the design for the program in question. Generally, from a well-thought out design, it is easy to see what features you need out of a language to efficiently implement the design.

For example, if I wanted to make a cross-platform networked version of Tetris, C/C++ with Allegro and a networking library isn't the most optimal solution. I'd use Java. That is the most reasonable language for that project. Here's why:

1) Java's cross-platform. Sure, so are C/C++, but each platform needs to recompile the sources. Java doesn't have these limitations.
2) Speed isn't much of an issue. It's Tetris, after all. It's not that taxing, so the speed advantages of C/C++ aren't relevant.
3) Networking is a breeze in Java. C/C++ doesn't provide easy cross-platform networking support. Certainly not the way Java does.

Therefore, if you're serious about implementing a cross-platform, networked version of Tetris, then Java is the language of choice. You, of course, may implement it in something else, but this is a far less reasonable thing to do. By not using Java, you are intensionally using a weaker tool to solve this problem.

The same goes for any design like that. By forcing OOP into a language (like C) that doesn't have intrinsic support for it (which it doesn't. You have to build it off of existing functionality), you are choosing to use a tool that is less efficient (at OOP) than a language that does intrinsically support OOP.

It's like using an electric screwdriver to beat a nail into wood. Yeah, you can do it. But you'd be better off with a simple hammer than using an electric screwdriver. You'll never see any real carpenter using a screwdriver to drive a nail, because he knows to use the right tool for the right job.

It's about time programmers learned this simple lesson.

a tear comes to my eye every time i look at the thread count and see a large number for a thread i started,.. but anyway, this was originally about malloc and new and whatnot and not about c++ vs C. i think everyone is a little tired of arguing, so either post in a new thread or give it a rest. no one is going to hate you for using C or C++.

I never said that C is incapable of OOP. I said that C doesn't support OOP.

Specifically, I mean that the C language does not provide intrinsic support for OOP. It doesn't not provide intrinsic support for objects that self-initialize/deinitialize. It doesn't provide intrinsic support for inheiritance or polymorphism either.

Once again, that's not to say that these things can't be done in C. It merely says that, in order to do them, you must create these facilities. Take Allegro, for example.

If you create a BITMAP * using what ANSI C says is a good way to create one (ie, (BITMAP *)malloc(sizeof(BITMAP));), then, under Allegro, you mave made a mistake. Under Allegro, there are specific functions for creating BITMAPs. And only those functions may be used to create valid BITMAP*'s that can be passed to other Allegro functions.

According to ANSI C, there is nothing wrong with malloc'ing that BITMAP object. That is a perfectly legitimate creation of a BITMAP, and functions that expect a BITMAP* are guarenteed (when they are allocated that way) that the pointer points to an area of memory that is both valid (though not symantically valid) and is large enough to hold a BITMAP.

It just so happens that, symantically, according to Allegro, this is a bad idea. Allegro expects certain things (like the v-table pointer) to be filled in. It may even expect the actual bitmap bits to follow (in memory) the BITMAP data structure. ANSI C does not guarentee any of these things. These can only be guarenteed by user code. Therefore, OOP is supported, not by ANSI C, but only by the program-defined conventions of the use of objects.

By contrast, C++ supports OOP in the language. Let's take the above example, but assuming BITMAP were a proper C++ class object. Under ANSI C++, the correct way to allocate this object is with "new BITMAP;". The blank constructor, assuming a robust implementation, would function like "create_bitmap" with some meaningful, though utterly arbituary, values. Therefore, what you get is a meaningful BITMAP object.

This object is ready to be used by any BITMAP function (most of which are members of the BITMAP, following standard OOP via C++). In fact, the only way to create a BITMAP object that is invalid is to violate ANSI C++. You can "malloc" one, but ANSI C++ specifically warns that this will not create a properly initialized object.

By using the facilities of the C++ language, you can guarentee (as long as the user follows ANSI C++) that the user cannot break certain things. The user cannot create invalid objects. If you're using public/private correctly, he can't directly damage the data. In short, you can make it really difficult for someone to break your underlying code as long as they stick to ANSI C++.

I really hate C++ exceptions. They really should be optional. You mean I have to go through my entire codebase and replace "new" with "new(nothrow)"? I guess that's what #defines are for