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.

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

Remove C++ keywords in header files #195

Closed
bylee20 opened this issue Aug 19, 2013 · 8 comments
Closed

Remove C++ keywords in header files #195

bylee20 opened this issue Aug 19, 2013 · 8 comments

Comments

@bylee20
Copy link
Contributor

bylee20 commented Aug 19, 2013

This is a suggestion and not a bug.

Some variables are named with C++ keywords.
For instance, struct m_option has a member nambed 'new' which is a reserved keyword in C++ for memory allocation.
This enforce to write some dirty codes in order to link mpv with C++ applications like:

#define new ____new
#include "m_option.h"
#undef new 
...
m_option opt;
opt.____new = 1;

(Actually, I'm recognizing this problem in m_option.h only.)

It would be nice to exclude all C++ keywords in mpv's header files.
Maybe I'm the only one who feels uncomfortability from this currently because I'm developing a C++ application linked with mpv.
However, if you have plan to provide mpv as a regular C library (see #97 ), this could be a major problem.

@ghost
Copy link

ghost commented Aug 19, 2013

I'm not against it, but yeah, in general the code in the headers expects C99 and compiles as C++ only by coincidence. Is there anything else?

However, if you have plan to provide mpv as a regular C library (see #97 ), this could be a major problem.

That would use a minimal wrapper API, with no direct access to mpv internals.

@bylee20
Copy link
Contributor Author

bylee20 commented Aug 19, 2013

Ok, fair enough. I'm the one who uses mpv by irregular method, so I think I have to bare with it.

For your information, I've just tried to find other cases in *.h with regexp

'\b(new|this|delete|final|override|public|protected|private|friend|throw|try|catch|virtual)\b'

which is considered as frequently used words, IMO, and the result is:

  • new in mpvcore/m_option.h
  • this in sub/spudec.h

@ghost
Copy link

ghost commented Aug 19, 2013

this in sub/spudec.h

Only sd_spu.c includes this, and there's no reason to include it yourself, so I suppose this doesn't need to be changed.

I can change the m_option.h case later this day.

@bylee20
Copy link
Contributor Author

bylee20 commented Aug 19, 2013

Glad to hear that. Thank you!

ghost pushed a commit that referenced this issue Aug 19, 2013
Cosmetic change to allow C++ code to include this header.

See github issue #195.
@ghost
Copy link

ghost commented Aug 19, 2013

Done.

@ghost ghost closed this as completed Aug 19, 2013
@bylee20
Copy link
Contributor Author

bylee20 commented Aug 19, 2013

Can you bring declaration of 'enum seek_type' to global scope?
Sorry, I've forgotten to mention this problem.

Currently, 'enum seek_type' is defined in mp_core.h:

typedef struct MPContext {
    ...
    struct seek_params {
        enum seek_type {
            MPSEEK_NONE, MPSEEK_RELATIVE, MPSEEK_ABSOLUTE, MPSEEK_FACTOR
        } type;
        ...
    } seek;
    ...
} MPContext;

and, the declaration of queue_seek() function in mp_core.h take a parameter whose type is 'enum seek_type':

void queue_seek(struct MPContext *mpctx, enum seek_type type, double amount, 
                int exact);

In C++, each struct has its own scope, so a variable of 'enum seek_type' should be declared like

MPContext::seek_params::seek_type type;

which conflicts with the prototype of queue_seek().

I think you can just declare 'enum seek_type' top of MPContext like:

enum seek_type {MPSEEK_NONE, MPSEEK_RELATIVE, MPSEEK_ABSOLUTE, MPSEEK_FACTOR};
typedef struct MPContext {
    ...
    struct seek_params {
        enum seek_type type;
        ...
    } seek;
    ...
} MPContext;

Sorry to bother you.

@ghost
Copy link

ghost commented Aug 19, 2013

Did so.

@bylee20
Copy link
Contributor Author

bylee20 commented Aug 19, 2013

Good. Thank you so much.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant