Forward Declaration is !(a lie)

[newbieg]

I'm playing around with building my own compiler, obviously just a learning exercise.
This means I am viewing the assembly output of gcc -S

Now read the title again.

Forward declaration of a function produces exactly* the same assembly output as defining the entire function above main?

Does anything else about the C/C++ language just make you stop and say what?

* footnote: sorry, because it produces the functions in the order that they are defined in, so the one with forward declaration just has main listed first. Sorry for the exaggeration above, but it actually stresses the point even further. A function does not need be defined before it it called, just so long as it is defined somewhere.

[ne555]

> exactly* the same assembly output as defining the entire function above main?
> A function does not need be defined before it it called, just so long as it is defined somewhere.
a function needs to be declared before being called

void bar(){foo();}
void foo(){}

will fail at compilation

error: ‘foo’ was not declared in this scope

[Duthomhas]

No, the compiler needs to know what the function signature is before you can call it.

Older C dialects allow you to use a function before declaring it by assuming some things about it, but modern C11 and C++ forbid that (IIRC).


Forward declarations are not “a lie”.
You have simply assumed that they produce some sort of code.

Which they don’t.

[againtry]

Comprehensively, without a word of a lie :)
https://stackoverflow.com/questions/4757565/what-are-forward-declarations-in-c++

[Ganado]

Taking this from a different angle: C++ has no standard binary format and makes no guarantees about the layout of functions that the linker determines.

[newbieg]

@Ne555: I should have clarified that when I used the word function I meant in respect to the assembly/machine code that is output. I was surprised that while the compiler/language has a rule about forward declaration, it didn't produce assembly that matched that rule.

I didn't mean this as a rebuff against the C++ language. As Duthomas suggests, I just had a moment of realization that I believed that by writing the FD each time I was producing meaningful output. I kind of felt tricked.

It's like finding out that I was told to push a button when I enter a room in order to turn on the lights. Then, after several years, one day I decide to add a new light in a dark corner of the room, so open up some of the wiring, and find a separate wire that actually leads to a motion sensor. All along I could have just walked into the room 3 extra feet and the lights would have turned on anyway.

Figuring out that FD is not required in assembly would have helped me earlier in a book on assembly I tried and gave up on reading partly because I thought the code made no sense because it was out of order. Could have taken a hint from that I guess.

Thank you Againtry for the comprehensive on the benefits on forward declaration, that it speeds up build time and makes name-clashes less dangerous by giving local functions preference. Good to know that there is actual benefits to the thing even if it isn't generally a change in the final product.

[helios]

I still don't understand what you mean. What counts as a "lie" by your interpretation? Are variable names lies? Data types?
The compiler is not required to structure the resulting machine code in any particular way, as long as the behavior is equivalent, so are ifs, whiles, and even functions themselves lies too?

[Ganado]

And surely at some point you saw a code example with a function that wasn't forward declared, right? What was a trick about that, exactly, compared to other changes that happen in assembly? Did you think it produces less optimal assembly due to lack of an FD? Just curious.

Sorry if I'm beating a dead horse but just to summarize: Forward declaring just tells the parser "this is a function with a particular signature"; no actual logic or instructions have been produced. (You don't need to do any sort of forward declaring unless you have some sort of interdependeny.)

[newbieg]

@helios: I have not done much in assembly before, so it surprised me and made me feel a little foolish about my own assumptions is all. Like the story about a light in the room in my previous post: all I would have needed was to try some things out earlier. It just changed my perspective on how things actually work.

In my original post I do apologize for exaggeration, I again apologize for my hyperbole and hope that my modification to the topic line helps.

My original goal was not to focus of FD, but to open a topic on what about C++ may have altered your perspective as you learned more about it.

[deleted account xyzzy]

Does anything else about the C/C++ language just make you stop and say what?

Not really, especially the things you are talking about.

I accept that the compiler/linker does what it does no matter what. The compiler writers know lots more about efficient machine code layout than I do. More than I ever will know.

USING the language tools provided is what interests me. The differences of coding that can occur between the C++98/11/14/17 standards simultaneously intrigue and frustrate me.

Probably because I am self-taught, still learning. I am a hobbyist, not a pro.

I am grateful there are people who do obsess over creating solid machine code from a high level language. I benefit from their fanaticism.

[Ganado]

Does anything else about the C/C++ language just make you stop and say what?

- Having an empty destructor defined can produce less efficient code than just setting it to default.
- Template compiler errors
- Negative effects of Argument-Dependent Lookup: http://www.cplusplus.com/forum/lounge/263831/
- "Most vexing parse": https://en.wikipedia.org/wiki/Most_vexing_parse
- C++ is insanely hard to parse and slows down my intelliSense for even some medium projects: https://www.youtube.com/watch?v=WfIr7lKT4Sk
- "More vexing parse" @ 22:38 in above link
-----> void bar3(foo((foo)));
- C is still the necessary language for portable DLLs
- Passing tolower to an <algorithm> function can be annoying; it's an ambiguous call if your library implementation internally #includes both <locale> and <cctype>. But the compiler doesn't always tell you it's ambiguous; it just tries to go with what it thinks is the 'right' function, and then gives you an error saying the input doesn't match the types of the function parameters.
- RTTI has a cost even if you don't use it.

[newbieg]

OMG Ganado, That is quite the list! YES!!! Thank you, these are perfect.

In my little compiler project I've barely started getting some basic arithmetic and controls to output into assembly. Thank you for reminding me that I'd eventually have to tackle templates and all that weirdness. In that list you've given me days/weeks worth of research to get into and many things to keep in mind going forward. This is awesome! (Now I can go and obsess over these quietly in my corner)

@Furry Guy. I get that and understand not diving too deep since that's also how I go about learning to use a new library or new API as well. Truly you will actually make more apps/programs your way and they will be more useful for most users than what I'm doing. Nothing wrong with that at all.
Oh, and C++98/11/14/17 bugs me too, like being happy with the methods used for random numbers in older C/C++ only to find out that srand(time(NULL)) has been replaced with a much stranger random number scheme in later C++ which may be more difficult to use but yields better randomization. (http://www.cplusplus.com/reference/random/) That nagged at the back of my mind for the longest time that my numbers might not be random enough. I learned part of the new library, then I decided that nearly random was good enough until I needed better, then I'd learn the new method all over again. Again, just diving as deep as needed then come up for air.