Thread: ITSA Ready! (Version 0.381966)

ITSA has been updated and the latest release is now ready for alpha-stage testing! The library has seen some major restructuring in the process and a *lot* has changed. Exceptions can be propagated to the user or suppressed in favor of returning a boolean value. Sockets can now be passed around to other services. A built-in message-passing protocol simplifies the construction of higher level protocols. You gotta check it out!

I'd also like to thank everyone for the comments and suggestions; had it not been for you, ITSA 0.381966 probably wouldn't even exist!

Note: The new API is unfortunately not 100% compatible with the previous version, so please use the examples included rather than the ones from the last incarnation of the library.

P.S.: Sorry about the crappy documentation...I did the best I could despite a serious lack of sleep, okay?

Ha, doesn't even compile! (Errant 'using' statement on line 961 or some such)

Okay, version 0.3819660...

Whoops - I think I deleted them! Can an admin here please undelete those? Well, I can repost those older versions (for posterity, at least) in a bit...

Quick note:

Code:

template <typename Type>
void zero(Type& data)
{
	memset(&data, 0, sizeof(Type));
}

This is dangerous (what if T is a C++ object?). I don't know why it's there in the first place. It should be the user's responsibility to zero out stuff if necessary. It's trivial when initializing objects.

Code:

bool settings::s_exceptions = false;
int settings::s_default_buffer_length = ITSA_DEFAULT_BUFFER_LENGTH;

Declaring statics in a header file?

>> This is dangerous (what if T is a C++ object?). I don't know why it's there in the first place. It should be the user's responsibility to zero out stuff if necessary. It's trivial when initializing objects.

I know, that's why it's tucked away in the itsa::detail namespace. But come to think of it, won't the compiler zero out even a constructorless object with this:

Code:

template <typename Type>
void zero(Type& data)
{
    data = Type();
}

...or no?

>> Declaring statics in a header file?

Well, the library itself is contained within a single header file, so...where else to put them?

Found a bug on line 735: fail<recv_exception>(format >> data).

Fixed.

Declaring statics in a header file?

O_o

Right to point out the issue; wrong way to point the issue out.

1): A `static' variable is different than a `static' member variable.
2): Definitions are not declarations.

Code:

class S{static int m;}; // a non-template declaration of a `static' member variable which is really a global with specific visibility

Code:

int S::m; // a non-template definition of a `static' member variable which must appear exactly once in a given, linked, binary

[Edit]
To clarity, a global variable marked `static' is different in that such a variable is considered to have "internal linkage" which is a fancy way of saying that even though each translation unit including the definition of the variable gets a copy of that variable something is done to the label/memory so that multiple definitions are not a problem.
[/Edit]

Well, the library itself is contained within a single header file, so...where else to put them?

Well, the correct answer is "Any specific translation unit you wish to provide.".

Despite what you imagine, considering the emoticon, the definition appearing in a header is a mistake.

The definition appearing in a header results in a definition appearing in every translation unit where the header is included which results in, usually, linker errors.

[Edit]
You can use templates to solve the issue without distributing a source file or using macro trickery--one possible C solution.

You just need to separate the `static' member variable bits into a template component which forces the compiler suite--generally linker--to perform the same sort duplicate elimination required by general template expansion.

Code:

template <typename IGNORED> class S_t{protected:static int m;}; // declare `static' member variables
template <typename IGNORED> int S_t<IGNORED>::m = 0; // define `static' member variables

class S: public S_t<void>
{
    /* the magic line `public', `private', or `protected' */ public: using S_t<void>::m;
};

[/Edit]

Soma

Originally Posted by Sebastiani

I know, that's why it's tucked away in the itsa::detail namespace. But come to think of it, won't the compiler zero out even a constructorless object with this:

Code:

template <typename Type>
void zero(Type& data)
{
    data = Type();
}

...or no?

If T is an integral type, then yes; otherwise, it will just call the default constructor.

>> Declaring statics in a header file?
Well, the library itself is contained within a single header file, so...where else to put them?

Well, statics and header-only libraries are kind of not compatible...
Now, I haven't looked at the entire source, but why don't you just use Boost Asio's style of one overload that takes a reference to a error-condition variable that does not throw and one overload that takes no such variable and throws? That eliminates the need for global state.

Why don't you just use Boost Asio's style of one overload that takes a reference to a error-condition variable that does not throw and one overload that takes no such variable and throws?

O_o

I'd prefer object specific settings like the standard library.

Soma

>> The definition appearing in a header results in a definition appearing in every translation unit where the header is included which results in, usually, linker errors.

Right, forgot about that! Well, I'll just put them in itsa.cpp then. Done.

>> If T is an integral type, then yes; otherwise, it will just call the default constructor.

What I meant though was constructorless objects containing only native types. What then? It seems to work under GCC, but I wonder if it's undefined behavior?

>> Now, I haven't looked at the entire source, but why don't you just use Boost Asio's style of one overload that takes a reference to a error-condition variable that does not throw and one overload that takes no such variable and throws?

I'd rather not, if I can at all avoid it. Too cluttered.

>> I'd prefer object specific settings like the standard library.

Interesting idea, though I imagine the implementation might be pretty complicated...

*** EDIT ***

>> You can use templates to solve the issue without distributing a source file or using macro trickery--one possible C solution. You just need to separate the `static' member variable bits into a template component which forces the compiler suite--generally linker--to perform the same sort duplicate elimination required by general template expansion.

Missed your post, sorry. Sounds good, I'll try that.

Originally Posted by Sebastiani

What I meant though was constructorless objects containing only native types. What then? It seems to work under GCC, but I wonder if it's undefined behavior?

It is well defined syntax for value initialisation, which for the types you have in mind means zero initialisation.

Code:

template <typename IGNORED> class S_t{protected:static int m;}; // declare `static' member variables
template <typename IGNORED> int S_t<IGNORED>::m = 0; // define `static' member variables
 
class S: public S_t<void>
{
    /* the magic line `public', `private', or `protected' */ public: using S_t<void>::m;
};

Brilliant man, works like a charm! Where the hell did you learn that anyway? Great stuff.

>> It is well defined syntax for value initialisation, which for the types you have in mind means zero initialisation.

Awesome, thanks. I'll just do away with using memset then...

Brilliant man, works like a charm! Where the hell did you learn that anyway? Great stuff.

O_o

Back in 1998, that seemed like something worth having realized. (My secondary compiler, "Microsoft Visual C++ 6.0", had a lot of problems related to templates.) I'm sure I've even bragged about having "discovered" some technique.

Now a days, the technique seems obvious. Something somewhere, virtually always the linker, needs the juice to eliminate duplicated template expansions. Placing stuff the inclusion model will duplicate, otherwise causing problems, behind a template only makes sense.

Thanks for sure but kind of depends really on your perspective. I had to jump through a lot of hoops, even using different compilers to learn different features, when I started learning C++ for university. You could say I figured it out through a lot of studying. On the other hand, I had to do a lot of "hoop jumpery" even to get my code to compile making some things really stand out; you could say I stumbled over it simply because some of the tools really sucked.

Soma