Thread safe classes

[sash]

A C++ class can only have instance methods, no static methods.

Static members in C++, data and functions

[Zoran]

A C++ class can only have instance methods, no static methods.

Static members in C++, data and functions

Yes, sorry. 
However, I still mean everything else I said about using static classes in Pascal.

[sash]

Wrapping routines (and variables too) in "static" classes, is a very good practice. It is a way to force qualifying function calls (and variables).

A very (c++/java)ish view which was formed exactly because a lack of "interface/implementation" division.

And while it is rather matter of personal preferences and code style, a creation of an entity as "sealed class" looks redundant to me.

[ASerge]

Anyway I was not able to have the same results using the second version posted by @ASerge.

OK. You got me . I also fixed another bug in the source code. Randomize does not do its job. To check enough to make that

Code: Pascal  [Select][+][-]

1. procedure TForm1.Button1Click(Sender: TObject);
2. var
3.   i: Integer;
4. begin
5.   Memo1.Clear;
6.   TThreadSafeRandom.Randomize;
7.   for i := 1 to 10 do
8.     Memo1.Append(IntToStr(TThreadSafeRandom.Random(High(Int64))));
9. end;

And press button several times. The next time you run the program, you will get the same sequence.
The new version is all right.

[apeoperaio]

I probably missed something, did you posted the corrected source somewhere?
What is TThreadSafeRandom?
Could you please provide me a sample project?
I am actually not able to use your unit with threadvar.

[ASerge]

I probably missed something, did you posted the corrected source somewhere?
What is TThreadSafeRandom?
Could you please provide me a sample project?
I am actually not able to use your unit with threadvar.

TThreadSafeRandom - get from first link.
The code from the test is a new project with a button that uses ... and code above.

[Zoran]

Wrapping routines (and variables too) in "static" classes, is a very good practice. It is a way to force qualifying function calls (and variables).

A very (c++/java)ish view

Please avoid using this argument.

which was formed exactly because a lack of "interface/implementation" division.

Of course not. When you create a function intended to be used by other units, you have to declare it in interface section, don't you?

Then your options are:
1. give it a long and cryptic name and hope that it won't clash with some other identifier.
2. write a comment above the declaration to ask users not to forget to prefix it with unit name, or to think well about order of units listed in uses section. 
3. put it in a class, let it be a class static method -- now you do get help from the compiler, which won't allow using your function without prefixing it with class name.

Choose according to your personal preferences.

[sash]

give it a long and cryptic name and hope that it won't clash with some other identifier.

name1.name2.name3 looks exactly same cryptic (or even longer by at least 2 dots in this case ) than Name1Name2Name3.

Not to mention, you could get similar side effects while writing (and people do) something like

Code: C++  [Select][+][-]

1. using namespace some_namespace;

Also, I've seen a cases of namespace clashes with two independent libraries, so everything has its own drawbacks, as I said this is a matter of personal view on a code naming conventions.

[BeniBela]

Wrapping routines (and variables too) in "static" classes, is a very good practice. It is a way to force qualifying function calls (and variables).

A very (c++/java)ish view

[/quote]


They are picking the rosines.

Java 10 got a var keyword. They get the best of the Pascal syntax, but we do not get any of their good syntax

Of course not. When you create a function intended to be used by other units, you have to declare it in interface section, don't you?

The worst is when you want to have one class to be used by other units, but this class need to use some other classes that should not be used by other units, but you still need to put all these classes in interface

[Zoran]

The worst is when you want to have one class to be used by other units, but this class need to use some other classes that should not be used by other units, but you still need to put all these classes in interface

Why would you need to put these in interface?

[Thaddy]

The new version is all right.

Although I agree somewhat with the cast (tnx I overlooked that, but should not be necessary), the next "fix" broke compatibility....
You did not test it, did you? against fpc's random or C++11 random?

That said, for others:
I provided an alias and this class is not meant to be instantiated. tsrandom is just  shorthand and distinguishes from random.

[BeniBela]

The worst is when you want to have one class to be used by other units, but this class need to use some other classes that should not be used by other units, but you still need to put all these classes in interface

Why would you need to put these in interface?

Because you want to use it

Code: [Select]

type
  TA = class
  end;
  TB = class
    a: TA;
  end;

TA should  not be visible to other units, but you cannot move it away from interface, while keeping TB public

[Zoran]

The worst is when you want to have one class to be used by other units, but this class need to use some other classes that should not be used by other units, but you still need to put all these classes in interface

Why would you need to put these in interface?

Because you want to use it

Code: [Select]

type
  TA = class
  end;
  TB = class
    a: TA;
  end;

TA should  not be visible to other units, but you cannot move it away from interface, while keeping TB public

One way to overcome this:

Code: Pascal  [Select][+][-]

1.  
2. type
3.   TB = class
4.   private type
5.     TA = class
6.     end;
7.   private
8.     A: TA;
9.   end;
10.