Asked  7 Months ago    Answers:  5   Viewed   36 times

What is better: void foo() or void foo(void)? With void it looks ugly and inconsistent, but I've been told that it is good. Is this true?

Edit: I know some old compilers do weird things, but if I'm using just GCC, is void foo() Ok? Will foo(bar); then be accepted?


void foo(void);

That is the correct way to say "no parameters" in C, and it also works in C++.


void foo();

Means different things in C and C++! In C it means "could take any number of parameters of unknown types", and in C++ it means the same as foo(void).

Variable argument list functions are inherently un-typesafe and should be avoided where possible.

Tuesday, June 1, 2021
answered 7 Months ago

In C, pointer conversions to and from void* were always implicit.

In C++, conversions from T* to void* are implicit, but void* to anything else requires a cast.

Wednesday, June 9, 2021
answered 6 Months ago

Yes, as far as i know the second declaration is invalid in C++ and C89, but it is valid in C99.

From The C99 draft, TC2 (

The special case of an unnamed parameter of type void as the only item in the list speci?es that the function has no parameters.

It's explicitly talking about the type "void", not the keyword.

From The C++ Standard, 8.3.5/2:

If the parameter-declaration-clause is empty, the function takes no arguments. The parameter list (void) is equivalent to the empty parameter list.

That it means the actual keyword with "void", and not the general type "void" can also be seen from one of the cases where template argument deduction fails (14.8.2/2):

  • Attempting to create a function type in which a parameter has a type of void.

It's put clear by others, notable in one core language issue report here and some GCC bugreports linked to by other answers.

To recap, your GCC is right but earlier GCC versions were wrong. Thus that code might have been successfully compiled with it earlier. You should fix your code, so that it uses "void" for both functions, then it will compile also with other compilers (comeau also rejects the second declaration with that "VOID").

Friday, June 25, 2021
answered 6 Months ago

----EDIT 2 -----

Given that you're trying to make an editor like the one you showed, I'd recommend going WPF even more. My current project has many features along those lines, as well, and we've decided that the ability to composite WPF with Direct3D content is extremely powerful. It's nice to be able to render your scene into anything - not just a rectangular window. In WinForms, you pretty much were limited to one rectangle, and you had issues with airspace there, too (subtle, but things like flickering issues when menus pull over your hwnd, etc). The WPF compositor with D3DImage gets rid of all of those issues, and lets you use your imagination to construct a very flexible UI. Things like rendering your scene in realtime on the side of a WPF3D object are possible, or using WPF controls directly on top of your d3d scene instead of trying to do the GUI in D3D, etc.


If you're going to be hosting DX, you might want to consider it - especially since it gives you the ability to do scene composition with your UI and no airspace issues if you use D3DImage.

This does work with SlimDX and WPF.


For more information on the disadvantages of using Direct3D with Winforms, and the advantages of WPF/DX integration, see:

MSDN Article on Airspace

Codeproject arcticle on intro to D3DImage

Monday, August 2, 2021
answered 4 Months ago

Depending on the context we can consider heap or stack. Every thread gets a stack and the thread executes instructions by invoking functions. When a function is called, the function variables are pushed to stack. And when the function returns the stack rollbacks and memory is reclaimed. Now there is a size limitation for the thread local stack, it varies and can be tweaked to some extent. Considering this if every object is created on stack and the object requires large memory, then the stack space will exhaust resulting to stackoverflow error. Besides this if the object is to be accessed by multiple threads then storing such object on stack makes no sense.

Thus small variables, small objects who's size can be determine at compile time and pointers should be stored on stack. The concern of storing objects on heap or free store is, memory management becomes difficult. There are chances of memory leak, which is bad. Also if application tries to access an object which is already deleted, then access violation can happen which can cause application crash.

C++11 introduces smart pointers (shared, unique) to make memory management with heap easier. The actual referenced object is on heap but is encapsulation by the smart pointer which is always on the stack. Hence when the stack rollbacks during function return event or during exception the destructor of smart pointer deletes the actual object on heap. In case of shared pointer the reference count is maintained and the actually object is deleted when the reference count is zero.

Saturday, September 25, 2021
answered 2 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :