0

I can define a byte using:

a:  byte;

and also can define with following:

a:  Byte;

The compiler will pass for above two situation, but what is the difference of the byte and Byte?

Kromster
  • 7,181
  • 7
  • 63
  • 111
Moon soon
  • 2,616
  • 2
  • 30
  • 51
  • One of the very first tutorials on Delphi syntax explains that it is case-insensitive: http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Fundamental_Syntactic_Elements_(Delphi) Since Lazarus/FP are based on Delphi, it carries pretty much all the same syntax rules. – Jerry Dodge Sep 28 '18 at 14:00

1 Answers1

13

There is absolutely no difference. All versions of Pascal (including Delphi and Free Pascal) are case-insensitive (with very few exceptions - see below), so you can use any of the below - they're all exactly the same thing.

a: byte;
a: Byte;
a: bYTe;
A: bytE;
A: BYTe;

There are very few places Delphi is case-sensitive, and these specific exceptions are described in the documentation for H2365 Override method %s.%s should match case of ancestor %s.%s:

Here are some situations in which Delphi is case-sensitive:

Unit References and the Uses Clause

In unit declarations and uses clauses, unit names must match the file names in case. In other contexts (such as qualified identifiers), unit names are case insensitive. To avoid problems with unit references, refer to the unit source file explicitly:

uses MyUnit in "myunit.pas";

Registering components

When you write your own components and you want to register them, the register function that you declare must be written like this:

procedure Register;  <<-- Leading capital required.

The name of the Register procedure is case-sensitive for design-time packages. If you declare a register procedure (lower-case), and even if hint H2365 is not emitted, you do not get the expected result; your component does not get registered. For more information, see Using the RegisterComponents Procedure.

Importing external functions

When importing external functions, the exact case used in the DLL must be preserved.

Community
  • 1
  • 1
Ken White
  • 123,280
  • 14
  • 225
  • 444
  • In [Free Pascal Wiki about String](http://wiki.freepascal.org/String) and [Char](http://wiki.freepascal.org/Char), it use `string` or `char` to define variable and sometime use `String` and `Char` to define varable, it made me confused, is there some rule for define variable ? – Moon soon Sep 28 '18 at 02:53
  • No. `String`, `stRing`, `stRING` and `STRING` are all the same. UPPER or lower or MiXed doesn't matter. The common way is `string`, but any of them will work. – Ken White Sep 28 '18 at 02:54
  • but destructor Detroy and destructore destroy are not the same under delphi :) – zeus Sep 28 '18 at 08:20
  • @Dima me i receive an error saying case must match :) – zeus Sep 28 '18 at 09:41
  • 1
    @loki It can't be an error, maybe a warning or hint? I have seen that message too, usually with some kind of reference to C++Builder. In contrast to Delphi/Pascal, C(++) is very much case sensitive (One of the things I don't like about it.) – dummzeuch Sep 28 '18 at 10:08
  • 3
    There is H2365 that points out a difference in casing when overriding a method. See https://stackoverflow.com/a/7755124/587106 – Stefan Glienke Sep 28 '18 at 10:22
  • @StefanGlienke nice info, thanks, but it doesn't shed the light on `destructor destroy` case. So I still think Loki mistakes. – Josef Švejk Sep 28 '18 at 10:45
  • 1
    @dima: [dcc32 Hint] Main.pas(924): H2365 Override method TMainForm.destroy should match case of ancestor TCustomForm.Destroy – zeus Sep 28 '18 at 10:54
  • @loki, I'll take my words back. I've never override `TForm`'s methods. Sometimes I make new components (where I override `Destroy`) and there are were no such hint so I thought you mistake )) Sorry me) [There are more info about H2365 hint](http://docwiki.embarcadero.com/RADStudio/Tokyo/en/H2365_Override_method_%25s.%25s_should_match_case_of_ancestor_%25s.%25s_(Delphi)) – Josef Švejk Sep 28 '18 at 11:01
  • 2
    @loki: You're wrong. There is only a couple of places where Delphi is case-sensitive, one of which is `procedure Register` used for registration calls for components into the VCL, and it is only case-sensitive so that components install properly into C++Builder. `destructor Destroy` and `destructor destroy` are exactly the same in Delphi. What you're seeing with the `destructor destroy; override;` is a **hint**, not a compiler error. Hints are suggestions. Google *define hint*. I'd suspect that the hint is generated (again) for C++Builder compatibility, but it's not an error. – Ken White Sep 28 '18 at 12:05
  • **"In unit declarations and uses clauses, unit names must match the file names in case."** I just created a console app, added a new unit and saved it as "UnitWithLongName.pas". Then, at the top of the file, I changed the declaration into `unit unitwithlongname;`, and in the .dpr, I also changed it to `uses unitWithlongname in 'UnitwithlongName.pas';`, i.e. a different case spelling in all relevant places. Compiles fine and works like a treat. – Rudy Velthuis Sep 28 '18 at 12:39
  • @RudyVelthuis: Yep, that's been my experience as well. I didn't write that documentation, I just quoted it. – Ken White Sep 28 '18 at 12:44
  • @KenWhite: in C++Builder, destructors don't have names of their own. A destructor for a class `Foo` is called `~Foo()`, so the case of `destroy` in Delphi should be irrelevant for C++Builder. – Rudy Velthuis Sep 28 '18 at 12:45
  • @RudyVelthuis: Yes, but that isn't going to be the case for other overridden methods, which Builder would in fact have, and I doubt the compiler authors wanted to create a hint that said *Override method %s.%s (except for create and destroy) should match case of ancestor %s.%s*. I'd still be willing to bet that that hint is intended to help with C++ Builder component compatibility. – Ken White Sep 28 '18 at 12:48
  • @Ken: that could be true. Oh, and they write: **When importing external functions, the exact case used in the DLL must be preserved.** That is true, but you can also do: `procedure MyOwnName(params); external DllName name 'ProperlyCasedDLLFuncName';`, which is pretty nice for e.g. not properly demangled exported function names in DLLs: `procedure Simple(I: Integer); stdcall; external DllName name '_Simple@4';`. – Rudy Velthuis Sep 28 '18 at 12:53