* * *

Recent Posts

Pages: [1] 2 3 ... 10
1
General / Re: Why should we use classes instead of records?
« Last post by marcov on Today at 04:04:07 pm »
Well, 99% of the time the objects are dynamically allocated.  Making classes an auto reference removes the need to constantly mess with pointer syntax and have special parameters modifiers like & in C++.

Classes this way also don't need a deep assignment operation, since normal assignment just copies references.

For iterators, and other small potato stuff (like TPoint and vector types) that is often static, there's records with methods.

So the only problems are combining that, but not having to deal with the pointer syntax most of the time is well worth that.
2
General / Re: Why should we use classes instead of records?
« Last post by taazz on Today at 03:41:27 pm »
I'm wondering that why are default C++ classes value typed, not reference typed but Object Pascal classes are reference typed, not value typed? Should a class be value typed or reference type as default in any programming language?
I guess they took different approaches to solving the same problem as thaddy already said turbo pascal 5 or 6 had similar objects with C/C++ with delphi 1.0 they moved to heap based classes instead I never managed to find any info on why they did that I have some assumptions on why but they are only that assumptions and not worth sharing.
Actually my question is this.

I'm usually writting C++ codes and I use C++ object files in OP.
There is a C++ class:
Code: Diff  [Select]
  1. class QString
  2. {
  3. private:
  4.  ...
  5. public:
  6.  ...
  7. };
  8.  
I want to use this QString C++ class in Object Pascal. Should I use this:
Code: Pascal  [Select]
  1. type
  2.   QString = record
  3.   end;
  4.  
Or should I use this:
Code: Pascal  [Select]
  1. type
  2.   QString = class
  3.   end;
  4.  
And why? Thanks all.
neither is safe again quoting Thaddy you should use Object eg
Code: Pascal  [Select]
  1. type
  2.   QString = object
  3.   end;
  4.  
but not before reading this http://rvelthuis.de/articles/articles-cppobjs.html it should give you a general idea of what problems to expect.
3
General / Re: Request for peer review: classes on the stack
« Last post by Thaddy on Today at 03:39:40 pm »
I found a small issue myself with parameterless constructors. These work except for the first level derived class. Strange because the base create does nothing.
I will investigate if I should document it as a limitation or that there is a solution. Subsequent second level derived parameterless constructors work as expected.

A.t.m. it only works without optimization, but I know how to solve that. I edited the unit to compile in {$O-} state.
4
General / Re: Why should we use classes instead of records?
« Last post by Thaddy on Today at 03:28:13 pm »
Quote
Code: C  [Select]
  1.   // Dynamic:
  2.   Example* instance_ptr = new Example(5); // Reference typed, created on the heap.
  3.  
Is exactly what I described. before, isn't it? The statement that C++ classes are always created on the stack is not true.

Anyway, I found a - somewhat limited - way to create Object Pascal classes on the stack. See above. Note I use C++ more than I like and for over 20 years.
5
In the example, three paths are expanded with ExpandFileName. The result when there are multiple path separators seems to be wrong. 

Code: Pascal  [Select]
  1. program Project1;
  2.  
  3. {$IFNDEF FPC}{$APPTYPE CONSOLE}{$ENDIF}
  4.  
  5. uses
  6.   SysUtils;
  7.  
  8. begin
  9.   Writeln(ExpandFileName('/var/log//../'));
  10.   Writeln(ExpandFileName('/var/log/../'));
  11.   Writeln(ExpandFileName('/var/log/..'));
  12. end.  

output if compiled with fpc for linux
Code: Pascal  [Select]
  1. /var/log/
  2. /var/
  3. /var

output if compiled with fpc for windows
Code: Pascal  [Select]
  1. D:\var\log\
  2. D:\var\
  3. D:\var

output if compiled with kylix
Code: Pascal  [Select]
  1. /var/
  2. /var/
  3. /var

output if compiled with delphi
Code: Pascal  [Select]
  1. D:\var\
  2. D:\var\
  3. D:\var


Code: Pascal  [Select]
  1. $ realpath /var/log//../
  2. /var
  3. $ realpath /var/log/../
  4. /var
  5. $ realpath /var/log/..
  6. /var
6
General / Re: Why should we use classes instead of records?
« Last post by İbrahim on Today at 03:23:21 pm »
Thanks for all your replies.

Quote
Thaddy: C++ classes are stack oriented as a generalization is false.
Default C++ classes are value typed (created on the stack). Default Object Pascal classes are reference typed (created on the heap). I mean:
Code: Diff  [Select]
  1. class Example
  2. {
  3. private:
  4.   int _count;
  5. public:
  6.   Example();
  7.   Example(int count);
  8.   void print() const;
  9. };
  10.  
  11. Example::Example() : _count(0)
  12. {
  13. }
  14.  
  15. Example::Example(int count) : _count(count)
  16. {
  17. }
  18.  
  19. void Example::print() const
  20. {
  21.   std::cout << _count << std::endl;
  22. }
  23.  
  24. void main()
  25. {
  26.   // Default:
  27.   Example instance(5); // Value typed, created on the stack.
  28.   instance.print();
  29.  
  30.   // Dynamic:
  31.   Example* instance_ptr = new Example(5); // Reference typed, created on the heap.
  32.   instance_ptr->print();
  33.   // We must to delete instance_ptr like Object Pascal default classes:
  34.   delete instance_ptr;
  35. }
  36.  

In Object Pascal:
Code: Pascal  [Select]
  1. type
  2. Example = class
  3. private
  4.   _Count : Integer;
  5. public
  6.   constructor Create; overload;
  7.   constructor Create(Count: Integer); overload;
  8.   procedure Print;
  9. end;
  10.  
  11. /////////////////////
  12. RecordExample = record;
  13. private
  14.   _Count : Integer;
  15. public
  16.   class function Create : RecordExample; overload;
  17.   class function Create(Count: Integer) : RecordExample; overload;
  18.   procedure Print;
  19. end;
  20. /////////////////////
  21.  
  22.   constructor Example.Create; overload;
  23.   begin
  24.     _Count := 0;
  25.   end;
  26.  
  27.   constructor Example.Create(Count: Integer); overload;
  28.   begin
  29.     _Count := Count;
  30.   end;
  31.  
  32.   procedure Example.Print;
  33.   begin
  34.     WriteLn(_Count);
  35.   end;
  36.  
  37. var
  38.   Instance : Example;
  39.   Instance2 : RecordExample;
  40. begin
  41.   Instance := Example.Create(5); // Reference typed, created on the heap.
  42.   try
  43.     Instance.Print;
  44.   finally
  45.     // We must to delete instance in OP.
  46.     FreeAndNil(Instance);
  47.   end;
  48.  
  49.   Instance2 := RecordExample.Create(5); // Value typed, created on the stack.
  50.   Instance2.Print;
  51. end.
  52.  

I'm wondering that why are default C++ classes value typed, not reference typed but Object Pascal classes are reference typed, not value typed? Should a class be value typed or reference type as default in any programming language? Actually my question is this.

I'm usually writting C++ codes and I use C++ object files in OP.
There is a C++ class:
Code: Diff  [Select]
  1. class QString
  2. {
  3. private:
  4.  ...
  5. public:
  6.  ...
  7. };
  8.  
I want to use this QString C++ class in Object Pascal. Should I use this:
Code: Pascal  [Select]
  1. type
  2.   QString = record
  3.   end;
  4.  
Or should I use this:
Code: Pascal  [Select]
  1. type
  2.   QString = class
  3.   end;
  4.  
And why? Thanks all.
7
Beginners / Re: Invalid Function Call
« Last post by wp on Today at 03:20:43 pm »
And maybe you should also draw a sketch of what the component should look like. I cannot imagine what a "container showing a number of lists of labels" is.

Without writing a decicated component I would use a TScrollbox as container (it shows scrollbars when inserted controls are larger than the scrollbox size), and add a TListbox for every "list of labels". But probably I don't understand...
8
Windows / Re: Mimic a TSR in WinExec call???
« Last post by marcov on Today at 03:14:17 pm »
If I reread the question, I think the problem you are going to hit is

16-bit vs 32-bit and dos vs windows.

IOW trapping 16-bit dos ints and doing windows socket communication in the same exe won't be easy.
9
Carbon / Re: How future "safe" is Carbon - anyone knows?
« Last post by skalogryz on Today at 03:14:06 pm »
How to learn what Carbon APIs are deprecated?
Not every C-style function is part of Carbon.
I.e. CoreFoundation or CoreGraphics are C-style libraries, yet are not considered being a part of Carbon.

It's also worth noting that any unix or posix apis are not deprecated as well.
Even more Apple recommended those as alternative to Carbon APIs in their Carbon Deprecrecation document

If I can compile my app in 64-bit with Cocoa widgetset, does it mean that all existing 64-bit Carbon APIs are not deprecated?

I have a large old Freepascal product which doesn't use LCL. It's jard work to check all the code in hundred of units to make sure that I didn't miss all deprecated Carbon APIs. My form is using Cocoa API.
If you can compile an application for 64-bit, then it's likely you're already not using any Carbon API function.
(otherwise you would fail to link the app)
Another safe approach is to try out the app on Mojave. You should be able to get access to the beta version even now, by signing up for apple beta program
10
thanks for the patch. it has been applied to the trunk
Pages: [1] 2 3 ... 10

Recent

Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus