This is a CPP problem

This is a CPP problem

keprast

Member #16,794

January 2018

It's like you see it.I am a student.
Need the help of the teacher.

Now, there are two files.A.cpp and B.cpp.

A.cpp:

struct abc{................};

abc * edf = new abc[x];

...................

A is not the entrance.

B.cpp:

int main()
{..............}

This is object oriented programming.It's my problem, too.
How does this structure in B be used by A？

If you have time.Can you help me？:)

Of course, there is an example code that is the best.thanks.;)

bamccaig

Member #7,536

July 2006

Typically the main function is not called by user code. It certainly can be, and perhaps in a glorified world you'll discover a program that can do it, but in the real world it's very uncommon. main gets called automatically by the C or C++ compiler/runtime.

However, that doesn't matter because the only thing special about main is that it is called automatically as the entry point (starting point, or "entrance" as you called it). Otherwise, it's just a function like any other.

What you're asking about is also not really object-oriented. main is just a function AKA procedure, and has nothing to do with objects. What you're asking about is code reuse and modularization.

I wrote an article on the wiki a few years back that may help on the subject of header files which are key: https://wiki.allegro.cc/index.php?title=Header_file

C and C++ are rather old, and as a result carry some baggage from the hardware that existed at the time. In short, they do things silly because they were designed when memory capacity and CPU speeds were very small. This means that programs were built a piece at a time because the entire process wouldn't fit into memory. These days that's not a problem, and we've had technologies for decades that work better than C or C++ in this regard.

In C or C++, a single source file is compiled/processed at a time. This is considered a "compilation unit". A compilation unit cannot automatically see the rest of the program. A compilation unit can only see what is explicitly shown to it by the programmer (you or I).

For example, a program might consist of foo.cpp, bar.cpp, and main.cpp. Though integrated development environments (IDEs or GUIs) tend to abstract this, each file is typically compiled into a separate binary file (machine readable file) before the final program is made. Typically these intermediate files are called object files. Generally they have either a ".o" extension or a ".obj" extension. It's entirely optional to actually write these files or intermediate steps to the disk. Toolchains can do it all in memory too, but there's sometimes value in writing them to disk so that only files/compilation units that have changed need to be remade.

The way this all works is "declarations". Essentially, this means stating the "signature" or interface to a piece of code or data in each file/compilation unit so that the compiler knows how to interpret the specific memory cells when you use it.

It's a huge burden to keep all of these definitions (the actual thing) and declarations (a description of the thing) the same when changes occur to the program over time. To save a bit of effort, a program called the "preprocessor" interprets specially marked lines to "edit" files before passed them to the compiler. This program looks for "directives" (special instructions) and does things like copy the contents of a file into the compilation unit, or exclude parts of a file from the compilation unit (if, for example, the code is specific to a particular physical or virtual environment.

That is probably hard to understand even if English is your first language, let alone if it's not, so let me demonstrate.

foo.h#SelectExpand
  1// This pattern is called a "header guard". It uses preprocessor directives
  2// to prevent duplicating the file contents in a single "compilation unit".
  3#ifndef FOO_H
  4    #define FOO_H
  5
  6// Here we declare a function `foo` using a declaration.
  7void foo(void);
  8
  9#endif

foo.c#SelectExpand
  1// The preprocessor is used here to pull in declarations so the compiler will know
  2// that these functions exist. "stdio" is short for "standard I/O" which is short
  3// for "standard input/output". This is a standard module that contains interfaces
  4// for communicating between the user and the machine. We use it for the `puts`
  5// function to send a string of characters to the console.
  6#include <stdio.h>
  7
  8void foo(void) {
  9    puts("foo says: hello");
 10}

bar.h#SelectExpand
 1#ifndef BAR_H
 2    #define BAR_H
 3
 4void bar(void);
 5
 6#endif

bar.c#SelectExpand
  1#include <stdio.h>
  2
  3// We use a preprocessor directive to pull in the declarations from our own
  4// "foo" module. This way when we comile "bar.c" the compiler will know about
  5// `void foo(void)`.
  6#include "foo.h"
  7
  8void bar(void) {
  9    puts("bar says: hello");
 10
 11    foo();
 12
 13    puts("bar says: goodbye");
 14}

main.c#SelectExpand
  1#include <stdio.h>
  2
  3#include "bar.h"
  4
  5int main(int argc, char * argv[]) {
  6    puts("main says: hello");
  7
  8    bar();
  9
 10    puts("main says: goodbye");
 11
 12    return 0;
 13}

Expected output:

main says: hello
bar says: hello
foo says: hello
bar says: goodbye
main says: goodbye

Try to comment out the "#include" directives to see what happens. Suddenly the compiler won't understand that these functions exist, and so the program won't be able to build.

The compilation step turns a source file into an object file. A separate step, the linker step, turns these various objects and libraries (which may be an object archive, static library, dynamically linked library, or shared object; the latter of which are just various ways to store compiled code for reuse).

This is probably a lot, and probably not explained very well, but hopefully it'll give you enough to ask questions so that we can build on it.

--
I mean the best with what I say. It doesn't always sound that way.

LennyLen

Member #5,313

December 2004

You need to include the other file. Note: You should only include header (.h) files, not source (.cpp) files.

#SelectExpand
  1// Example.h
  2//
  3//
  4#ifndef EXAMPLE_H
  5#define EXAMPLE_H
  6
  7
  8struct Example
  9{
 10    int foo;
 11    int bar;
 12};
 13
 14#endif // EXAMPLE_H
 15
 16
 17
 18// main.cpp
 19//
 20//
 21#include <iostream>
 22#include "Example.h"
 23
 24int main()
 25{
 26    Example ex;
 27    ex.foo = 10;
 28    ex.bar = 20;
 29
 30    std::cout << "Foo = " << ex.foo << " and Bar = " << ex.bar << std::endl;
 31
 32    return 0;
 33}

If the class/struct is more complicated, you declare the class in the header file and have the definition in a source file that also includes the header file with the class declaration.

Edit: sigh, beaten because I've been doing too much C# coding lately.

keprast

Member #16,794

January 2018

Thank you. It's like a tree.
Need“.h ”as a branch.:)