next topic »

[Reply #15 on:]

Not a problem. I am the same way. 

I can see where doing it the way you described saves on the copying and pasting. Perhaps someday I'll try that too, once I get my "sea legs" so to speak.

[Reply #16 on:]

...That fixed it!!

Huzzah!!!

...when you print a book, and the information in it is wrong, it stays wrong forever.

I poked around a little and found that the book has a web site (http://pragprog.com/titles/msard/arduino), and even an errata page (http://pragprog.com/titles/msard/errata)
You can make your own contribution to the community by posting a correction (or corrections) there.  (Since I haven't bought the book, I wouldn't dream of taking it on myself to post there.)


Regards,

Dave

The errata page lists things found (apparently anyone is free to submit information) in both the printed and PDF versions of the book. One such submission explains why I wasn't getting any output to the Serial Monitor. The author had omitted the

Code:

Serial.begin(BAUD_RATE);

needed to initialize serial activity. Your suggestion had included that statement, so that's why it started working for me. But I don't see anything about the missing

Code:

delay(_dit_length);

which fixed the whole project so it worked correctly. So I will probably submit that, giving thanks to you good folks here on the forum.

BTW, in another thread I had been stumbling around a bit trying to use the correct terms for things. Do I recall correctly that pretty much any line like the above (no matter whether it is a function, method, etc.) can all be referred to as a "statement"? My previous programming experiences date back into the 70s and 80s and I probably have forgotten most of it by now.

[Reply #17 on:]

.
...pretty much any line like the above (no matter whether it is a function, method, etc.) can all be referred to as a "statement"?

The formal definition of statement in the C language specification document goes like this:
"A statement specifies an action to be performed."  So, yes, that is a statement.

In particular, a statement that performs a call to a void function or a statement that calls any other kind of function (for its side effects) but discards the return value is called an "expression statement," but one hardly ever bothers with that specific language.

Bottom line: It's a statement.  (But I already said that.)


Regards,

Dave

[Reply #18 on:]

Thanks!

I signed up for an account on pragmatic programmers. The errata page for this book doesn't show anything past this project but I still have > 1/2 the book to finish. So if I get stuck again I can try going "straight to the horse" for a solution.

[Reply #19 on:]

I could use some help figuring out what to put in my comment lines, as I go along explaining to myself how this sketch works, for some of the code in the above project. In the Telegraph.cpp file, I think I know that the line

Code:

void Telegraph::dit() {

Is declaring the function "dit()" that resides in the Class "Telegraph" (laid out in the Telegraph.h library file) and that the function is not going to return any data. Right?

But a slightly similar line caught my eye as I typed it in, because the Arduino IDE made it gray instead of the other colors I have seen for functions. The first line in this section of code. What exactly does it mean?

Code:

Telegraph::Telegraph(const int output_pin, const int dit_length) {
  _output_pin = output_pin;
  _dit_length = dit_length;
  _dah_length = dit_length * 3;
  pinMode(_output_pin, OUTPUT);
}

I noticed there is a Class "Telegraph", and then a Function (or Method?) Telegraph being declared in this section of the Telegraph.h code:

Code:

class Telegraph {          //create class Telegraph
  public:                              // This is the PUBLIC part of the class that users of the class have access to
    Telegraph(const int output_pin, const int dit_length);

So is that line I questioned above accessing the Telegraph FUNCTION (or MODE?) within the Telegraph CLASS? If so, why is it colored gray by the IDE whereas the VOID statements of similar functions are always orange?

Thanks.

[Reply #20 on:]

In the Telegraph.cpp file, I think I know that the line
void Telegraph::dit() {
Is declaring the function "dit()" that resides in the Class "Telegraph" (laid out in the Telegraph.h library file) and that the function is not going to return any data. Right?

Right. However a comment to that effect is pretty much useless. Anyone looking at the code can see that that is the case. The comment should define what dit() does.

The first line in this section of code. What exactly does it mean?

The first line is:

Code:

Telegraph::Telegraph(const int output_pin, const int dit_length)

(The open curly brace belongs on the next line).
It is defining a special function in the class called a constructor. The name of the function is (and must be) exactly the same as that of the class, and it returns no value. The reason for this is that the constructor is typically (though not on the Arduino) called like so:

Code:

Telegraph *morseSender = new Telegraph(10, 30);

The constructor is invoked by the new operator which has it's own ideas about what to return.

[Reply #21 on:]

I do not understand.

With the statement

Code:

Telegraph::dit()

being valid, why is it that in

Code:

Telegraph::Telegraph(const int output_pin, const int dit_length)

The name of the function is (and must be) exactly the same as that of the class

? I could not have a statement such as

Code:

Telegraph::Morse(const int output_pin, const int dit_length)

instead and have it be valid?

[Reply #22 on:]

Why is it that when you drop an egg it always falls to the floor? There are simply some rules you have to accept. One of the rules is that classes have constructors. Another is that the name of the constructor must match that of the class.

[Reply #23 on:]

If I have figured this out correctly, it doesn't present the "issue" I had thought it to present. Please tell me if I have this right or not:

You can make a Class, such as Telegraph

               In that Class you can use a constructor to make an object Telegraph (must be the same name as the
               Class)

                         Then, you can USE the Telegraph object as many times as you like by declaring methods of
                         the object as many times as you like, using them in a format such as:

Code:

Telegraph.code()
Telegraph.key()
Telegraph.device (3,2,1)

You can also create more objects under the same class and Telegraph object by using statements such as:

Code:

Telegraph one()
Telegraph two()
Telegraph three(3,2,1)

And then use those (sub? secondary?) objects in the same format as above:

Code:

one.code()
two.key()
three.device(3,2,1)

So if I understand this correctly, my original thought, that requiring a class and its (primary?) object to have the same name seeming very restrictive as to how many objects a class could have, was completely unfounded. The process branches out sort of like an Outline format, and can have a whole slew of named objects, methods and functions.





                                  

[Reply #24 on:]

Please tell me if I have this right or not:

Not entirely, no.

A class is a template, like a cookie cutter. Once you have defined the class, you can use it to create as many objects/instances (cookies) as you like - all having the same capabilities.

The class, like Telegraph, needs a constructor, so instances can be created. The constructor is a special method that needs to be named the same as the class. There can be other methods in the class, that can have any name you like.

When you create instances of the class, the constructor will be executed. So,
Telegraph one;
Telegraph two;
creates two instances of the Telegraph class.

Each of those instances has all the methods and fields of the class. The methods are shared, but the fields are completely independent.

If the Telegraph class has a field:

Code:

unsigned long dit_length;

and a method:

Code:

void SetDitLength(unsigned long ditLength)
{
  dit_length = ditLength;
}

then,

Code:

one.SetDitLength(10);
two.SetDitLength(10000);

will assign different values to the dit_length field of each instance.

So if I understand this correctly, my original thought, that requiring a class and its (primary?) object to have the same name seeming very restrictive as to how many objects a class could have, was completely unfounded.

There is no relationship whatsoever between a class name and the names of any instances of the class.

The only relationship between a class name and a method name is for two special functions - the constructor, which we have been talking about, which has the same name as the class, and the destructor, which we haven't talked about, which has the name of the class preceeded by a ~.

Code:

class Telegraph
{
   public:
      Telegraph(); // Constructor
      ~Telegraph(); // Destructor

   // Any other public methods

   // Any public fields (typically none)

   private:
   // Any private methods

   // Any private fields
};

[Reply #25 on:]

OK. Thanks! I think I have a 'basic' grasp on these concepts. What I need now is to see them in action, before I try to learn more of the terminology. That will help me remember how this fits together.

I did run across the destructor term in some of the online tutorials I have found for Arduino coding and some for C++ but the book I am using hasn't implemented destructors yet.  I know the depth of the whole C++ programming language and all its rules could fill several books and take a great many credit-hours to fully understand. But the hands on approach to learn these programming terms as they apply to Arduino projects is my intent so I'll press on in the book.

Thanks again for helping me understand this.