Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Added overloaded encode function which can accept a character array #131

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Added overloaded encode function which can accept a character array #131

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions src/TinyGPS++.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -97,6 +97,16 @@ bool TinyGPSPlus::encode(char c)
return false;
}

bool TinyGPSPlus::encode(char* c, size_t len)
{
bool bRet = false;

for(int i = 0; i < len; i++)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you should return on a complete sentence, so you can process the data first.
But this also complicates stuff a bit as you then also should keep track of how many characters were read and keep the rest.
Or... you should pre-parse and only hand over chunks till the next newline char.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be a nice design change but that would also require several other changes in existing components of the library for your suggestion to integrate nicely. And as you mentioned already, that would make things more complicated. And even the way I have done, every statement gets processed, exactly like it would be by using the existing interface function which takes one character at a time (my change uses existing function anyway).

I had thought about what you have suggested but decided to implement this change the way I did because of the following reasons.

  1. Simplicity of the code change and the library interface (the user code remains simple as well).

  2. Consistency with the existing design and library interface. Existing encode function returns true upon completion of "A" sentence. The caller has no idea which sentence it was and what information (location? time? speed? etc.) was just updated as a result of this completion.

In a similar fashion, after my change, the caller knows that one or more valid sentences were successfully parsed by the library, but still does not know what was updated.

Therefore, this change is perfectly consistent with the existing library and it's external interface.

It would be another nice change if the library held "dirty" flags for all pieces of information it holds, so that the caller can figure out which fields contain new information.

  1. Minimal changes to existing code while still achieving what I wanted to achieve.

bRet |= encode(c[i]);

return bRet; // Return true if one of the characters resulted in a valid sentence
}

//
// internal utilities
//
Expand Down
1 change: 1 addition & 0 deletions src/TinyGPS++.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -221,6 +221,7 @@ class TinyGPSPlus
public:
TinyGPSPlus();
bool encode(char c); // process one character received from GPS
bool encode(char* c, size_t len); // process len characters received from GPS
TinyGPSPlus &operator << (char c) {encode(c); return *this;}

TinyGPSLocation location;
Expand Down