avoiding object files

[Alexander Stippler]

Hello,

I have written a little library which consists of template functions and
classes (99%) and two non-template classes. I'd appreciate very much if I
could use the library by only including some header files without having to
deal with building and linking a library or object files. Are there any
tricks how this can be achieved?
I guess not, but perhaps you know better.

Best regards,
alex

 

[Rob Williscroft]

Alexander Stippler wrote in in
comp.lang.c++:

Hello,

I have written a little library which consists of template functions
and classes (99%) and two non-template classes. I'd appreciate very
much if I could use the library by only including some header files
without having to deal with building and linking a library or object
files. Are there any tricks how this can be achieved?
I guess not, but perhaps you know better.

Instead of

class non_template
{
// whatever
};

Do:

template < typename = void >
class for_non_template
{
// Whatever (as above).
};

typedef for_non_template<> non_template;

HTH.

Rob.

 

[David Lindauer]

Alexander Stippler wrote in in
comp.lang.c++:


Instead of

class non_template
{
// whatever
};

Do:

template < typename = void >
class for_non_template
{
// Whatever (as above).
};

typedef for_non_template<> non_template;

what does it mean if you use the typename keyword in a template parameter
declaration?

Thanks,

David

 

[Rob Williscroft]

David Lindauer wrote in in
comp.lang.c++:

what does it mean if you use the typename keyword in a template parameter
declaration?

Its exactly the same as when you use class.

Rob.

 

[Alexander Stippler]

Alexander Stippler wrote in in
comp.lang.c++:


Instead of

class non_template
{
// whatever
};

Do:

template < typename = void >
class for_non_template
{
// Whatever (as above).
};

typedef for_non_template<> non_template;

HTH.

Rob.

That works fine for whole classes, but what about simple objects. I have
only one global variable, which I do not want to give any dummy template
parameter. Just an instantiation of a non-template class. It's only this one
object which forces the creation of a library. Any workaround?

regards,
alex

 

[Lionel B]

/snip/

... I have only one global variable, which I do not want
to give any dummy template parameter. Just an instantiation
of a non-template class. It's only this one object which
forces the creation of a library. Any workaround?

Well, you could declare your global variable "extern" in the header and
demand that the *user* of the library define it somewhere.
Regards,

 

[Rob Williscroft]

Alexander Stippler wrote in in
comp.lang.c++:

That works fine for whole classes, but what about simple objects. I
have only one global variable, which I do not want to give any dummy
template parameter. Just an instantiation of a non-template class.
It's only this one object which forces the creation of a library. Any
workaround?

inline non_template &object()
{
static non_template obj = non_template();
return obj;
}


Rob.

 

[Alexander Stippler]

Alexander Stippler wrote in in
comp.lang.c++:



inline non_template &object()
{
static non_template obj = non_template();
return obj;
}


Rob.

Works in general. But this way I have a function call, not direct access. In
my special situation direct access to the variable is necessary. It is
called '_' and I want to use it for function arguments in special
situations, like A( _ , 1 ) and not A( _(), 1). Thus your solution does not
work for me. I'm afraid, IMO there is no solution.

regards,
alex

 

[Lionel B]

/snip/

That's neat

Works in general. But this way I have a function call, not direct access. In
my special situation direct access to the variable is necessary. It is
called '_' and I want to use it for function arguments in special
situations, like A( _ , 1 ) and not A( _(), 1). Thus your solution does not
work for me. I'm afraid, IMO there is no solution.

What exactly is the problem with declaring your object "extern"?

Regards,

 

[Alexander Stippler]

That's neat


What exactly is the problem with declaring your object "extern"?

Regards,

We want to achieve the most simple way of usage for our library since users
are students with very poor knowledge of C++ and software development at
all. They shall do numerical exercises with it (and have already done
successfully one semester).
Declaring '_' as extern would require the user to define it somewhere. On
the other hand this tiny little '_' object is a really nice piece of
syntactic sugar, we do not want to miss anymore. But it's also the one
single piece of code which prevents us from having the whole library to be
used by including headers only.

regards,
alex

 

[Lionel B]

/snip/

/snip/

We want to achieve the most simple way of usage for our library since users
are students with very poor knowledge of C++ and software development at
all. They shall do numerical exercises with it (and have already done
successfully one semester).

Fair enough.

Declaring '_' as extern would require the user to define it somewhere. On
the other hand this tiny little '_' object is a really nice piece of
syntactic sugar, we do not want to miss anymore. But it's also the one
single piece of code which prevents us from having the whole library to be
used by including headers only.

I have to confess that having a variable called '_' sounds to me like
a recipe for generating fabulously opaque compiler errors (especially
for "students with very poor knowledge of C++" ...?).

That said, surely even the most computer-illiterate student could be
persuaded to copy-and-paste the line:

underscore_object_type _;

into a source file? Perhaps they might be enticed with:

#define MY_TEACHER_TOLD_ME_TO_PUT_THIS_HERE underscore_object_type _;